java 1.8 1.6hashmap_jdk 1.6 / 1.7 / 1.8 之HashMap & ConcurrentHashMap对比

jdk 1.6 / 1.7 / 1.8 之HashMap & ConcurrentHashMap对比

HashMap

1.6

负载因子默认0.75,默认容量是16

当容量使用占比>=(16*0.75)时，进行扩容(resize(2 * table.length))

基于数组和链表实现,hash碰撞时，会添加到链表中

key为null时，数据添加到数组索引0的位置

缺点：

1：hash碰撞多较多时，获取数据会变慢

2：hash算法复杂

3：new HashMap时，开辟了内存空间，如果不使用，则浪费内存

1.7

同1.6基本没太大差异，不过改成了懒汉初始化,意味着new HashMap并没有开辟内存空间

容量达到负载阀值时，会扩容(resize(2 * table.length))

1.8

相比1.7，进一步优化了new HashMap的过程

hash算法改为了XORs算法(x ^ (x>>>16))

扩容算法改为ewThr = oldThr << 1

解决了hash碰撞较多情况下的性能问题(链表长度限制为8，过长时请将链表转换为TreeNode(红黑树))

鉴于hashMap扩容问题，如果确定业务数据大于默认负载时，建议new HashMap时，指定容量，防止扩容时的性能损耗

ConcurrentHashMap

key & value都不允许为null，但是1.6/1.7没做前置检查

1.6

默认容量16，负载因子0.75，并发度16(相当于数据分片),默认构造开辟了内存空间

hash算法难看的一比，懒得去理解什么意思了

基于分片+链表数组结构(分片竟然继承了ReentrantLock，表示无奈)

根据hash值，得到对应的分片，然后将值插入分片中

插入数据时，使用了父类的lock方法(可重入锁)

不得不说ConcurrentHashMap的扩容过程是相当复杂,并且和HashMap一样，碰撞比较多时，影响性能

1.7

相比1.6，无大变化，但是数据存取依赖了UNSAFE

1.8

修正1.6/1.7，put数据时key为null没有前置检查的问题

hash算法采用XORs

丢弃了1.6/1.7中那个并发级别定义(concurrency level)，改用动态分片

分片锁采用synchronized,1.6/1.7都是可重入锁

数据结构构造采用懒汉方法，避免new但不使用的内存浪费情况

分片(链表长度)大8时，采用TreeNode(红黑树)，提高检索效率

最后的建议：如果用Map做缓存使用时，请注意扩容问题，尽量初始化指定大小，防止扩容导致的性能问题

深夜码字，很累，如有错误请指正，不喜勿喷.