用并发容器替代手动加锁是降低Java并发复杂度、规避死锁最有效的方式：ConcurrentHashMap、CopyOnWriteArrayList等内置线程安全机制，避免竞态与死锁，配合不可变对象和ThreadLocal可进一步减少共享。
直接用并发容器替代手动加锁，是降低 Java 并发代码复杂度和规避死锁最有效、最落地的方式。核心逻辑很简单：把“自己管同步”变成“交给 JDK 管同步”，既省心又可靠。
优先选用线程安全的并发集合类
JDK 的 java.util.concurrent 包不是锦上添花，而是为多线程场景而生。它们内部已封装了细粒度锁、CAS、无锁算法等机制，开发者调用方法时无需额外同步。
-
ConcurrentHashMap替代HashMap：put/get 本身线程安全；复合操作如computeIfAbsent、merge也自带原子性，避免“先查后 put”的竞态。 -
CopyOnWriteArrayList替代ArrayList：适合监听器列表、配置项订阅等读极多、写极少的场景；遍历过程不会抛ConcurrentModificationException。 -
BlockingQueue（如LinkedBlockingQueue、ArrayBlockingQueue）替代手动同步的队列：生产者调用put()自动阻塞，消费者调用take()自动等待，不用手写wait/notify或ReentrantLock + Condition。 -
ConcurrentLinkedQueue用于高吞吐、允许弱一致性（如日志缓冲）的无锁队列；ConcurrentSkipListMap提供线程安全的有序 Map。
避免用 Collections.synchronizedXXX 包装普通集合
立即学习“Java免费学习笔记（深入）”；
这类包装看似“一步到位”，实则埋雷：
- 单个方法（如
add()）是同步的，但迭代必须手动加锁：List<String> list = Collections.synchronizedList(new ArrayList<>()); // ❌ 错误：迭代时不加锁，可能抛 ConcurrentModificationException for (String s : list) { ... } // ✅ 正确：必须显式同步整个遍历过程 synchronized (list) { for (String s : list) { ... } } - 复合逻辑（如“若不存在则添加”）不是原子的，仍需外部加锁，反而更难维护。
- 所有操作串行化，性能接近单线程，失去并发意义。
用并发容器天然规避常见死锁诱因
手动加锁容易出错，比如嵌套锁顺序不一致、锁范围过大、忘记释放、在锁内调用外部方法等。而并发容器：
- 不暴露锁对象，无法写出
synchronized(a); synchronized(b)这类交叉加锁； - 没有
wait/notify调用链，杜绝因条件判断与唤醒不同步导致的永久等待； - 所有操作边界清晰，没有“锁中锁”或“锁中 IO”等高风险模式。
配合不可变性与 ThreadLocal 进一步减少共享
并发容器解决的是“共享可变状态”的并发问题，但最优解其实是“不共享”：
- 用
Collections.unmodifiableList()、ImmutableList.of()创建不可变集合，彻底消除写竞争； - 对线程私有数据（如解析上下文、临时缓存），优先用
ThreadLocal，避免跨线程同步； - 在任务边界（如一次 HTTP 请求）内使用局部变量+不可变对象，比全局并发容器更轻量、更安全。
本质上，并发容器不是万能解药，而是把“同步的复杂性”下沉到成熟、压测过、持续演进的 JDK 实现里。你写的每一行 map.put(key, value)，背后已是桶级锁或 CAS 的精密协作——你只管业务，它来扛并发。
