并发内功-如何确定加什么类型的锁?

前言

在 Java 并发编程（JUC）的学习中，我们往往容易陷入 API 的泥潭：掌握了 synchronized 的原理，背熟了 AQS 的源码，但在面对具体的业务场景时，却依然犹豫不决——“这里到底该用哪种锁？为什么？”

在 JDK 1.8 时代，锁的性能差异已不再像早期那么巨大，选型的核心依据从单纯的“性能”转向了**“场景匹配度”与“代码维护性”**。

本文将摒弃枯燥的 API 罗列，直接提供一套从实战出发的并发工具选型决策指南。

如果你时间紧迫，请直接参考这份选型决策树。在面对线程安全问题时，按顺序自问：

是数据容器（List, Map, Queue）吗？
- KV 存储 → ConcurrentHashMap (首选)
- 需要排序的 KV → ConcurrentSkipListMap
- 读多写极少（如白名单） → CopyOnWriteArrayList
- 生产消费队列 → ArrayBlockingQueue (必须有界)
是单个变量的简单操作（如 +1，赋值）吗？
- 极高并发统计（如接口限流计数） → LongAdder (JDK 1.8+)
- 需要精确值或 CAS (如序列号) → Atomic 系列
读写比例是否非常悬殊（读 >> 写）？
- 追求极致读性能且能容忍代码复杂 → StampedLock (乐观读)
- 常规业务，追求稳健 → ReentrantReadWriteLock
需要高级流程控制（超时、中断、多条件等待）吗？
- 是 → ReentrantLock + Condition
默认选项（终点）：
- 上述都不满足 → synchronized (最简单、最安全、自动挡)

观点：不要因为“它是重量级锁”而不敢用。在 JDK 1.8+ 中，它是默认首选。

早期的 synchronized 确实性能较差，但在 JDK 1.6 之后，JVM 引入了偏向锁、轻量级锁（自旋）、重量级锁的自动升级机制。

口诀：官方原生是默认，自动挡位最省心。若无特殊高级求，synchronized 是冠军。

观点：当 synchronized 的“死等”机制无法满足需求时，才使用它。

synchronized 是霸道的，一旦进入等待队列，要么拿到锁，要么一直死等，不可中断。ReentrantLock 提供了三种核心能力：

快速失败 (Fail-Fast)：tryLock()。尝试拿一下，拿不到就放弃或去做别的事，适合定时任务或自我保护机制。
可中断响应：lockInterruptibly()。允许在等待锁的过程中响应 Thread.interrupt()，适合需要“取消按钮”的交互场景。
多路通知：配合 Condition 可以实现精准唤醒（如只唤醒消费者，不唤醒生产者），这是实现复杂阻塞队列的基础。

必须养成肌肉记忆：锁的释放必须放在 finally 块中。

lock.lock();
try {
    // 业务逻辑
} finally {
    lock.unlock(); // 必须在这里释放！
}

观点：只有在“读多写少”（建议比例 > 10:1）的场景下，读写锁才有意义。

为了解决 RRW 的性能瓶颈，JDK 8 引入了 StampedLock，它支持乐观读 (Optimistic Read)。

观点：如果只是简单的数值更新，没必要动用“锁”这种重型武器。

不要再使用 Vector 或 Hashtable，也不要乱用 Collections.synchronizedList。

容器类型	推荐组件	选型关键点
Map	`ConcurrentHashMap`	默认首选。JDK 1.8 优化为 CAS + synchronized (Node锁)，性能极高。
List	`CopyOnWriteArrayList`	仅限读多写极少（如白名单）。写操作会复制整个数组，频繁写会造成 GC 灾难。
Queue	`ArrayBlockingQueue`	生产环境首选。必须有界！防止消费者宕机导致队列积压引发 OOM。
Queue	`LinkedBlockingQueue`	吞吐量虽高，但默认构造函数是无界的（Integer.MAX_VALUE）。使用时必须手动指定容量。

技术选型没有银弹，只有 Trade-off（权衡）。

希望这篇博文能帮你建立起一套完整的并发工具选型框架。下次面对复杂的线程安全问题时，不再迷茫，能够自信地做出最合理的架构决策。