Java11 HashMap源码分析(一、文档翻译)
描述文档：
/**
* Hash table based implementation of the {@code Map} interface. This
* implementation provides all of the optional map operations, and permits
* {@code null} values and the {@code null} key. (The {@code HashMap}
* class is roughly equivalent to {@code Hashtable}, 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.
*/
第一段表明HashMap是基于Map接口实现的哈希表，提供了所有可选的Map操作，并且允许空Key和Value。HashMap和Hashtable大体上相同，但是HashMap不是线程安全的并且允许空值。
这个类也不保证Map的顺序，特别是不能保证顺序的持久化，也就是说顺序可能随着时间变化（例如rehash操作）。
/**This implementation provides constant-time performance for the basic
* operations ({@code get} and {@code put}), assuming the hash function
* disperses the elements properly among the buckets. Iteration over
* collection views requires time proportional to the "capacity" of the
* {@code HashMap} 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.
*/
第二段，这个实现(HashMap)提供了基础操作put和get的固定时间表现（指每次操作时间相同），假设哈希函数将元素正确的分散到篮子（table中的位置）。
在集合视图上迭代的时间和HashMap的capacity和size有关，因此为了迭代的性能，不要将初始capacity设置的过高。
/**<p>An instance of {@code HashMap} 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.
*/
第三段，有两个影响HashMap性能的因素：初始容积(initial capacity, hashtable中位置的数量)和装填因子(load factor,决定HashMap的位置在扩容之前能有多少比例被使用)。
每当元素的数量大于装填因子和容积的积，就会触发扩容和重哈希，新的HashMap的容积大约是原来的两倍。
/**<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 {@code HashMap} class, including
* {@code get} and {@code put}). 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 {@code HashMap}
* 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.
*/
第五段，当有许多映射储存在Hashmap中时，创建时指定一个足够大的容积比等待它自动扩容要更有效率。
使用许多有着相同hashcode的key会明显的降低任何hashtable的性能。为了改善这个情况，当key是可比较的(实现了Comparable接口），
可以在key中使用比较顺序来帮助打破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>
第六段，注意这个实现（HashMap）是线程不安全的。如果多个线程同时访问一个hashmap，并且至少一个线程结构性的(structurally，删除或增加)修改这个map，
就必须在外部被同步。同步通常是在通过封装map的某个对象上来实现的。(?)
如果没有这样的对象，hashmap应该使用Collections.synchrinizedMap方法包裹起来，最好在创建的时候，来防止意外的非同步访问。并给出了示例。
/**<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
* {@code remove} 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.
*/
第七段，这个类所有的集合视图方法返回的迭代器都是fail-fast的--如果map在迭代器被创建后的任何时间被结构性的修改（除了这个迭代器自己通过remove修改），迭代器就会抛出concurrentModificationException异常。因此，当有并发操作时，迭代器快速崩溃，而不是冒着出错的风险继续工作。
* <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 {@code ConcurrentModificationException} 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>
第八段，接着上一段讲，注意迭代器的fail-fast行为不能被保证正常工作，一般来说，在非同步并发修改时做出任何硬性保证是不可能的。
fail-fast迭代器抛出ConcurrentMdificationException异常已经尽了最大的努力，因此不能依赖这个机制的正确性来写程序--迭代器的fast-fail行为应该只在检测bug时被使用。
