ConcurrentHashMap1.8与1.7相比的重大变化：
数据结构：取消了segment，直接用table保存数据，锁的粒度更小，减少并发冲突的概率。
时间复杂度：Table+链表和红黑树的形式，纯链表的形式时间复杂度O（n），红黑树的形式时间复杂度O（logn），性能提升大。链表转红黑树，必要条件：个数超过了8个。当链表个数小于等于6的时候，从红黑树转化为链表。
线程并发安全机制：从1.7的ReentrantLock+segment+HashEntry到CAS+synchronize+HashEntry+红黑树
锁的粒度：从1.7的对操作元素的segment加锁到1.8的对每个数组元素（Node中）加锁。
元素插入：1.7用的是头插法，而JDK1.8及之后使用的都是尾插法，因为JDK1.7是用单链表进行的纵向延伸，当采用头插法时会容易出现逆序且环形链表死循环问题。但是在1.8之后是因为加入了红黑树使用尾插法，能够避免出现逆序且链表死循环的问题。
HashMap 的工作原理？
HashMap 底层是 hash 数组和单向链表实现，数组中的每个元素都是链表，由 Node 内部类（实现 Map.Entry接口）实现，HashMap 通过 put & get 方法存储和获取。
存储对象时，将 K/V 键值传给 put() 方法：
1、调用 hash(K) 方法计算 K 的 hash 值，然后结合数组长度，计算得数组下标；
2、调整数组大小（当容器中的元素个数大于 capacity * loadfactor 时，容器会进行扩容resize 为 2n）；
3、i.如果 K 的 hash 值在 HashMap 中不存在，则执行插入，若存在，则发生碰撞；
ii.如果 K 的 hash 值在 HashMap 中存在，且它们两者 equals 返回 true，则更新键值对；
iii. 如果 K 的 hash 值在 HashMap 中存在，且它们两者 equals 返回 false，则插入链表的尾部（尾插法）或者红黑树中（树的添加方式）。
（JDK 1.7 之前使用头插法、JDK 1.8 使用尾插法）
获取对象时，将 K 传给 get() 方法：①、调用 hash(K) 方法（计算 K 的 hash 值）从而获取该键值所在链表的数组下标；②、顺序遍历链表，equals()方法查找相同 Node 链表中 K 值对应的 V 值。
ConcurrentHashMap的弱一致性：
可能你期望往ConcurrentHashMap底层数据结构中加入一个元素后，立马能对get可见，但ConcurrentHashMap并不能如你所愿。换句话说，put操作将一个元素加入到底层数据结构后，get可能在某段时间内还看不到这个元素，若不考虑内存模型，单从代码逻辑上来看，却是应该可以看得到的。
ConcurrentHashMap的弱一致性主要是为了提升效率，是一致性与效率之间的一种权衡。要成为强一致性，就得到处使用锁，甚至是全局锁，这就与Hashtable和同步的HashMap一样了。
何为加载因子？
加载因子是表示Hsah表中元素的填满的程度.若:加载因子越大,填满的元素越多,好处是,空间利用率高了,但:冲突的机会加大了.
反之,加载因子越小,填满的元素越少,好处是:冲突的机会减小了,但:空间浪费多了.
冲突的机会越大,则查找的成本越高.反之,查找的成本越小.因而,查找时间就越小.
因此,必须在 "冲突的机会"与"空间利用率"之间寻找一种平衡与折衷. 这种平衡与折衷本质上是数据结构中有名的"时-空"矛盾的平衡与折衷.
HashMap中的加载因子
HashMap默认的加载因子是0.75，最大容量是16，因此可以得出HashMap的默认容量是：0.75*16=12。
用户可以自定义最大容量和加载因子。
HashMap 包含如下几个构造器：
HashMap()：构建一个初始容量为 16，负载因子为 0.75 的 HashMap。
HashMap(int initialCapacity)：构建一个初始容量为 initialCapacity，负载因子为 0.75 的 HashMap。
HashMap(int initialCapacity, float loadFactor)：以指定初始容量、指定的负载因子创建一个 HashMap。
ConcurrentHashMap与HashMap的区别
除了线程安全以外，还有允许键值为null，但是ConcurrentHashMap不允许
为什么 ConcurrentHashMap 比 HashTable 效率要高？
HashTable 使用一把锁（锁住整个链表结构）处理并发问题，多个线程竞争一把锁，容易阻塞；
ConcurrentHashMap
红黑树的特点：
ConcurrentHashMap 在 JDK 1.8 中，为什么要使用内置锁 synchronized 来代替重入锁 ReentrantLock？
1、粒度降低了；
2、JVM 开发团队没有放弃 synchronized，而且基于 JVM 的 synchronized 优化空间更大，更加自然。
3、在大量的数据操作下，对于 JVM 的内存压力，基于 API 的 ReentrantLock 会开销更多的内存。
针对 ConcurrentHashMap 锁机制具体分析（JDK 1.7 VS JDK 1.8）
JDK 1.7 中，采用分段锁的机制，实现并发的更新操作，底层采用数组+链表的存储结构，包括两个核心静态内部类 Segment 和 HashEntry。
1、Segment 继承 ReentrantLock（重入锁） 用来充当锁的角色，每个 Segment 对象守护每个散列映射表的若干个桶；
2、HashEntry 用来封装映射表的键-值对；
3、每个桶是由若干个 HashEntry 对象链接起来的链表
JDK 1.8 中，采用Node + CAS + Synchronized来保证并发安全。取消类 Segment，直接用 table 数组存储键值对；当 HashEntry 对象组成的链表长度超过 TREEIFY_THRESHOLD 时，链表转换为红黑树，提升性能。底层变更为数组 + 链表 + 红黑树。
本文分享自微信公众号 - JAVA干货分享（JAVA347411）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。