1. 项目概述从一把锁到并发世界的秩序在Java的世界里尤其是在处理高并发、高性能的系统时“锁”这个概念就像现实世界中的交通信号灯。想象一下一个十字路口没有红绿灯所有车辆都想同时通过结果必然是混乱的碰撞和堵塞。程序中的共享资源比如一个银行账户的余额、一个电商商品的库存就是那个十字路口。当多个线程可以理解为多个并发的“车辆”试图同时修改这个余额或库存时如果没有“锁”这个信号灯来协调数据就会出错账户余额可能变成负数商品库存可能超卖。这就是并发编程中最核心、也最令人头疼的问题数据竞争。我接触过不少项目从早期的单机多线程任务调度到如今动辄每秒数万请求的分布式微服务锁的使用贯穿始终。新手开发者往往对synchronized关键字浅尝辄止遇到性能瓶颈或死锁就束手无策而资深工程师则能像老练的交通指挥官根据路况业务场景灵活选用信号灯乐观锁、交通协管CAS操作、甚至区域限行读写锁等不同策略在保证安全数据一致性的前提下最大化通行效率系统吞吐量。今天我们就来彻底拆解Java中的锁不光是知道有哪些锁更要明白在什么路口、什么时间、该用哪一把锁以及如何避免锁带来的“交通瘫痪”死锁和“拥堵”性能瓶颈。2. 锁的核心原理与内存模型基础要理解锁必须先踏入Java内存模型JMM这个领域。JMM定义了线程如何以及何时可以看到其他线程修改过的共享变量这直接关系到锁的可见性和有序性保障。2.1 可见性、原子性与有序性并发问题的三座大山可见性问题就像一个办公室里的公告板。线程A更新了公告板上的数据修改了共享变量但线程B在自己的小隔间里CPU缓存看到的可能还是旧的数据。synchronized和volatile关键字以及我们今天讨论的所有锁一个核心作用就是强制线程去读取主内存中的最新值保证修改能被其他线程立刻看到。原子性问题可以类比为“从ATM取钱”这个操作。它包含“查询余额”、“计算新余额”、“吐出钞票”、“更新余额”多个步骤。如果两个线程同时取钱且这些步骤被打断交织就可能发生“余额扣了一次钱却取了两份”的灾难。锁通过互斥执行将这一系列操作打包成一个不可分割的整体从而保证了原子性。有序性问题则更为微妙。为了优化性能编译器和处理器可能会对指令进行重排序。在单线程下这没问题但在多线程下重排序可能导致意想不到的结果。JMM通过happens-before规则来定义内存操作的偏序关系而锁的释放和获取正是建立happens-before关系的关键操作之一。当一个线程释放锁时它在该锁保护下的所有写操作对后续获取同一把锁的线程来说都是可见且有序的。2.2 锁在JMM中的实现内存屏障与同步语义锁的实现底层依赖于内存屏障。你可以把内存屏障理解为一道“栅栏”它确保屏障前的写操作必须先于屏障后的读/写操作被刷新到主内存并被其他处理器看到。synchronized关键字和java.util.concurrent.locks.Lock接口的实现在进入临界区加锁和退出临界区解锁时都会插入相应强度LoadLoad, StoreStore, LoadStore, StoreLoad的内存屏障。例如ReentrantLock的lock()操作内部包含了类似acquire语义的内存屏障它禁止该操作之后的读/写操作被重排序到lock()之前。而unlock()操作则包含了release语义的内存屏障它禁止该操作之前的读/写操作被重排序到unlock()之后。这一前一后两道屏障就清晰地围出了一块“安全区”保证了临界区内操作的原子性和可见性。注意理解JMM和内存屏障是深入并发编程的基石。很多诡异的并发Bug比如“明明已经设置了标志位但另一个线程就是看不到”其根源往往在于对可见性和有序性的忽视。不要满足于“代码能跑”要追问“为什么这样跑是安全的”。3. Java内置锁synchronized的深度剖析synchronized是Java语言层面提供的互斥锁也是最常用、最基础的锁。它的使用看似简单但内部机制却经历了显著的优化。3.1 使用方式与锁对象synchronized主要有三种用法修饰实例方法锁定的是当前实例对象this。public synchronized void add() { // 临界区代码 }修饰静态方法锁定的是当前类的Class对象。public static synchronized void staticAdd() { // 临界区代码 }修饰代码块需要显式指定锁对象灵活性最高。public void method() { // 非同步代码... synchronized (lockObject) { // 临界区代码 } // 非同步代码... }关键点锁住的是对象而不是代码。所有需要互斥访问的线程必须竞争同一个对象上的锁。如果线程A锁住了对象O1线程B锁住了对象O2即使它们执行的是同一段同步代码也不会互斥。3.2 锁升级过程偏向锁、轻量级锁与重量级锁在Java早期版本synchronized是纯粹的“重量级锁”直接向操作系统申请互斥量涉及用户态到内核态的切换性能开销很大。但从Java 6开始JVM引入了大幅度的优化其核心是锁升级机制目的是在无竞争或低竞争场景下减少开销。锁的信息存储在Java对象头的Mark Word中。升级过程如下无锁状态一个新创建的对象。偏向锁假设锁总是由同一个线程获得。当一个线程第一次进入同步块时JVM会使用CAS操作将线程ID记录到Mark Word中并将锁标志位设为偏向模式。之后该线程再进入时只需检查Mark Word中的线程ID是否是自己如果是则直接执行无需任何同步操作。这就像给这个线程开了个“快速通道”。轻量级锁当有另一个线程来尝试获取锁发生竞争偏向锁就会撤销升级为轻量级锁。轻量级锁的加锁过程是在当前线程的栈帧中创建一个名为锁记录的空间拷贝对象头的Mark Word到锁记录中然后尝试用CAS将对象头的Mark Word替换为指向锁记录的指针。如果成功当前线程获得锁如果失败表示存在竞争会自旋等待一小段时间自适应自旋尝试再次获取。重量级锁如果轻量级锁自旋失败竞争激烈或者自旋超过一定次数锁就会膨胀为重量级锁。此时Mark Word中存储的是指向操作系统级互斥量的指针未获取到锁的线程会被挂起进入阻塞队列等待操作系统调度唤醒。升级路径无锁 - 偏向锁 - 轻量级锁 - 重量级锁。这个过程是单向的目的是为了在“竞争程度”这个维度上用最小的代价实现互斥。3.3 可重入性与实现原理synchronized是可重入锁。这意味着同一个线程在外层方法获取锁之后在进入内层方法时如果锁对象相同会自动获取锁而不会被自己阻塞。public class ReentrantExample { public synchronized void methodA() { methodB(); // 线程在此处可以再次获取同一把锁不会死锁 } public synchronized void methodB() { // ... } }其原理是JVM会为每个锁对象维护一个计数器和一个所有者线程标识。当线程首次获取锁时计数器置为1记录所有者。同一线程每次重入计数器加1退出同步块时计数器减1直到计数器减为0锁才被真正释放其他线程才有机会获取。实操心得虽然synchronized经过了优化但在超高并发、锁竞争激烈的场景下如电商秒杀核心库存扣减重量级锁导致的线程挂起和唤醒开销依然巨大。此时通常需要考虑更细粒度的锁如分段锁或非阻塞算法如CAS。另外避免使用String常量、Integer等可能被缓存或池化的对象作为锁这可能导致意想不到的全局锁竞争。最佳实践是使用私有的、不可变的final Object作为专用锁对象。4. JUC显式锁ReentrantLock与ReadWriteLockjava.util.concurrent.locks包提供了更灵活、功能更强大的显式锁。最核心的两个类是ReentrantLock和ReentrantReadWriteLock。4.1 ReentrantLock灵活性与高级功能ReentrantLock实现了Lock接口它同样具有可重入性但在synchronized的基础上提供了三大关键增强尝试非阻塞获取锁tryLock()方法。线程尝试获取锁如果锁可用则获取并立即返回true否则立即返回false线程不会被阻塞。这可以用于避免死锁或者实现更复杂的锁获取逻辑。Lock lock new ReentrantLock(); if (lock.tryLock(1, TimeUnit.SECONDS)) { // 也可以尝试等待一段时间 try { // 操作共享资源 } finally { lock.unlock(); // 必须在finally块中释放锁 } } else { // 获取锁失败执行备选方案 }可中断的锁获取lockInterruptibly()方法。在等待锁的过程中线程可以响应中断。这对于实现可取消的任务非常重要。公平锁与非公平锁ReentrantLock的构造器可以接受一个boolean参数指定是否为公平锁。非公平锁默认线程获取锁的顺序与请求时间不一定一致。可能存在“插队”现象。优点是吞吐量高因为减少了线程挂起和唤醒的开销。公平锁严格按照线程请求锁的顺序FIFO来分配锁。保证了公平性但可能降低整体吞吐量因为维护队列需要开销。4.2 ReentrantReadWriteLock读写分离提升并发度在很多场景下对共享资源的访问是“读多写少”的。如果每次读操作也像写操作一样需要独占锁会严重限制并发性能。ReentrantReadWriteLock将锁分离为一个读锁和一个写锁。读锁共享锁允许多个线程同时持有读锁只要没有线程持有写锁。写锁排他锁一次只允许一个线程持有写锁。当有线程持有写锁时其他线程无法获取读锁或写锁。其规则可以总结为读读共享读写互斥写写互斥。这极大地提升了读操作的并发度。ReentrantReadWriteLock rwLock new ReentrantReadWriteLock(); ReentrantReadWriteLock.ReadLock readLock rwLock.readLock(); ReentrantReadWriteLock.WriteLock writeLock rwLock.writeLock(); // 读操作 public Data readData() { readLock.lock(); try { // 执行读操作 return data; } finally { readLock.unlock(); } } // 写操作 public void writeData(Data newData) { writeLock.lock(); try { // 执行写操作 data newData; } finally { writeLock.unlock(); } }4.3 Condition精准的线程等待与通知synchronized配合Object.wait()和Object.notify()/notifyAll()可以实现线程间的等待/通知机制但一个锁对象只能有一个等待队列无法实现更精细的条件控制。ReentrantLock可以与多个Condition对象关联实现多路等待/通知。例如实现一个容量有限的生产者-消费者队列public class BoundedQueueT { private final Lock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); // 队列“未满”条件 private final Condition notEmpty lock.newCondition(); // 队列“非空”条件 private final Object[] items; private int putPtr, takePtr, count; public void put(T x) throws InterruptedException { lock.lock(); try { while (count items.length) { notFull.await(); // 队列已满在“notFull”条件上等待 } items[putPtr] x; if (putPtr items.length) putPtr 0; count; notEmpty.signal(); // 放入一个元素后队列肯定非空唤醒一个在“notEmpty”上等待的消费者 } finally { lock.unlock(); } } public T take() throws InterruptedException { lock.lock(); try { while (count 0) { notEmpty.await(); // 队列为空在“notEmpty”条件上等待 } T x (T) items[takePtr]; if (takePtr items.length) takePtr 0; --count; notFull.signal(); // 取走一个元素后队列肯定不满唤醒一个在“notFull”上等待的生产者 return x; } finally { lock.unlock(); } } }使用两个Condition可以精准地唤醒生产者或消费者避免了使用synchronized时notifyAll()带来的无效竞争“惊群效应”。注意事项使用ReentrantLock必须手动释放锁并且务必在finally块中执行unlock()以确保锁在发生异常时也能被释放避免死锁。这是它与synchronized自动释放最大的使用区别也是容易出错的地方。5. 无锁编程与原子类基于CAS的乐观并发控制当锁竞争成为性能瓶颈时无锁编程提供了一种新的思路。其核心思想是乐观锁假设冲突很少发生先进行操作在提交时检查是否有冲突如果有则重试。这避免了线程的挂起和调度开销。5.1 CAS原理与底层支持乐观锁的基石是CAS操作。CAS是Compare-And-Swap的缩写它是一条CPU原子指令。操作包含三个参数内存位置V、预期原值A和新值B。当且仅当V的值等于A时处理器才会用B更新V的值否则不执行更新。无论是否更新都会返回V的旧值。整个操作是一个不可分割的原子过程。在Java中sun.misc.Unsafe类提供了CAS的底层方法但通常我们不直接使用它。java.util.concurrent.atomic包下的原子类为我们提供了线程安全的、基于CAS的原子操作。5.2 Atomic原子类家族详解原子类覆盖了基本类型和引用类型基本类型AtomicInteger,AtomicLong,AtomicBoolean。引用类型AtomicReference,AtomicStampedReference,AtomicMarkableReference。数组类型AtomicIntegerArray,AtomicLongArray,AtomicReferenceArray。字段更新器AtomicIntegerFieldUpdater,AtomicLongFieldUpdater,AtomicReferenceFieldUpdater。以AtomicInteger为例其incrementAndGet()方法实现了线程安全的自增public final int incrementAndGet() { return unsafe.getAndAddInt(this, valueOffset, 1) 1; } // Unsafe.getAndAddInt 内部是一个典型的CAS循环 public final int getAndAddInt(Object o, long offset, int delta) { int v; do { v getIntVolatile(o, offset); // 获取当前值 } while (!compareAndSwapInt(o, offset, v, v delta)); // CAS尝试更新失败则循环重试 return v; }5.3 ABA问题与解决方案CAS操作存在一个经典问题ABA问题。线程1读取变量值为A然后线程2将值改为B接着又改回A。此时线程1进行CAS操作发现当前值仍是A于是操作成功。但这可能隐藏了问题因为变量经历了A-B-A的变化其状态可能已不是线程1最初认知的A例如链表头节点被替换过又换回。解决方案是给变量加上版本号或时间戳。AtomicStampedReference和AtomicMarkableReference就是为此设计的。AtomicStampedReferenceInteger atomicStampedRef new AtomicStampedReference(100, 0); int[] stampHolder new int[1]; int oldStamp atomicStampedRef.get(stampHolder); // 同时获取值和版本戳 int newStamp oldStamp 1; // CAS时同时比较值和版本戳 boolean success atomicStampedRef.compareAndSet(100, 101, oldStamp, newStamp);5.4 无锁数据结构示例无锁栈下面是一个简化版的无锁栈实现展示了CAS在数据结构中的应用public class ConcurrentStackE { private static class NodeE { final E item; NodeE next; Node(E item) { this.item item; } } private AtomicReferenceNodeE top new AtomicReference(); public void push(E item) { NodeE newNode new Node(item); NodeE oldTop; do { oldTop top.get(); newNode.next oldTop; } while (!top.compareAndSet(oldTop, newNode)); // CAS更新栈顶 } public E pop() { NodeE oldTop; NodeE newTop; do { oldTop top.get(); if (oldTop null) return null; newTop oldTop.next; } while (!top.compareAndSet(oldTop, newTop)); // CAS更新栈顶 return oldTop.item; } }实操心得无锁编程能极大提升高竞争场景下的吞吐量但它把并发控制的复杂性转移到了算法设计上。CAS循环在竞争激烈时可能导致大量的CPU空转忙等待。因此它适用于锁持有时间极短、线程数不会远超CPU核心数的场景。对于复杂的复合操作无锁算法设计难度很高此时使用锁可能是更明智的选择。LongAdder和LongAccumulator是AtomicLong在高并发写场景下的优化变体它们通过内部维护一个单元格数组来分散竞争在sum()时才合并写性能远高于AtomicLong值得关注。6. 分布式锁跨越JVM的同步当系统从单机扩展到分布式集群单JVM内的锁就失效了。我们需要一个所有服务实例都能访问的外部协调系统来实现分布式锁。其核心要求是互斥性、安全性死锁免疫、容错性锁服务节点宕机不影响、高性能。6.1 基于Redis的分布式锁实现Redis因其高性能和丰富的数据结构成为实现分布式锁的热门选择。基础实现SETNX EXPIREpublic class RedisDistributedLock { private Jedis jedis; private String lockKey; private String lockValue; // 通常使用UUID线程ID用于安全释放 private int expireTime; // 秒 public boolean tryLock() { lockValue UUID.randomUUID().toString() Thread.currentThread().getId(); // 使用SET命令的NX和EX选项保证设置值和过期时间的原子性 String result jedis.set(lockKey, lockValue, NX, EX, expireTime); return OK.equals(result); } public void unlock() { // 关键使用Lua脚本保证判断锁归属和删除的原子性 String luaScript if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; jedis.eval(luaScript, Collections.singletonList(lockKey), Collections.singletonList(lockValue)); } }关键点解析原子性加锁使用SET key value NX EX seconds命令将设置值和过期时间合并为一个原子操作避免SETNX和EXPIRE分开执行时进程崩溃导致死锁。设置唯一值lockValue必须是全局唯一标识如UUID线程ID用于标识加锁的客户端。这是实现安全释放锁的前提。原子性解锁使用Lua脚本。因为判断lockValue和删除key必须是原子的否则可能误删其他客户端持有的锁例如客户端A阻塞导致锁过期释放客户端B获得锁此时A恢复执行删除操作就会删掉B的锁。6.2 锁续期与RedLock算法锁续期Watch Dog如果业务执行时间超过了锁的过期时间锁会自动释放导致数据不一致。因此需要一种机制在锁过期前自动续期。可以在一个守护线程中定期比如过期时间的1/3检查锁是否仍被持有如果是则延长过期时间。RedLock算法为了提升Redis分布式锁的可靠性避免单点故障Redis作者提出了RedLock算法。其核心思想是同时向N个通常为5个独立的Redis主节点申请锁只有当获取了超过半数N/2 1节点的锁且总耗时小于锁的有效时间才算加锁成功。释放锁时需要向所有节点发起释放请求。RedLock的实现和运维成本较高且存在争议需要根据业务对一致性的要求谨慎选择。6.3 基于ZooKeeper的分布式锁ZooKeeper通过其有序临时节点特性可以非常优雅地实现分布式锁。实现原理所有客户端在指定目录如/locks/my_lock下创建临时有序节点。节点创建后获取父目录下的所有子节点并排序。锁获取如果自己创建的节点是序号最小的则获取锁成功。锁等待如果不是最小节点则向比自己序号小的前一个节点注册Watcher监听。锁释放业务执行完毕删除自己创建的临时节点。ZooKeeper会通知监听该节点的客户端使其被唤醒并重新检查自己是否已成为最小节点。优势避免死锁临时节点在客户端会话结束时如进程崩溃会自动删除锁自然释放。公平锁节点顺序保证了获取锁的FIFO公平性。可重入需要在客户端记录重入次数。劣势性能通常低于Redis且强依赖于ZooKeeper集群的可用性。注意事项分布式锁是“重器”会显著增加系统复杂度和调用耗时。在设计时务必先问是否真的需要分布式锁很多场景可以通过更轻量的方式解决例如数据库唯一约束对于防重复提交可以在数据库层面设置唯一索引。乐观锁使用数据版本号或时间戳在更新时校验。分区键将数据分片让同一资源的所有请求落到同一个服务实例上退化为本地锁。 如果必须使用要仔细处理网络延迟、时钟漂移、GC停顿等问题并做好完备的异常处理和降级方案。对于核心链路建议使用经过充分测试的成熟客户端如Redisson对于Redis它内置了看门狗、可重入锁、读写锁等多种实现。7. 锁的优化策略与最佳实践了解了各种锁之后如何在实际项目中用好它们避免性能陷阱和死锁才是真正的挑战。7.1 锁粒度优化细粒度锁与锁分段锁的粒度越粗安全性越高但并发度越低粒度越细并发度越高但管理越复杂可能引发死锁。粗粒度锁例如对整个ArrayList对象加锁来保证线程安全。细粒度锁例如ConcurrentHashMap在JDK 7中使用的分段锁。它将整个Map分成若干个Segment默认为16个每个Segment独立加锁。写操作只锁住对应的Segment不同Segment的写操作可以并发进行大大提升了并发写能力。JDK 8的ConcurrentHashMap则进一步优化在某些场景下使用了synchronizedCAS的无锁化设计。锁分段实践如果你有一个大的HashMap需要高并发更新可以将其拆分为多个小的HashMap每个配一把独立的锁根据key的哈希值决定使用哪个子Map和锁。7.2 死锁预防、检测与避免死锁的四个必要条件互斥、持有并等待、不可剥夺、循环等待。打破任意一个即可预防死锁。预防避免嵌套锁尽量只获取一把锁。如果必须获取多把锁确保所有线程以固定的全局顺序获取锁例如按锁对象的哈希值或ID排序。这是最有效的方法。// 错误的嵌套可能死锁 // 线程1: lock A - lock B // 线程2: lock B - lock A // 正确的固定顺序 Object lock1 ...; Object lock2 ...; Object firstLock lock1.hashCode() lock2.hashCode() ? lock1 : lock2; Object secondLock firstLock lock1 ? lock2 : lock1; synchronized(firstLock) { synchronized(secondLock) { // ... } }使用带超时的锁ReentrantLock.tryLock(long timeout, TimeUnit unit)。使用可中断的锁lockInterruptibly()。检测对于复杂系统可以定期扫描线程和锁的依赖图检测是否存在循环等待。JVM自带的工具如jstack或APM工具可以辅助发现死锁线程。7.3 性能监控与排查工具当系统出现性能问题时锁竞争往往是元凶之一。jstack最常用的命令行工具。jstack pid可以打印出Java进程所有线程的堆栈信息。查找状态为BLOCKED的线程看它们正在等待哪个锁以及这个锁被哪个线程持有。JVisualVM / JMC图形化工具。它们提供了线程监控视图可以直观地看到线程状态、锁竞争情况甚至可以进行线程转储分析。Arthas阿里开源的Java诊断工具。其thread -b命令可以一键找出当前阻塞其他线程最多的“罪魁祸首”线程。自定义监控可以在代码中通过ThreadMXBean接口获取线程的锁信息或使用AOP对加锁方法进行耗时统计定位热点锁。7.4 实战场景选型指南最后我们用一个表格来总结不同场景下的锁选型建议这源于我多年踩坑后的经验场景特征推荐方案理由与注意事项简单的同步块竞争不激烈synchronized语法简洁JVM自动优化无需手动释放。是大多数情况下的首选。需要尝试获取锁、可中断、公平锁等高级功能ReentrantLock功能强大灵活。切记在finally中unlock。明确的读多写少场景ReentrantReadWriteLock显著提升读并发性能。注意写锁饥饿问题一直有读锁导致写锁无法获取可通过公平锁或StampedLock缓解。读远大于写且读操作耗时短StampedLock提供了乐观读模式性能可能优于ReadWriteLock。但API复杂且不是可重入锁。简单的计数器、状态标志更新AtomicInteger,AtomicBoolean等原子类无锁性能极高。注意ABA问题必要时用带版本号的类。高并发统计求和如计数器LongAdder,DoubleAdder写性能远超AtomicLong空间换时间适合统计场景。单机内复杂共享变量的无锁更新AtomicReference CAS循环适用于更新对象引用。需要自行设计无锁算法复杂度高。跨JVM/服务间的资源互斥分布式锁Redis/ZooKeeper评估必要性。Redis性能好ZooKeeper可靠性高。做好容错和降级。需要超时控制的互斥访问ReentrantLock.tryLock()或分布式锁避免无限期等待提升系统健壮性。线程间精准的等待/通知如生产者-消费者ReentrantLockCondition比Object.wait/notify更灵活可创建多个等待队列。锁是并发编程中强大而危险的工具。我的体会是在设计和评审代码时对于每一把锁都要像对待数据库事务一样谨慎范围尽可能小时间尽可能短粒度尽可能细。多花时间在架构设计上通过数据分片、无状态设计、异步处理等方式减少共享状态往往比绞尽脑汁优化锁更能从根本上提升并发能力。当你不确定时先用jstack和性能分析工具看看数据比直觉更可靠。