金三银四精选面试题-JAVA8的ConcurrentHashMap为什么放弃了分段锁，有什么问题吗，如果你来设计，你如何设计？

java8的ConcurrentHashMap为什么放弃了分段锁，有什么问题吗，如果你来设计，你如何设计？

JDK1.7中设计的分段锁

Segment继承了重入锁ReentrantLock，有了锁的功能，每个锁控制的是一段，当每个Segment越来越大时，锁的粒度就变得有些大了，具体分段数量由concurrencyLevel字段来控制。

• 分段锁的优势在于保证在操作不同段 map 的时候可以并发执行，操作同段 map 的时候，进行锁的竞争和等待。这相对于直接对整个map同步synchronized是有优势的。

• 缺点在于分成很多段时会比较浪费内存空间(不连续，碎片化); 操作map时竞争同一个分段锁的概率非常小时，分段锁反而会造成更新等操作的长时间等待; 当某个段很大时，分段锁的性能会下降。

因为在 JDK7 中 Segment 继承了重入锁ReentrantLock,但是大家有没有想过，如果说每个 Segment 在增长的时候,那你有没有考虑过这时候锁的粒度也会在不断的增长。

一个Segment里包含一个HashEntry数组，每个锁控制的是一段，那么如果分成很多个段的时候，这时候加锁的分段还是不连续的，是不是就会造成内存空间的浪费。所以问题一出现了，分段锁在某些特定的情况下是会对内存造成影响的，什么情况呢？我们倒着推回去就知道：

1.每个锁控制的是一段，当分段很多，并且加锁的分段不连续的时候，内存空间的浪费比较严重。

大家都知道，并发是什么样子的，就相当于百米赛跑，你是第一，我是第二这种形式，同样的，线程也是这样的，在并发操作中，因为分段锁的存在，线程操作的时候，争抢同一个分段锁的几率会小很多，既然小了，那么应该是优点了，但是大家有没有想过如果这一分块的分段很大的时候，那么操作的时间是不是就会变的更长了。

所以第二个问题出现了：

如果某个分段特别的大，那么就会影响效率，耽误时间。所以，这也是为什么在 JDK8 不在继续使用分段锁的原因。

JDK8 的 ConcurrentHashMap 使用的是什么？

从上面的分析中，我们得出了 JDK7 中的 ConcurrentHashMap 使用的是 Segment 和 HashEntry，而在 JDK8 中 ConcurrentHashMap 就变了，阿粉现在这里给大家把这个抛出来，我们再分析， JDK8 中的 ConcurrentHashMap 使用的是 synchronized 和 CAS 和 HashEntry 和红黑树。

ConcurrentHashMap 和 HashMap 一样，使用了红黑树，而在 ConcurrentHashMap 中则是取消了Segment分段锁的数据结构，取而代之的是Node数组+链表+红黑树的结构。

为什么要这么做呢？

因为这样就实现了对每一行数据进行加锁，减少并发冲突。

实际上我们也可以这么理解，就是在 JDK7 中，使用的是分段锁，在 JDK8 中使用的是 “读写锁” 毕竟采用了 CAS 和 Synchronized 来保证线程的安全。