HashMap类注释解析

电玩女神 2024-04-18 21:27 33阅读 0赞

结束了Collection集合的summary，现在先来看看Map集合下的HashMap的类注释。以下都是基于jdk1.8的。

HashMap继承树如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0x1eWFuYw_size_16_color_FFFFFF_t_70]

<table> 
 <tbody> 
  <tr> 
   <td align="left"><font><b>HashMap类注释解析<b></b></b></font></td> 
  </tr> 
 </tbody> 
</table>

（1）HashMap是基于Map接口实现的，它提供了Map中所有的操作，并且允许key和value为null。HashMap跟HashTable基本一样，只是HashMap是线程不安全的，并且HashMap允许null值（HashTable不允许null）。HashMap不能保证元素的顺序（即存储顺序跟添加顺序不一致）；而且，不保证这个顺序不发生变化（当rehash时，可能发生变化）。

* 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.

（2）假设hash函数能将元素均匀分布到不同的桶中，HashMap就能对基本操作（如get、put）提供常量级的实现。迭代操作的时间性能取决于HashMap实例的容量（即桶的数量）和key-value映射的数量。因此，如果对迭代性能要求比较高的话，不要将初始容量设置得太高（或将加载因子设置得太低）。

* <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.

（3）HashMap的性能受两个参数的影响：initial capacity 和 load factor。容量就是hash表中桶的数量，初始容量就是hash表被创建时的初始容量。加载因子是衡量hash表允许达到多满才可以自动扩容。当hash表中enries数量超过加载因子和当前容量的乘积时，hash表会进行rehash（也就是说，内部数据结构会重建），导致hash表中桶的数量近乎翻倍。

* <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.

（4）通常来说，加载因子的默认值0.75在时间性能和空间消耗之间达到了平衡。较高的值虽然降低了空间消耗，但是却增加了查找时间（反映在HashMap大多数的操作上，包括get和put）。当设置初始容量的时候，应该考虑将要放入map中的元素数量和加载因子，以减少rehash的次数。如果初始的容量比预计的entry数量除以加载因子的商还要大，那么永远不需要rehash操作。

* <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.

（5）如果有大量的key-value映射要添加到HashMap中，在创建实例时指定足够大的容量要比按需扩容效率更高。需要注意的是，当很多keys有相同的hashCode值时，这无疑会降低hash表的效率。为了减少冲突，key最好能够实现Comparable接口，这样这个类就能在这些key之间使用比较来降低这种影响。

* <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.

（6）HashMap不是线程安全的，如果多个线程并发访问hashmap，当至少一个线程修改了map的结构，必须在外部实现同步。结构修改指的是添加或删除key-value映射，修改已经存在的key-value映射值并不是结构修改。这通常是通过同步封装了这个map的某个对象来实现的。  
如果不存在这样的对象，那么就应该使用Collections\#synchronizedMap来封装。为了防止偶然异步访问这个map，最好在创建的时候就使用Map m = Collections.synchronizedMap(new HashMap(…));

* <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>

（7）当迭代器创建之后，除了通过迭代器自己的remove方法，任何对map进行了结构性修改，迭代器就会抛出 并发修改的异常。当面对并发修改的时候，迭代器会快速明了的报错，而不冒任何在未来的某个不确定时间的不确定行为的风险。  
注意，迭代器的快速失败行为不能得到保证，一般来说，存在非同步的并发修改时，不可能作出任何坚决的保证。快速失败迭代器尽最大努力抛出 ConcurrentModificationException。因此，编写依赖于此异常的程序的做法是错误的，正确做法是：迭代器的快速失败行为应该仅用于检测程序错误。

* <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>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0x1eWFuYw_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/67db2ab42edf439fb1baa8ab04e9d24e.png