Introduction to "Bucket" and "load factor" in HashMap __android

"The following excerpt from the Click to open the link at the end of a few paragraphs."

For HashMap and their subclasses, they use the Hash algorithm to determine where the elements in the collection are stored. When the system starts initializing HASHMAP, the system creates a Entry array of length capacity, where the location of the element can be stored as "bucket (bucket)", each bucket has its specified index, and the system can quickly access the bucket based on its index The elements stored in the.
Whenever a HashMap's bucket stores only one element (that is, a Entry), because the Entry object can contain a reference variable (the last parameter of the Entry constructor) is used to point to the next Entry, it is possible that the HASHMAP There is only one Entry in the bucket, but the Entry points to another entry--which forms a Entry chain. As shown in Figure 1:



Figure 1. HASHMAP Storage Signal

Read implementation of HASHMAP

When the HashMap of each bucket stored in the Entry is only a single entry--that is not through the pointer to generate Entry chain, at this time the HASHMAP has the best performance: When the program through key out of the corresponding value, the system as long as the first calculation of the key Hashcode () Returns a value that finds the index of the key in the table array based on the Hashcode return value, then takes out the Entry at the index, and returns the value of the key. Look at the Get (K key) method code for the HashMap class:

Java Code    public v get (object key)     {     //  if  key  is  null, call  getForNullKey  take out the corresponding  value     if  (key  == null)          return getfornullkey ();      //  calculates its  hash  code     int  According to the  key   hashCode  value Hash = hash (Key.hashcode ());     //  Direct removal  table  The value at the specified index in the array,     for  (entry<k,v> e = table[indexfor (hash, table.length)];          e != null;            Search the  Entry  chain for the next  Entr         e =  E.next)          // ①    {         object k;         //  If the  Entry  of   key   key  same as searched         if  (e.hash == hash  &&  ((k = e.key)  == key              | |  key.equals (k))              return  e.value;     }     return null;   }    


As you can see from the code above, if there is only one Entry in each bucket of the HASHMAP, HASHMAP can quickly retrieve bucket from the Entry by index, and in the case of a "Hash conflict", a single bucket store is not an E Ntry, instead of a Entry chain, the system must iterate through each Entry in order until it finds the Entry to search for--if the Entry that is to be searched is at the very end of the Entry chain (the Entry was first placed in the bucket), the system must loop to the most To find the element.

To sum up simply, HashMap at the bottom of the key-value as a whole to deal with, this whole is a Entry object. The HashMap bottom uses a entry[] array to hold all the key-value pairs, and when a Entry object needs to be stored, its storage location is determined according to the hash algorithm, and when a Entry is needed, the storage location is also found according to the hash algorithm, which is taken directly out The Entry. This shows: HashMap can quickly save, take it contains Entry, exactly similar to the real life mother taught us from childhood: different things to put in a different position, need to quickly find it.

When creating HashMap, there is a default load factor (load factor) with a default value of 0.75, which is a tradeoff between time and space costs: increasing the load factor reduces the memory footprint of the Hash table (that is, the Entry array), but increases the time cost of querying the data , and queries are the most frequent (HashMap get () and put () methods use queries), and reducing load factors increases the performance of data queries, but increases the amount of memory space occupied by the Hash table.

After mastering the above knowledge, we can appropriately adjust the value of the load factor when we create the HASHMAP, if the program is concerned about the space overhead, the memory is tense, can increase the load factor appropriately; If the program is concerned with the time overhead, A more comfortable memory can be appropriate to reduce the load factor. Typically, programmers do not need to change the value of a load factor.

If you begin to know that HASHMAP will save multiple key-value pairs, you can use a large initialization capacity at the time of creation, if the number of Entry in HashMap is not exceeding the limit capacity (capacity * load factor), HASHMAP will not need to call The resize () method allocates the table array to ensure better performance. Of course, initially setting the initial capacity too high can be a waste of space (the system needs to create a Entry array of length capacity), so initializing capacity settings when creating HashMap also needs to be handled with care.