Java源码解析HashMap简介

/**

  * hash table based implementation of the <tt>map</tt> interface. this

  * implementation provides all of the optional map operations, and permits

  * <tt>null</tt> values and the <tt>null</tt> key. (the <tt>hashmap</tt>

  * class is roughly equivalent to <tt>hashtable</tt>, except that it is

  * unsynchronized and permits nulls.) this class makes no guarantees as to

  * the order of the map; in particular, it does not guarantee that the order

  * will remain constant over time.

  * <p>this implementation provides constant-time performance for the basic

  * operations (<tt>get</tt> and <tt>put</tt>), assuming the hash function

  * disperses the elements properly among the buckets. iteration over

  * collection views requires time proportional to the "capacity" of the

  * <tt>hashmap</tt> instance (the number of buckets) plus its size (the number

  * of key-value mappings). thus, it's very important not to set the initial

  * capacity too high (or the load factor too low) if iteration performance is

  * important.

  * <p>an instance of <tt>hashmap</tt> has two parameters that affect its

  * performance: <i>initial capacity</i> and <i>load factor</i>. the

  * <i>capacity</i> is the number of buckets in the hash table, and the initial

  * capacity is simply the capacity at the time the hash table is created. the

  * <i>load factor</i> is a measure of how full the hash table is allowed to

  * get before its capacity is automatically increased. when the number of

  * entries in the hash table exceeds the product of the load factor and the

  * current capacity, the hash table is <i>rehashed</i> (that is, internal data

  * structures are rebuilt) so that the hash table has approximately twice the

  * number of buckets.

  * <p>as a general rule, the default load factor (.75) offers a good

  * tradeoff between time and space costs. higher values decrease the

  * space overhead but increase the lookup cost (reflected in most of

  * the operations of the <tt>hashmap</tt> class, including

  * <tt>get</tt> and <tt>put</tt>). the expected number of entries in

  * the map and its load factor should be taken into account when

  * setting its initial capacity, so as to minimize the number of

  * rehash operations. if the initial capacity is greater than the

  * maximum number of entries divided by the load factor, no rehash

  * operations will ever occur.

  * <p>if many mappings are to be stored in a <tt>hashmap</tt>

  * instance, creating it with a sufficiently large capacity will allow

  * the mappings to be stored more efficiently than letting it perform

  * automatic rehashing as needed to grow the table. note that using

  * many keys with the same {@code hashcode()} is a sure way to slow

  * down performance of any hash table. to ameliorate impact, when keys

  * are {@link comparable}, this class may use comparison order among

  * keys to help break ties.

  * <p><strong>note that this implementation is not synchronized.</strong>

  * if multiple threads access a hash map concurrently, and at least one of

  * the threads modifies the map structurally, it <i>must</i> be

  * synchronized externally. (a structural modification is any operation

  * that adds or deletes one or more mappings; merely changing the value

  * associated with a key that an instance already contains is not a

  * structural modification.) this is typically accomplished by

  * synchronizing on some object that naturally encapsulates the map.

  * if no such object exists, the map should be "wrapped" using the

  * {@link collections#synchronizedmap collections.synchronizedmap}

  * method. this is best done at creation time, to prevent accidental

  * unsynchronized access to the map:<pre>

  *  map m = collections.synchronizedmap(new hashmap(...));</pre>

  * <p>the iterators returned by all of this class's "collection view methods"

  * are <i>fail-fast</i>: if the map is structurally modified at any time after

  * the iterator is created, in any way except through the iterator's own

  * <tt>remove</tt> method, the iterator will throw a

  * {@link concurrentmodificationexception}. thus, in the face of concurrent

  * modification, the iterator fails quickly and cleanly, rather than risking

  * arbitrary, non-deterministic behavior at an undetermined time in the

  * future.

  * <p>note that the fail-fast behavior of an iterator cannot be guaranteed

  * as it is, generally speaking, impossible to make any hard guarantees in the

  * presence of unsynchronized concurrent modification. fail-fast iterators

  * throw <tt>concurrentmodificationexception</tt> on a best-effort basis.

  * therefore, it would be wrong to write a program that depended on this

  * exception for its correctness: <i>the fail-fast behavior of iterators

  * should be used only to detect bugs.</i>

  * <p>this class is a member of the

  * <a href="{@docroot}/technotes/guides/collections/index.html" rel="external nofollow" >

  * java collections framework</a>.

  * @param <k> the type of keys maintained by this map

  * @param <v> the type of mapped values

  * @author doug lea

  * @author josh bloch

  * @author arthur van hoff

  * @author neal gafter

  * @see   object#hashcode()

  * @see   collection

  * @see   map

  * @see   treemap

  * @see   hashtable

  * @since  1.2

  **/