注释部分
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>
*
接口的基于哈希表的实现。该实现提供了所有可选的映射操作，并允许 null值和null键。 HashMap 类与Hashtable大致等效，除了它不同步并且允许空值此类不保证map的顺序；特别是，它不能保证顺序会随着时间的推移保持恒定。 此实现为基本操作 get和 put提供了恒定时间的性能，并假设哈希函数在各个存储桶中正确分散了元素。在集合视图上进行迭代需要的时间与HashMap实例的“容量”（存储桶数）及其大小（键值映射的数量）成比例。因此，如果迭代性能很重要，则不要将初始容量设置得过高（或负载因数过低），这一点非常重要。HashMap的实例具有两个影响其性能的参数：初始容量和负载系数。 capacity是哈希表中存储桶的数量，初始Capacity是创建哈希表时的容量。负载因子衡量散列表的容量在自动增加之前允许多少。当哈希表中条目的数量超过负载因子与*当前容量的乘积时，哈希表将被 rehashed（即，内部数据结构被重建），以便哈希表中的存储桶数量大约是数量的两倍。 作为一般规则，默认的负载系数（.75）在时间和空间成本之间提供了一个很好的折衷方案。较高的值会减少空间开销，但会增加查找成本（在HashMap类的大多数操作中都得到了体现，包括get 和 put）。 设置其初始容量时，应考虑映射中的预期条目数及其负载因子，以最大程度地减少重新哈希操作的数量。如果初始容量大于最大条目数除以负载系数，则将不会发生任何重新哈希操作。 如果要在 HashMap实例中存储许多映射，则以足够大的容量创建映射将比使它执行自动重新散列的方式更有效地存储映射。需要增长表。请注意，使用多个具有相同{@code hashCode（）}的键是降低任何哈希表性能的肯定方法。为了改善影响，当键是{@link Comparable}时，此类可以使用键之间的比较顺序来帮助打破平局。 请注意，此实现未同步。如果多个线程同时访问哈希映射，并且线程中的至少一个在结构上修改了映射，则它必须我从外部同步。 （结构修改是添加或删除一个或多个映射的任何操作； 仅更改与实例已经包含的键相关联的值不是结构修改。）通常是通过同步某个对象来完成的。自然地封装了地图。 如果不存在这样的对象，则应使用{{@link CollectionssynchronizedMap Collections.synchronizedMap} 方法来“包装”地图。最好在创建时执行此操作，以防止意外非同步访问map：Map m = Collections.synchronizedMap（new HashMap（...））; 返回的迭代器所有此类的“集合视图方法” 都是快速失败：如果在创建迭代器之后的任何时间对结构进行结构修改，则除了通过迭代器自己的方法之外，其他方式都是 remove 方法，迭代器将抛出{@link ConcurrentModificationException}。因此，面对并发的修改，迭代器会迅速而干净地失败，而不是冒着在未来未定的时间冒任意，不确定的行为的风险。请注意，不能保证迭代器的快速失败行为，因为通常来说，在存在不同步的并发修改的情况下，不可能做出任何严格的保证。快速失败的迭代器尽最大努力抛出ConcurrentModificationException。 因此，编写依赖于此异常的程序的正确性是错误的：迭代器的快速故障行为仅应用于检测错误
