HashMap、ConcurrentHashMap HashMap常见的不安全问题及原因
非原子操作
++ modCount 等非原子操作存在且没有任何加锁机制会导致线程不安全问题；
扩容取值
扩容期间会创建新的table在数据转储期间，可能会有取到null的可能；
碰撞丢失
多线程情况下，若同时对一个bucket 进行put操作可能会出现覆盖情况；
可见性问题
HashMap中没有可见性volatile关键字修饰，多线程情况下不能保证可见性；
死循环
JDK1.7 扩容期间，头插法也可能导致出现循环链表，即NodeA.next = NodeB ; NodeB.next = NodeA 在取值时则会发生死循环；
ConcurrentHashMap在JDK1.8中的升级 Java 7 版本的 ConcurrentHashMap
从图中我们可以看出，在 ConcurrentHashMap 内部进行了 Segment 分段，Segment 继承了 ReentrantLock，可以理解为一把锁，各个 Segment 之间都是相互独立上锁的，互不影响分段锁。相比于之前的 Hashtable 每次操作都需要把整个对象锁住而言，大大提高了并发效率。因为它的锁与锁之间是独立的，而不是整个对象只有一把锁。
每个 Segment 的底层数据结构与 HashMap 类似的HashEntry（所以1.7中的put操作需要进行两次Hash，先找到Segment再找到HashEntry，并使用 tryLock + 自旋的方式尝试插入数据），仍然是数组和链表组成的拉链法结构。默认有 0~15 共 16 个 Segment，所以最多可以同时支持 16 个线程并发操作（操作分别分布在不同的 Segment 上）。16 这个默认值可以在初始化的时候设置为其他值，但是一旦确认初始化以后，是不可以扩容的。
获取Map的size时，依次执行两种方案，尝试不加锁获取两次，若不变则说明size准确；否则执行方案二 加锁情况下直接获取size；
Java 8 版本的 ConcurrentHashMap在 Java 8 中，几乎完全重写了 ConcurrentHashMap，代码量从原来 Java 7 中的 1000 多行，变成了现在的 6000 多行，取消了Segment，使用 Node [] + 链表 + 红黑树，放弃了ReentrantLock的使用采用了`Synchronized + CAS + volatile（Node 的 value属性） 锁机制能适应更高的并发和更高效的锁机制，也依赖于Java团队对Synchronized锁的优化。
获取Map的size时，sumCount函数在每次操作时已经记录好了，所以直接返回；但既然是高并发容器，size并没有多大意义，瞬时值；
图中的节点有三种类型。
第一种是最简单的，空着的位置代表当前还没有元素来填充。 第二种就是和 HashMap 非常类似的拉链法结构，在每一个槽中会首先填入第一个节点，但是后续如果计算出相同的 Hash 值，就用链表的形式往后进行延伸。 第三种结构就是红黑树结构，这是 Java 7 的 ConcurrentHashMap 中所没有的结构，在此之前我们可能也很少接触这样的数据结构。 当第二种情况的链表长度大于某一个阈值（默认为 8），且同时满足一定的容量要求的时候，ConcurrentHashMap 便会把这个链表从链表的形式转化为红黑树的形式，目的是进一步提高它的查找性能。所以，Java 8 的一个重要变化就是引入了红黑树的设计，由于红黑树并不是一种常见的数据结构，所以我们在此简要介绍一下红黑树的特点。
红黑树是每个节点都带有颜色属性的自平衡的二叉查找树，颜色为红色或黑色，红黑树的本质是对二叉查找树 BST 的一种平衡策略，我们可以理解为是一种平衡二叉查找树，查找效率高，会自动平衡，防止极端不平衡从而影响查找效率的情况发生。
由于自平衡的特点，即左右子树高度几乎一致，所以其查找性能近似于二分查找，时间复杂度是 O(log(n)) 级别；反观链表，它的时间复杂度就不一样了，如果发生了最坏的情况，可能需要遍历整个链表才能找到目标元素，时间复杂度为 O(n)，远远大于红黑树的 O(log(n))，尤其是在节点越来越多的情况下，O(log(n)) 体现出的优势会更加明显。
红黑树的一些其他特点：
每个节点要么是红色，要么是黑色，但根节点永远是黑色的。
红色节点不能连续，也就是说，红色节点的子和父都不能是红色的。
从任一节点到其每个叶子节点的路径都包含相同数量的黑色节点。