搞定镇楼：3步解决代码报错与高频面试题

刚把网上抄来的“镇楼”代码贴进项目，直接报 NullPointerException 或者编译失败，对着满屏红字发呆？这种“复制即崩”的绝望感，在开发圈太常见了。很多新手甚至老手，在准备高频面试题时，往往死记硬背了概念，却拿不准实际落地时的边界条件。

“镇楼”这个词，在技术语境里其实是个双关。一方面，它指代博客或社区里置顶展示的核心代码片段，通常是解决复杂问题的“压舱石”；另一方面，在 Java 并发编程或底层机制的讨论中，它常被用来隐喻那些需要“压住阵脚”的关键同步原语，比如 synchronized 关键字、ReentrantLock 或者更底层的 CAS 操作。今天咱们不聊虚的，专门拆解这个“镇楼”背后的技术逻辑，对比几种主流实现方式，看看为什么你的代码跑不通，以及面试官到底想考什么。

各自定位：谁是真正的压舱石

在深入代码之前，得先搞清楚几个核心概念的定位。很多开发者混用 synchronized、ReentrantLock 和 AtomicXxx，导致性能瓶颈或死锁，根源就在于没搞懂它们的“性格”。

synchronized 是 JVM 层面的内置关键字，它的“镇楼”地位在于简单、安全、自动释放。你只需要在方法或代码块上加个注解，JVM 就会帮你处理锁的获取与释放。它的定位是默认首选，除非你有特殊需求，否则它是最不容易出错的选择。

ReentrantLock 是 java.util.concurrent 包下的显式锁。它的定位是高自由度。它允许你指定公平锁、尝试非阻塞获取锁、设置超时时间，甚至支持多个 Condition 对象。当你需要更精细的控制权时，它才是那个能“镇住”复杂业务逻辑的角色。

而 AtomicXxx 系列（如 AtomicInteger）则是无锁编程的代表。它的定位是高性能计数器。通过 CAS（Compare-And-Swap）指令，它在高并发下避免了线程阻塞，适合高频读写但逻辑简单的场景。

这三者看似都能“镇楼”，但适用场景截然不同。选错了，不仅性能受损，还可能引入难以排查的并发 Bug。

核心差异：一张表看懂选型关键

为了让大家看得更清楚，我把这三者的核心差异整理成了下表。这张表也是面试中经常被问到的对比维度，建议截图保存。

维度	synchronized	ReentrantLock	AtomicXxx (CAS)
实现层级	JVM 字节码层 (monitorenter/monitorexit)	JDK 层 (AQS 状态机)	CPU 指令层 (CAS)
锁粒度	方法级 / 代码块级	代码块级 (必须手动 lock/unlock)	单变量原子操作
阻塞行为	线程阻塞 (等待队列)	线程阻塞 / 可尝试非阻塞 / 可超时	自旋 (不阻塞，但耗 CPU)
公平性	非公平	可配置 (默认非公平)	非公平
中断响应	不支持 (InterruptedException 无法中断)	支持 (lockInterruptibly)	不支持
条件变量	单一 (wait/notify)	多个 (newCondition)	无
性能趋势	JDK 6+ 优化后大幅提升 (偏向/轻量级锁)	稳定，高竞争下表现优异	低竞争下极快，高竞争下自旋损耗大
适用场景	短临界区、通用场景	复杂业务逻辑、需要精细控制	高频计数、简单状态切换

注意看“中断响应”这一行。很多线上事故就是因为 synchronized 块里的线程被阻塞，外部想中断却中断不了，导致线程池耗尽。而在 Stack Overflow 上，关于“如何优雅退出 synchronized 块”的提问从未停止，答案往往指向 ReentrantLock。

代码写法对比：从报错到修复

理论讲再多，不如看代码。我们模拟一个典型的“库存扣减”场景，这是电商系统里最常见的并发痛点，也是高频面试题的重灾区。

场景一：使用 synchronized (最稳但不够灵活)

这是很多新手第一反应写出的代码。看似没问题，但在高并发下，性能会急剧下降，且无法感知线程是否被中断。

