concurrentHashMap 为什么是 CAS+Sychronized 保障线程安全？

[bingoshe]

为什么不是 CAS+CAS Sychronized+Sychronized?

[VinsonGuo]

cas 的性能大于 synchronized，但是 cas 可能会失败（默认应该是自旋 10 次），在失败的情况下再使用 sync

全部用 sync 锁的话，性能太差了

[Leviathann]

cas 在高并发的时候经常比较失败
性能还不如上锁

[fareware]

这不是一面八股文基础题吗，阿里就喜欢这个

[ccde8259]

put/set 用 synchronized 锁头节点不用 CAS，可能考虑原因是对整个链表 /红黑树进行 CAS 代价太大。需要把链表 /红黑树 deep copy 然后进行 compare 和 swap 操作，失败再拷一遍？
rehash 用 CAS 不用 synchronized，可能考虑原因是 CAS 抢占失败代表已经有线程领过了这个任务，没有必要再尝试 CAS 。这里锁并不需要真正获取到，比起 synchronized 进去发现任务没了代价更低。

[hfc]

synchronized 是悲观锁，CAS 是乐观锁，乐观锁适用于竞争较少的情况下。
ConcurrentHashMap 用 synchronized 的地方是锁住 table 上的某个 Node 头节点吧，这个 Node 还会通过 next 连接成链表，那么在链表较长时，其上发生的竞争几率就会比较高，这个时候估计使用悲观锁会比乐观锁效率更高。

[4kingRAS]

http://cs.oswego.edu/pipermail/concurrency-interest/2006-May/subject.html#2484

抛砖引玉一下

[eric96]

可以看下 put 方法，只有在头节点为 null 时候，才是 cas 放入新节点。
否则是对当前节点加锁的