Solr the query query problem caused by solr cache

Background
Currently in the company, when implementing a solr dish name recommendation module, I encountered a problem that has been bothering me for several days. After the logic code of the module is implemented and the function is confirmed, a bug is found after deployment and testing. That is, the results of multiple queries repeat the results of the first query.
Troubleshooting
first thought whether the following queries did not really call the implemented logic, so I remotely debugged the code on the server in the local IDEA and found that when I query in solr, it does enter the logic code and hit a breakpoint, And it does pass different query parameters to the method, but the returned result is still not as expected, just repeating the first result.
Considering again whether it is some caching mechanism of solr, multiple query results are identified as the same, and the results in the cache are directly returned. After thinking about this result, I started a long process of single-step debugging, hoping to locate the code that may be problematic, and at the same time looking for relevant content about the solr cache.
Finally, in the conf file of solr, the relevant cache code is located

<query>
    <maxBooleanClauses>1024</maxBooleanClauses>

    <filterCache class="solr.FastLRUCache"
                 size="512"
                 initialSize="512"
                 autowarmCount="0"/>

    <!-- Add this paragraph, there will be multiple query results with the same problem-->
    <queryResultCache class="solr.LRUCache"
                     size="512"
                     initialSize="512"
                     autowarmCount="0"/>
     
    <documentCache class="solr.LRUCache"
                   size="512"
                   initialSize="512"
                   autowarmCount="0"/>
    
    <cache name="perSegFilter"
      class="solr.search.LRUCache"
      size="10"
      initialSize="0"
      autowarmCount="10"
      regenerator="solr.NoOpRegenerator" />

During the test, it was found that when the section marked in the middle was deleted, the query was normal, so it was confirmed that the queryResultCache cache judged different queries as the same key, so the subsequent queries directly called the results of the first cache.
After finding this result, see what the key of the queryResultCache is determined by.

package org.apache.solr.search;
public QueryResultKey(Query query, List<Query> filters, Sort sort, int nc_flags) {
        this.query = query;
        this.sort = sort;
        this.filters = filters;
        this.nc_flags = nc_flags;
        int h = query.hashCode();
        Query filt;
        if(filters != null) {
            for(Iterator var6 = filters.iterator(); var6.hasNext(); h += filt.hashCode()) {
                filt = (Query)var6.next();
            }
        }

        this.sfields = this.sort != null?this.sort.getSort():defaultSort;
        SortField[] var10 = this.sfields;
        int var11 = var10.length;

        for(int var8 = 0; var8 < var11; ++var8) {
            SortField sf = var10 [var8];
            h = h * 29 + sf.hashCode();
        }

        this.hc = h;  
    }

The above is the definition class of the key of queryResultCache, where the hashcode of the key is the hc attribute. By definition, it can be seen that

int h = query.hashCode();
this.hc = h;

, after single-step debugging, it is found that the hc obtained here is the same after different query queries, so it is precisely located that the problem lies in the hashcode generation of the custom query.
FreqQuery entends bitQuery extends Query
in the superclass Query, define the method

@Override
  public int hashCode() {
    return getClass().hashCode();
  }

Inherited subclasses do not override the hashcode() method, so the hashcode of each query is the same.
After locating the problem, the modification method is very simple. Override this method in FreqQuery, pay attention to distinguishing each query, and at the same time ensure that the same query can hit the cache. Here I use the hashcode of the query as the hashcode of the query. After the modification is completed, submit the code, deploy the application, and find that the results are the same as expected.


Remote debugging tutorialhttps :
//www.cnblogs.com/wy2325/p/5600232.htmlOn solr cachinghttp : //www.cnblogs.com/phinecos/archive/2012/05/24/2517018.html