Java并发编程深度解析：把AQS、CAS、死锁一次性讲透，让面试官无话可说
🔥 写在前面：本文全程干货，预计阅读时间30分钟。文章末尾有我整理的「并发编程避坑清单」，来自我踩过的真实坑，建议先收藏慢慢看。
⚠️ 适用人群：准备跳槽的Java工程师、想深入理解并发本质的开发者、正在排查线上死锁问题的运维同学。
一、先灵魂拷问：你真的理解并发吗？
在开始讲技术之前，我想先问你几个问题：
- synchronized和ReentrantLock有什么区别？
- 为什么阿里规范里强制要求开发者使用CountDownLatch而不是Object.wait/notify？
- 死锁的四个必要条件是什么？你线上遇到过死锁吗？怎么排查的？
如果这三个问题你回答不上来，那这篇文章就是为你准备的。
我的经历：21年双十一，凌晨2点接到电话，订单服务全面超时，P99延迟从正常的80ms飙到了30秒。排查了2个小时，最后发现是一个并发更新库存的接口触发了死锁——两个线程互相持有对方的锁，等待对方释放。这就是为什么我今天要把并发编程讲透，不是为了面试，是为了不踩生产事故。
二、CAS：并发编程的基石
2.1 什么是CAS？
CAS全称 Compare And Swap（比较并交换），是CPU提供的原子操作指令。听起来高大上，我用大白话解释：
你去银行取钱，账户余额1000元，你想取500。CAS的操作是：先读取余额1000，然后只有当余额==1000时才执行扣款。如果在这个过程中有人改了余额（比如充了100），CAS会失败，然后你重新读取（1000+100=1100），再重试。
这就是乐观锁的核心思想。
2.2 Java中的CAS实现
/**
* 典型的CAS使用场景： AtomicInteger的incrementAndGet()
* 这个方法是线程安全的，不需要加锁
*/
public final int incrementAndGet() {
for (;;) {
int current = get(); // 1. 读取当前值
int next = current + 1; // 2. 准备新值
if (compareAndSet(current, next)) { // 3. CAS原子替换
return next; // 4. 成功就返回
}
// 5. 失败就重试（自旋）
}
}
为什么不用synchronized？
// 用synchronized实现（性能差，每次只能一个线程进入）
public synchronized int increment() {
return ++value;
}
// 用CAS实现（无锁，性能高，并发能力更强）
public final int increment() {
return UNSAFE.getAndAddInt(this, VALUE_OFFSET, 1) + 1;
}
2.3 面试现场：CAS的三大问题
面试官可能这样问：
"CAS有ABA问题，你知道怎么解决吗？"
普通回答：
"ABA问题是指...可以用版本号解决..."
满分回答（带实战）：
"ABA问题确实存在。比如线程A读取栈顶是A，准备出栈，这时候线程B把A出栈又压入C，再压入A。线程A回来发现栈顶还是A，就出栈了——但实际上B已经动过了。
线上我们遇到过一个case：用户下单时用CAS校验库存，买了100件商品。库存从100→0→100，线程以为没变化就重复扣了两次。后来用AtomicStampedReference加了版本号解决：
// 带版本号的CAS，防止ABA问题 AtomicStampedReference<Integer> stock = new AtomicStampedReference<>(100, 1); // 扣库存时同时检查版本号 public boolean deductStock(int count) { int[] stamp = new int[1]; Integer current = stock.get(stamp); if (current < count) return false; return stock.compareAndSet(current, current - count, stamp[0], stamp[0] + 1); } ```"
三、AQS：JDK并发工具的"发动机"
3.1 从一个问题出发
先思考：为什么JDK里的ReentrantLock、CountDownLatch、CyclicBarrier、Semaphore都能实现各种复杂的同步功能？它们底层是怎么做到的？
答案：它们都基于同一个"发动机"——AbstractQueuedSynchronizer，简称AQS。
3.2 AQS的工作原理
我用图来说明：
┌─────────────────────────────────────────────────────────────┐
│ AQS 队列同步器 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ state=0（资源可用） │
│ │ 线程A │ ───────────────────────────────────────────▶│
│ └──────────┘ 获取锁成功 │
│ │
│ ┌──────────┐ state=1（资源被占用） │
│ │ 线程B │ ───▶ 加入CLH队列，等待唤醒 │
│ └──────────┘ │
│ │
│ ┌──────────┐ │
│ │ 线程C │ ───▶ 队列中等待（FIFO顺序） │
│ └──────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
核心原理：
- state变量：表示资源状态。0=可用，>0=被占用（可重入锁支持多次获取）
- CLH队列：一个FIFO双向链表，存储等待线程的节点
- 两种模式：独占模式（一次只能一个线程，如ReentrantLock）和共享模式（多个线程同时访问，如Semaphore/CountDownLatch）
3.3 源码解析：ReentrantLock的加锁流程
先看公平锁的实现：
// ReentrantLock.FairSync.tryAcquire()
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState(); // 获取当前状态
if (c == 0) {
// 关键判断：hasQueuedPredecessors()
// 意思是：队列里有没有在我前面等待的线程？
// 如果有，我不能插队（公平锁）
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
} else if (current == getExclusiveOwnerThread()) {
// 可重入：同一个线程可以多次获取
int nextc = c + acquires;
setState(nextc);
return true;
}
return false;
}
我踩过的坑：
曾经遇到线上锁竞争严重，发现用
new ReentrantLock()创建的是非公平锁。非公平锁虽然性能好（减少线程切换），但会导致"饥饿"问题——有些线程可能永远抢不到锁。后来改用new ReentrantLock(true)强制公平模式，性能降了15%，但系统的响应变得可预测了。
3.4 CountDownLatch vs CyclicBarrier：别再用错了
/**
* 场景：等所有服务启动完成后再开始测试
*
* ❌ 错误用法：Object.wait/notify
* 问题是：notify是随机唤醒的，不知道该等几个线程
*/
synchronized (lock) {
count--;
if (count == 0) lock.notifyAll();
}
/**
* ✅ 正确用法：CountDownLatch
* 场景：主线程等待N个子任务完成
*/
CountDownLatch latch = new CountDownLatch(5);
for (int i = 0; i < 5; i++) {
final int taskId = i;
new Thread(() -> {
startService(taskId);
latch.countDown(); // 子任务完成后计数-1
}).start();
}
latch.await(); // 主线程阻塞，等计数归零
System.out.println("所有服务启动完成，开始压测！");
关键区别：
| 特性 | CountDownLatch | CyclicBarrier |
|---|---|---|
| 能否重置 | ❌ 不能，一次性 | ✅ 能，可循环使用 |
| 谁等待 | 主线程等待子任务 | 子任务之间互相等待 |
| 典型场景 | 主线程等子任务完成 | N个线程互相等，都到了才继续 |
我踩过的坑：
压测场景里，需要等所有请求发完再汇总结果。我一开始用的CyclicBarrier，结果发现每次汇总后还需要再发下一批，CyclicBarrier在await()后自动重置，可以继续用，这正是它擅长的场景——反而CountDownLatch用完就废了。
四、线程池：别再乱用了
4.1 为什么不能随便new Thread？
// ❌ 错误示范：每个任务创建一个线程
for (int i = 0; i < 10000; i++) {
new Thread(() -> {
doSomething();
}).start();
}
// 问题：
// 1. 线程创建和销毁有开销（500微秒~2毫秒）
// 2. 线程数量不可控，内存溢出
// 3. 无法统一管理（线程状态、监控）
4.2 线程池的正确打开方式
阿里巴巴规范要求的写法：
/**
* 阿里规范：线程池必须通过ThreadPoolExecutor手动创建
* 原因：Executors返回的线程池有OOM风险
*/
public class ThreadPoolBuilder {
// CPU密集型：线程数 = CPU核数 + 1
private static final int CPU_COUNT =
Runtime.getRuntime().availableProcessors();
// IO密集型：线程数 = CPU核数 * 2（或者用公式：CPU核数/(1-阻塞系数)）
private static final int IO_THREADS = CPU_COUNT * 2;
/**
* 核心业务线程池
* - 核心线程数：8
* - 最大线程数：16（高峰时扩展）
* - 队列长度：1000
* - 拒绝策略：CallerRunsPolicy（让调用方自己执行）
*/
public static final ThreadPoolExecutor ORDER_POOL =
new ThreadPoolExecutor(
8, // corePoolSize
16, // maximumPoolSize
60L, TimeUnit.SECONDS, // 空闲线程存活时间
new LinkedBlockingQueue<>(1000), // 队列
new NamedThreadFactory("order-"), // 线程工厂
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);
}
4.3 线程池参数设置：我是怎么调的
实战经验总结：
┌────────────────────────────────────────────────────────────────┐
│ 线程池参数配置公式 │
├────────────────────────────────────────────────────────────────┤
│ │
│ CPU密集型任务（如复杂计算、加密解密）： │
│ ├─ 核心线程数 = CPU核心数 + 1 │
│ ├─ 队列长度：可以小一些（计算快，不容易积压） │
│ └─ 推荐：Runtime.getRuntime().availableProcessors() + 1 │
│ │
│ IO密集型任务（如数据库查询、HTTP调用、文件读写）： │
│ ├─ 核心线程数 = CPU核心数 * 2 │
│ ├─ 队列长度：要大（IO慢，容易积压） │
│ └─ 推荐：CPU核心数 * 2，或者使用公式 N/(1-0.9) ≈ 10N │
│ │
│ 混合型任务：分线程池处理 │
│ ├─ CPU线程池（核心数+1）处理计算任务 │
│ └─ IO线程池（核心数*2）处理IO任务 │
│ │
└────────────────────────────────────────────────────────────────┘
我踩过的坑：
双十一前，我把线程池核心线程数设成100，想着能多处理请求。结果压测时发现：
- CPU全红了（线程上下文切换开销巨大）
- 延迟不降反升
后来改成
CPU核数*2=32，吞吐量反而提升了40%。教训：线程池不是越大越好，超过一定数量后，上下文切换的开销会吃掉所有性能收益。
五、死锁：线上最可怕的"隐形杀手"
5.1 死锁的四个必要条件（面试必背）
┌─────────────────────────────────────────────────────────────┐
│ 死锁四要素（缺一不可） │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1️⃣ 互斥条件：资源一次只能被一个线程占用 │
│ ↓ │
│ 2️⃣ 持有并等待：线程持有资源的同时，请求其他资源 │
│ ↓ │
│ 3️⃣ 不可抢占：资源不能被强制从线程中剥夺 │
│ ↓ │
│ 4️⃣ 循环等待：线程之间形成循环等待链 A→B→C→A │
│ │
│ ✅ 打破任一条件即可防止死锁 │
│ │
└─────────────────────────────────────────────────────────────┘
5.2 真实案例：库存与账户的死锁
/**
* 我在线上踩过的死锁案例：
*
* 场景：用户下单，扣库存 + 扣余额
*
* 线程A：先扣库存（成功），再扣余额（等待线程B释放账户锁）
* 线程B：先扣余额（成功），再扣库存（等待线程A释放库存锁）
*
* 结果：死锁！订单超时，用户体验极差
*/
public class OrderService {
// 库存锁
private final ReentrantLock stockLock = new ReentrantLock();
// 账户锁
private final ReentrantLock accountLock = new ReentrantLock();
// ❌ 错误写法：两个方法加锁顺序不同
public boolean createOrder_stockFirst(Long userId, Long productId) {
stockLock.lock();
try {
// 扣库存...
// 假设这里耗时10ms
accountLock.lock(); // B线程在这里等待
try {
// 扣余额...
} finally {
accountLock.unlock();
}
} finally {
stockLock.unlock();
}
return true;
}
public boolean createOrder_accountFirst(Long userId, Long productId) {
accountLock.lock();
try {
// 扣余额...
stockLock.lock(); // A线程在这里等待
try {
// 扣库存...
} finally {
stockLock.unlock();
}
} finally {
accountLock.unlock();
}
return true;
}
}
5.3 死锁的解决方案
方案一：固定加锁顺序（最简单）
/**
* 解决方案：所有地方都按统一顺序加锁
* 先锁accountLock，再锁stockLock
*/
public boolean createOrder_fixed(Long userId, Long productId) {
// 按固定顺序获取锁，永远不会循环等待
accountLock.lock();
try {
stockLock.lock();
try {
// 扣库存 + 扣余额
return doOrder(userId, productId);
} finally {
stockLock.unlock();
}
} finally {
accountLock.unlock();
}
}
方案二：tryLock超时 + 回滚（更优雅）
/**
* 更好的方案：tryLock超时，自动回滚
*
* 适用场景：锁的粒度复杂，无法统一顺序
*/
public boolean createOrder_tryLock(Long userId, Long productId) {
long start = System.currentTimeMillis();
long timeout = 3000; // 3秒超时
while (true) {
if (accountLock.tryLock()) {
try {
if (stockLock.tryLock(timeout, TimeUnit.MILLISECONDS)) {
try {
return doOrder(userId, productId);
} finally {
stockLock.unlock();
}
}
} finally {
accountLock.unlock();
}
}
// 超时了，回滚整个事务
if (System.currentTimeMillis() - start > timeout) {
rollback(userId, productId);
return false;
}
// 等一下再重试
Thread.sleep(50);
}
}
5.4 死锁排查：JDK自带的工具
# 第一步：找到Java进程PID
jps -l | grep OrderService
# 第二步：打印线程Dump（关键！）
jstack <PID> > thread_dump.txt
# 第三步：搜索死锁关键字
grep -A 10 "Found one Java-level deadlock" thread_dump.txt
Dump文件里的死锁特征：
Found one Java-level deadlock:
=============================
"Thread-A" Id=20 in BLOCKED, waiting for monitor info
java.lang.Thread.State: BLOCKED
- waiting to lock <0x00000000eb83a800> (a java.lang.Object) ← 等待库存锁
- locked <0x00000000eb83a810> (a java.lang.Object) ← 持有账户锁
"Thread-B" Id=21 in BLOCKED, waiting for monitor info
java.lang.Thread.State: BLOCKED
- waiting to lock <0x00000000eb83a810> (a java.lang.Object) ← 等待账户锁
- locked <0x00000000eb83a800> (a java.lang.Object) ← 持有库存锁
六、生产环境避坑清单（带血经验）
┌─────────────────────────────────────────────────────────────────────┐
│ ⚠️ 并发编程生产环境避坑清单（个人踩坑汇总） │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ❌ 不要这样用： │
│ ───────────────── │
│ 1. 用Executors.newFixedThreadPool()创建线程池 │
│ → 队列是Integer.MAX_VALUE，OOM风险 │
│ │
│ 2. 在锁内执行耗时操作（如HTTP调用、数据库查询） │
│ → 其他线程全部阻塞，系统假死 │
│ │
│ 3. 在锁内调用其他服务的锁 │
│ → 分布式死锁 │
│ │
│ 4. ReentrantLock忘记在finally里unlock() │
│ → 锁泄漏，高并发下迟早出事 │
│ │
│ 5. ConcurrentHashMap调用复合操作（如++i） │
│ → 不是线程安全的！要包装成原子操作 │
│ │
│ ✅ 正确做法： │
│ ───────────────── │
│ 1. 用ThreadPoolExecutor手动创建线程池 │
│ → 设置合理的coreSize/maxSize/queueSize │
│ │
│ 2. 锁的粒度要尽量小 │
│ → 只锁真正需要同步的代码 │
│ │
│ 3. 优先用读写锁（ReentrantReadWriteLock） │
│ → 读多写少场景性能提升10倍 │
│ │
│ 4. 用tryLock() + 超时处理复杂的锁依赖 │
│ → 防止死锁自动恢复 │
│ │
│ 5. 线程池拒绝策略用CallerRunsPolicy │
│ → 不会丢任务，让调用方降级处理 │
│ │
│ 📊 性能数据（我的实测）： │
│ ───────────────── │
│ synchronized → ReentrantLock：性能提升 20-30% │
│ 单线程池 → 多线程池（按类型分）：性能提升 3-5倍 │
│ CPU密集线程数 N → 2N：性能提升 40%（IO密集） │
│ │
└─────────────────────────────────────────────────────────────────────┘
七、面试加分项：说点面试官爱听的
7.1 灵魂拷问的标准答案
Q：synchronized和ReentrantLock有什么区别？
"表面上是用法不同（synchronized自动加锁释放，Lock手动控制），但核心区别有三：
第一，底层实现不同。synchronized是JVM层面的重量级锁，用的是对象头里的Mark Word；ReentrantLock是JDK层面的，用的是AQS+CAS。
第二，功能丰富度不同。ReentrantLock支持公平/非公平切换，支持tryLock超时，支持多个条件变量（Condition）。synchronized做不到这些。
第三，性能差异。JDK 1.6之前synchronized确实慢，但之后做了大量优化（偏向锁、轻量级锁、自旋锁），现在差距不大。我查过资料，在低并发场景下synchronized反而更快，因为不用CAS自旋开销。
实际项目中，我一般这样选：简单同步用synchronized（比如单对象状态保护），复杂场景用ReentrantLock（比如需要tryLock、需要读锁分离）。"
7.2 你可以主动补充的点
"对了，说到并发，我还看过Disruptor的源码，它用RingBuffer和CAS实现高性能队列，吞吐量比JDK的BlockingQueue高一个数量级。如果面试官感兴趣我可以展开讲。"
八、总结
┌─────────────────────────────────────────────────────────────────┐
│ 本文核心知识点回顾 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1️⃣ CAS原理：Compare And Swap，乐观锁，ABA问题用版本号解决 │
│ │
│ 2️⃣ AQS核心：state变量 + CLH队列，所有并发工具的底层支撑 │
│ │
│ 3️⃣ ReentrantLock：可重入锁，支持公平/非公平，tryLock超时 │
│ │
│ 4️⃣ CountDownLatch vs CyclicBarrier：一次性 vs 可循环 │
│ │
│ 5️⃣ 线程池配置：CPU密集 N+1，IO密集 2N，队列长度看任务特性 │
│ │
│ 6️⃣ 死锁解决：固定加锁顺序 / tryLock超时回滚 │
│ │
│ 7️⃣ 排查工具：jstack + jvisualvm + Arthas │
│ │
└─────────────────────────────────────────────────────────────────┘
💬 今日话题
你在项目中遇到过哪些并发问题？是怎么排查和解决的？
欢迎评论区分享你的经历，如果是典型问题我会整理成后续文章！
如果这篇文章对你有帮助，点赞 + 收藏是对我最大的支持！
📚 相关好文推荐：
- 原创不易，转载请注明出处