public class InventorySynchronized {private int stock = 100;public synchronized boolean deductStock(int amount) {// 模拟耗时操作，增加锁持有时间try {Thread.sleep(10); } catch (InterruptedException e) {// 痛点：这里捕获了异常，但锁依然持有，且无法主动释放e.printStackTrace();}if (stock >= amount) {stock -= amount;return true;}return false;}
}

逐行解析：

synchronized 修饰方法，意味着整个方法体都是临界区。
Thread.sleep 模拟业务逻辑耗时。在实际项目中，这里可能是数据库查询或远程调用。
核心问题：如果线程在 sleep 时被中断，InterruptedException 被捕获，但 synchronized 锁不会自动释放，直到方法执行完毕。这导致其他线程排队等待，吞吐量骤降。

场景二：使用 ReentrantLock (灵活且可控)

这是更推荐的写法，尤其是在需要处理异常和超时的场景。

import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.locks.Condition;public class InventoryReentrantLock {private int stock = 100;private final ReentrantLock lock = new ReentrantLock(true); // 使用公平锁private final Condition stockCondition = lock.newCondition();public boolean deductStock(int amount, long timeoutMs) {boolean acquired = false;try {// 尝试获取锁，超时时间 500ms，避免线程无限阻塞acquired = lock.tryLock(timeoutMs, java.util.concurrent.TimeUnit.MILLISECONDS);if (!acquired) {return false; // 获取锁失败，直接返回，不阻塞线程}if (stock >= amount) {stock -= amount;stockCondition.signalAll(); // 唤醒等待库存恢复的线程return true;}return false;} catch (InterruptedException e) {Thread.currentThread().interrupt(); // 恢复中断标志return false;} finally {// 关键：必须在 finally 中释放锁，防止死锁if (acquired) {lock.unlock();}}}
}

逐行解析：

new ReentrantLock(true) 创建公平锁，避免线程饥饿。
tryLock 带超时参数，这是 synchronized 做不到的。如果 500ms 没拿到锁，直接返回，保护了线程池。
finally 块中释放锁。这是 ReentrantLock 最大的陷阱：必须手动释放。如果你忘了写 unlock()，程序不会报错，但后续所有线程都会死等，直到 OOM。
Condition 允许更精细的通知机制，比 wait/notify 强大得多。

场景三：使用 AtomicXxx (无锁但需权衡)

对于简单的计数器，用锁是大材小用，但 CAS 有“ABA 问题”和“自旋损耗”。

import java.util.concurrent.atomic.AtomicInteger;public class InventoryAtomic {private final AtomicInteger stock = new AtomicInteger(100);public boolean deductStock(int amount) {while (true) {int current = stock.get();if (current < amount) {return false;}// 尝试将 current 更新为 current - amountif (stock.compareAndSet(current, current - amount)) {return true;}// 如果 CAS 失败，说明有其他线程修改了 stock，继续自旋重试}}
}

逐行解析：

compareAndSet (CAS) 是原子操作。
while(true) 是自旋。在低并发下，这种重试很快；但在高并发下，多个线程同时失败，会导致 CPU 空转，功耗飙升。
适用限制：CAS 适合“读多写少”或“单变量更新”。如果你的业务逻辑涉及多个变量（比如扣减库存的同时增加销量），CAS 就无能为力了，必须回到锁的方案。

进阶技巧与避坑：那些年踩过的坑

在实际项目中，仅仅会用 API 是不够的。Stack Overflow 上有大量关于“锁升级”和“伪共享”的讨论，这些细节往往决定了系统的高下。

1. 锁膨胀与偏向锁

JDK 6 之前，synchronized 是重锁，性能很差。JDK 6 引入了偏向锁、轻量级锁和重量级锁的自适应升级机制。

避坑：不要在 synchronized 块内执行远程调用或长耗时 IO。这会导致锁从偏向锁直接升级到重量级锁，且难以降级。
建议：尽量缩小临界区，只把需要共享的资源保护起来，其他逻辑移到锁外。

2. ReentrantLock 的“死锁”陷阱

ReentrantLock 必须手动释放。常见的错误是：

lock.lock();
doSomething();
lock.unlock();
// 如果 doSomething() 抛出异常，unlock() 不会执行，锁永久持有

正确做法：永远使用 try-finally 结构，或者使用 lock.lockInterruptibly() 配合 try-catch-finally。

3. CAS 的 ABA 问题

假设线程 1 读取值为 A，线程 2 将值改为 B 再改回 A，线程 1 执行 CAS 时发现值还是 A，于是操作成功。但如果 A 和 B 代表不同的状态（比如链表节点的指针），这就出大问题了。 解决方案：使用 AtomicStampedReference，给每个值加一个版本号，CAS 时同时比较值和版本号。

4. 高频面试题中的“陷阱”

面试官常问：“synchronized 和 volatile 有什么区别？”

volatile 只保证可见性和有序性，不保证原子性。
synchronized 保证可见性、有序性和原子性。
进阶问法：“volatile 能替代 synchronized 吗？” 答案是不能，除非你的操作是单条原子指令（如 AtomicInteger）。

选型建议：如何做出正确决策

面对“镇楼”级别的并发代码，选型没有绝对的对错，只有合适与否。以下是我的实战选型建议：

默认选择 synchronized：
- 如果你的业务逻辑简单，临界区短（几行代码），且不需要超时、中断或公平锁，直接用 synchronized。JVM 优化得很好，写起来也最不容易出错。
- 理由：代码简洁，JIT 编译器优化充分，维护成本低。
复杂逻辑选 ReentrantLock：
- 当需要以下任一功能时：
  - 需要超时获取锁（防止线程无限阻塞）。
  - 需要响应中断（lockInterruptibly）。
  - 需要多个条件变量（Condition）。
  - 需要公平锁（避免线程饥饿）。
- 理由：显式控制，功能强大，适合核心业务逻辑。
高频计数选 AtomicXxx：
- 当操作是单变量（如计数器、标志位），且并发量极高，逻辑极简时。
- 理由：无锁，性能最高。
- 警告：不要用它来处理复杂的多步操作，否则必须配合 AtomicReference 或 AtomicStampedReference，复杂度会急剧上升。
避免混合使用：
- 不要在一个类中同时使用 synchronized 和 ReentrantLock 保护同一个资源。这会导致锁状态混乱，极易引发死锁。