-
为什么ConcurrentHashMap是线程安全的
JDK1.7中,ConcurrentHashMap使用的锁分段技术,将数据分成一段一段的存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据的时候,其他段的数据也能被其他线程访问。 -
那说说JDK1.7中Segment的原理
刚刚说的一段一段就是指Segment,它继承了ReentrantLock,具备锁和释放锁的功能。ConcurrentHashMap只有16个Segment,并且不会扩容,最多可以支持16个线程并发写。 -
JDK1.8的ConcurrentHashMap怎么实现线程安全的
JDK1.8放弃了锁分段的做法,采用CAS和synchronized方式处理并发。以put操作为例,CAS方式确定key的数组下标,synchronized保证链表节点的同步效果。 -
JDK1.8的做法有什么好处呢
- 减少内存开销
假设使用可重入锁,那么每个节点都需要继承AQS,但并不是每个节点都需要同步支持,只有链表的头节点(红黑树的根节点)需要同步,这无疑消耗巨大内存。 - 获得JVM的支持
可重入锁毕竟是API级别的,后续的性能优化空间很小。synchronized则是JVM直接支持的,JVM能够在运行时作出相应的优化措施:锁粗化、锁消除、锁自旋等等。使得synchronized能够随着JDK版本的升级而不改动代码的前提下获得性能上的提升。
- 减少内存开销
-
为什么不推荐使用HashTable呢
HashTable容器使用synchronized来保证线程安全,但在线程竞争激烈的情况下HashTable的效率非常低下。因为多个线程访问HashTable的同步方法时,可能会进入阻塞或轮询状态。如线程1使用put进行添加元素,线程2不但不能使用put方法添加元素,并且也不能使用get方法来获取元素,所以竞争越激烈效率越低。
参考(部分摘抄的文字版权属于原作者):
https://segmentfault.com/a/1190000015907000
https://www.cnblogs.com/zhaojj/p/8942647.html
https://www.cnblogs.com/wfq9330/p/9606472.html
鸡汤:上帝为你关上了一扇门,然后去洗洗睡了。
相关文章
暂无评论...