HashMap 类
原码中的文档解释:
一
- 允许null value和null key
- 几乎与Hashtable等价,但它不是unsynchronized的(允许不同线程同时访问, 非线程安全)并且允许null出现在键值对中(只允许一个key为null)
- HashMap并不保证map的有序性
二
- (hash 函数将元素适当地分配到bucket中时)基本的get和put操作的时间是常量级别的
- 集合的迭代(iteration)与HashMap实例的''capacity''大小(bucket的数量)加上大小(key-value键值对的映射数量)是成比例的. 因此, 初始的capacity值不能设置的很高(或者使负载因子很小)如果想要使迭代性能比较高的话
三
一个HashMap有两个参数影响它的性能:
- 初始容量(initial capacity)
- 负载因子(load factor)
capacity是hash table中bucket的数量, initial capacity是hash table创建时的容量
load factor 是对capacity自动增长前对hash table大小的衡量(a measure of how full the hash table is allowed to* get before its capacity is automatically increased). 当在hash table 中的内容大小(size)超过load factor和当前capacity的乘积(product)时, hash table会被再哈希(rehashed) (也就是说, 内部的数据结构会被重建, 会使hash table的bucket数量变为接近原来的两倍大小)
四
一般来说, 默认的load factor (0.75)在空间和时间花费上达到了较好的平衡. 取值较高时会降低空间上的开销但是会增加查找上的开销(这点体现在HashMap的大多数操作上, 包括get和put). 设定initial capacity时应当考虑map中会有的记录条数(The expected number of entries in* the map)以及它的load factor的大小从而最小化rehash的操作次数. 如果initial capacity比entries/load factor的最大值大, rehash操作就不会发生了.
五
如果许多键值对映射被存储到HashMap实例中, 在创建这个实例时赋予足够大的capacity能使映射存储得更加高效(相比于自动rehash的来扩容的角度来说). 注意, 多个key的hashCode()值相同肯定会降低hash table的性能的. 为了改良这种影响, 当key是Comparable时, 会通过keys间的比较顺序来帮助打破这种情况.
六
HashMap类的实现不是synchronized的, 如果多线程并发访问一个hash map, 至少会有一个线程改变map的结构, 它的外部必须是synchronized的. (结构上的改动-structural modification)是任意的添加或者删除一个或多个映射(mappings); 仅仅改变已经存在于某个实例当中的某个key的值不是结构上的改动.) 这荣昌通过在某个object上进行synchronizing来对map进行封装进行解决.
如果没有这样的object存在, 那么map应当通过使用Collections.synchronizedMap方法进行包裹(wrapped). 这最好在创建时就使用, 从而能够避免意外地unsynchronized访问map,如:
Map m = Collections.synchronizedMap(new HashMap(...));
所有这个类的"collection view methods"返回的迭代器(iterator)都是fail-fast(快速失败的)，如果在iterator创建后map被structurally modified, 那么除了iterator自身调用remove方法外, 在调用其他方法时iterator会抛出ConcurrentModificationException异常. 因此, 在面临并发改动时, iterator会的迭代会很快失败.
iterator的fail-fast behavior并不能被保证, 一般来说, 不可能在unsynchronized concurrent modification出现时进行任何保证. <u>Fail-fast iterator在best-effort的基础上抛出ConcurrentModificationException</u>(没懂,原文:Fail-fast iterators throw ConcurrentModificationException on a best-effort basis.)因此, fail-fast behavior的特点在测试bugs使用尚可, 依赖于此而编写程序就不可取.
官网的集合接口的tutorial
源码分析的文章
