知识卡片
同步容器锁太粗
内容
早期同步容器（Vector、HashTable、Collections.synchronizedXxx）通常在整个方法上加 synchronized，简单但并发度低：无竞争时是 [[锁会逐级膨胀]] 的偏向锁，一旦竞争就膨胀为重量级锁，抢占释放要经历用户态/内核态切换，拖累吞吐。JUC 容器的思路是缩小冲突范围——复制、分段锁、局部锁配合阻塞语义各自服务不同读写比例，而非一把大锁保护一切。
参考来源
- 位置：《Java高并发核心编程.卷2，多线程、锁、JMM、JUC、高并发设计模式》第7章《JUC容器类》7.1节《线程安全的同步容器类》（源文件：_epub-src/OEBPS/Text/chapter230.xhtml）
- 结论依据：原文说明同步容器“在需要同步访问的方法上添加关键字synchronized”，并指出“一旦发生了线程争用，synchronized会由偏向锁膨胀成重量级锁，在抢占和释放时发生CPU内核态与用户态切换，所以削弱了并发性，降低了吞吐量……因此，为了解决同步容器的性能问题，有了JUC高并发容器”，因此推出本卡结论。
- 原始内容：这些同步容器实现线程安全的方式是：在需要同步访问的方法上添加关键字synchronized……一旦发生了线程争用，synchronized会由偏向锁膨胀成重量级锁，在抢占和释放时发生CPU内核态与用户态切换，所以削弱了并发性，降低了吞吐量，而且会严重影响性能。因此，为了解决同步容器的性能问题，有了JUC高并发容器。