HashMap源码和JDK1.8以后的一些变化

老夫写代码 就是一把梭
梭哈!!梭哈!!梭哈!!赢了会所嫩模,输了下海干活.

JDK1.8以后 HashMap的数据结构发生了一些改变,从单纯的数组加链表结构变成数组+链表+红黑树.如图

其中Node是HashMap的一个内部类,实现Map.Entry接口,本质是一个KV映射,上图中每个元素都是一个Node对象.
HashMap顾名思义是通过Hash表进行存储.为了解决哈希碰撞的问题,Java采用这种数组 + 链表方式来进行存储.
具体的put方法源码如下.

当JVM存储HashMap的K-V时,仅仅通过Key来决定每一个Entry的存储槽位(Node[]中的index).并且Value以链表的形式挂载到对应槽位上即可(1.8之后如果长度大于8则转为红黑树).
比如 我使用map.put(“UNSC”,”Cortana”);对HashMap中存入对应的KV,先将Key通过hashcode()方法获取到哈希值,再通过哈希算法的高位运算和取模运算来确定这个Key存储的槽位.

如果发生两个Key存储到了同一个位置,则发生了Hash冲突(碰撞),Java采用的数组 + 链表方式就发挥作用了.Java采用链地址法(哈希值相同的元素构成一个链表,链表头指针指向Node[]的index),避免了Hash冲突的问题(参考上面的HashMap的图).

HashMap扩容机制
HashMap中有resize()

看到了吧 出现了一个loadFactor(默认值0.75),当HashMap的元素个数超过数组的容量(length),进行扩容,默认情况下数组容量是16,当HashMap中的元素个数超过12个时(16*0.75 == 12),超过了临界值(就是源码中的threshold),需要把数组大小扩容一倍,然后通过rehash(再哈希),重新计算每个元素在数组中的位置.

如上图.

HashMap线程不安全的原因

HashMap在使用put方法时会调用这个方法,具体为addEntry(hash, key, value, i);
此时如果有两个线程T1和T2,两个线程同时对一个数组位置调用addEntry方法,T1和T2都能获得相同槽位(bucketIndex)的Node