概述
一、注释
- 基于
hash table
的Map接口实现。HashMap
提供所有map的可选操作,允许键和值为null
。(HashMap
除了unsynchronized
和允许null
值,与Hashtable相同)。HashMap
不保证元素顺序,特别是随着时间推移。 - 在hash函数正确的分散元素到
buckets
中时,HashMap
对基本的get和put操作提供常数项时间性能。对集合视图的迭代则与HashMap
实例的capacity(buckets
的数量)和size
(key-value键值对的数量)成比例。因此,如果迭代性能非常重要时,不要把initial capacity
初识容量设置的太高(或者load factor
负载因子设置太低) - 有两个参数影响
HashMap
实例的性能:initial capacity
初识容量和load factor
负载因子。capacity就是hash table
中buckets
的数量,initial capacity
就是hash table
创建时的容量。load factor
是hash table
再次自动增长时能有多满的一个衡量值。当hash table
中entires的数量超过load factor
* 当前capacity
时,hash table
会进行rehashed(),hash table
的buckets
数量会翻倍 - 一般情况下,默认
load factor
(0.75)在时间和空间成本之间提供了一个较好的平衡。较高的值会减少空间开销但是会增加查找成本(反映在HashMap
绝大多数操作,包括get和put)。为了减少rehash
的操作,在设置initial capacity
时应该考虑集合存储的元素数量和load factor
。如果initial capacity
大于元素数量除以load factor
,就不会发生rehash
操作。 - 如果要在
HashMap
实例中存储许多元素,再创建时设置比较大的容量比它进行rehashed
自动增长容量要更有效率。注意这点,对于任何hash table
,用很多有相同hashCode()
的keys是最能降低hash table
的性能,当keys是可比较时,HashMap
会使用keys之间的比较来改善这种状况。 - 请注意,此实现不是
synchronized
的。如果多个线程并发访问,并且至少又一个线程修改map的结构时,必须在外部进行synchronized
。(结构修改是指增加或删除一个或多个mappings映射,改变一个key对应的value不属于结构的修改)。这通常通过一个对象锁来实现,如果不存在这个对象,也可以使用Collections.synchronizedMap来实现:Map m = Collections.synchronizedMap(new HashMap(...));
- 对于这个类的所有返回的iterator方法:在iterator创建后,除了通过iterator的remove方法,任何对map的结构修改都会
fast-fail
快速失败,并抛出异常ConcurrentModificationException
。在并发修改的情况下,iterator会快速干净的失败,而不是在未来发生不确定的风险。 - 请注意,迭代器的故障快速行为无法得到保证,因为一般来说,在存在非同步并发修改时,无法做出任何硬性保证。失败快速的迭代器会尽最大努力抛出
ConcurrentModificationException
。因此,编写依赖于此异常的程序以确保其正确性是错误的:迭代器的失败快速行为应该 仅用于检测错误。
二、主要方法分析
三、使用注意
四、参考
- https://crossoverjie.top/2018/07/23/java-senior/ConcurrentHashMap/
最后
以上就是优秀小松鼠为你收集整理的java.util.HashMap的全部内容,希望文章能够帮你解决java.util.HashMap所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
发表评论 取消回复