Java多线程集合选型需按场景匹配：synchronizedList适用于低并发简单场景，但操作串行且迭代需手动同步；ConcurrentHashMap适合高并发键值操作，读无锁、写局部锁；CopyOnWriteArrayList适用于读远多于写的静态列表；BlockingQueue专用于生产者-消费者模型。
Java多线程中处理集合，关键不是“能不能用”，而是“在哪种场景下用得对”。synchronizedList这类同步包装类能用，但容易成为性能瓶颈；ConcurrentHashMap、CopyOnWriteArrayList等并发容器设计更精细，但并非万能——选错反而引入隐患。
什么时候可以用synchronizedList
适合低并发、逻辑简单、改造成本敏感的场景。比如内部工具类、单机批处理脚本、测试环境模拟数据等。
- 它只是给每个方法加了对象级synchronized锁，所有操作串行执行
- 迭代时必须手动同步：synchronized(list) { for (e : list) {...} }，否则仍可能抛ConcurrentModificationException
- 不支持复合原子操作（如“若不存在则添加”），需额外加锁或重构
ConcurrentHashMap更适合高并发键值场景
它不是“加锁版HashMap”，而是从结构上优化：JDK 8后基于CAS + synchronized锁单个桶节点，读操作完全无锁，写操作只锁局部链表头或红黑树根。
- put、get、computeIfAbsent等方法本身是线程安全且原子的
- 遍历过程不会因其他线程修改而失败，也不会阻塞写操作
- 比HashTable和synchronizedMap吞吐量高数倍，尤其在读多写少或写操作分散时
CopyOnWriteArrayList适用于读远大于写的列表
典型如事件监听器列表、配置白名单、静态路由表——这些结构初始化后极少变动，但被大量线程频繁遍历。
立即学习“Java免费学习笔记（深入）”；
- 每次add/remove/set都会复制整个数组，写操作开销大，不适合高频更新
- 读操作零同步、零阻塞，迭代过程绝对安全，无需额外同步块
- 注意内存放大：大容量列表+频繁写入可能触发频繁GC
别忽略BlockingQueue这类专用并发结构
如果业务本质是生产者-消费者模型（如任务分发、日志缓冲、消息中转），优先考虑BlockingQueue家族，而非强行用List或Map模拟队列。
- LinkedBlockingQueue使用双锁（takeLock/writeLock分离），吞吐量高于ArrayBlockingQueue
- ArrayBlockingQueue基于数组+单锁，内存连续、缓存友好，适合固定容量且争用可控的场景
- ConcurrentLinkedQueue无锁、无界、FIFO，适合极高并发、容忍短暂不一致的场景
