1. ReentrantLock核心机制解析作为Java并发包中的重量级选手ReentrantLock的实现远比表面看到的复杂。其底层采用AQSAbstractQueuedSynchronizer框架构建这个设计模式堪称并发控制的瑞士军刀。AQS内部维护了一个volatile修饰的state变量和CLH队列前者记录锁的重入次数后者管理等待线程的排队秩序。锁的公平性选择直接影响系统吞吐量。非公平锁默认模式在锁释放时会允许新请求线程与队列头线程竞争这种设计虽然可能造成线程饥饿但能减少线程切换带来的性能损耗。实测在激烈竞争场景下非公平锁的吞吐量可比公平锁高出40%以上。而公平锁严格按照FIFO顺序获取锁适合需要严格顺序执行的业务场景。// 公平锁与非公平锁的底层实现差异 static final class FairSync extends Sync { final boolean initialTryLock() { Thread current Thread.currentThread(); int c getState(); if (c 0) { if (!hasQueuedThreads() compareAndSetState(0, 1)) { setExclusiveOwnerThread(current); return true; } } // 省略重入判断... } } static final class NonfairSync extends Sync { final boolean initialTryLock() { Thread current Thread.currentThread(); if (compareAndSetState(0, 1)) { // 直接尝试CAS抢锁 setExclusiveOwnerThread(current); return true; } // 省略重入判断... } }2. 锁的实战应用模式2.1 基础加锁范式正确的锁使用必须遵循获取-释放的严格配对原则。推荐使用try-finally代码块确保锁释放这种写法比synchronized更灵活但也更容易出错。特别注意lock()方法会阻塞直到获取锁而tryLock()支持带超时的非阻塞获取ReentrantLock lock new ReentrantLock(); try { if (lock.tryLock(3, TimeUnit.SECONDS)) { // 等待3秒 try { // 临界区操作 } finally { lock.unlock(); } } else { // 超时处理逻辑 } } catch (InterruptedException e) { Thread.currentThread().interrupt(); }2.2 条件变量高级用法Condition接口实现了管程模型的等待/通知机制。与Object.wait()/notify()不同单个ReentrantLock可以创建多个Condition实现精细化的线程调度。典型的生产者-消费者场景中可以分别为队列满和队列空创建独立的条件变量class BoundedBuffer { final ReentrantLock lock new ReentrantLock(); final Condition notFull lock.newCondition(); final Condition notEmpty lock.newCondition(); void put(Object x) throws InterruptedException { lock.lock(); try { while (count items.length) notFull.await(); // 队列满时等待 // 入队操作... notEmpty.signal(); // 唤醒消费者 } finally { lock.unlock(); } } // 省略take方法... }3. 性能调优实战3.1 锁竞争热点优化通过ThreadMXBean可以检测锁竞争情况。当发现某个锁的等待时间超过操作本身的10倍时就需要考虑锁细化Lock Splitting或锁分段Lock Striping。例如ConcurrentHashMap就采用了分段锁设计将数据分成多个Segment独立加锁。重要提示JDK8的StampedLock在读多写少场景下性能更好但要注意其不是可重入锁3.2 死锁预防方案开发中建议使用统一的锁获取顺序或者通过tryLock实现死锁检测。下面是一个简单的死锁检测实现public class DeadlockDetector { private static final ThreadMXBean bean ManagementFactory.getThreadMXBean(); public static void check() { long[] threadIds bean.findDeadlockedThreads(); if (threadIds ! null) { ThreadInfo[] infos bean.getThreadInfo(threadIds); for (ThreadInfo info : infos) { System.err.println(Deadlock detected: info); } } } }4. 源码级实现剖析4.1 AQS队列运作机制当锁被占用时新请求线程会被封装成Node加入CLH队列。这个虚拟队列通过CAS操作维护避免了真正的队列操作带来的性能损耗。节点状态waitStatus包含CANCELLED(1)线程已取消SIGNAL(-1)后继节点需要唤醒CONDITION(-2)处于条件等待PROPAGATE(-3)共享模式传播// AQS中的入队操作 private Node enq(Node node) { for (;;) { Node t tail; if (t null) { // 必须初始化 if (compareAndSetHead(new Node())) tail head; } else { node.prev t; if (compareAndSetTail(t, node)) { t.next node; return t; } } } }4.2 锁释放的级联唤醒释放锁时会触发unparkSuccessor操作从尾节点向前遍历找到最前面的未取消节点进行唤醒。这种反向遍历的设计是为了处理并发添加节点时next指针可能暂时为null的情况Node s node.next; if (s null || s.waitStatus 0) { s null; for (Node t tail; t ! null t ! node; t t.prev) if (t.waitStatus 0) s t; } if (s ! null) LockSupport.unpark(s.thread);5. 生产环境问题排查5.1 锁泄漏检测忘记释放锁是常见问题可以通过继承ReentrantLock重写加锁方法加入堆栈跟踪public class TracedLock extends ReentrantLock { private MapThread, Exception traces new ConcurrentHashMap(); Override public void lock() { super.lock(); traces.put(Thread.currentThread(), new Exception(Lock acquired here)); } Override public void unlock() { super.unlock(); traces.remove(Thread.currentThread()); } public void checkLeaks() { traces.forEach((thread, ex) - { System.err.println(Potential lock leak by thread.getName()); ex.printStackTrace(); }); } }5.2 锁性能监控通过自定义MBean可以暴露锁的等待时间、持有时间等关键指标public interface LockMonitorMBean { long getWaitCount(); double getAverageWaitTime(); long getHoldCount(); } // 使用时通过JMX客户端连接即可查看实时数据在实际高并发场景中我曾遇到过一个案例某支付系统使用ReentrantLock保护账户余额变更在促销期间出现性能骤降。通过ThreadDump发现锁等待链过长最终采用锁分段方案将账户按尾号分成16个锁段QPS立即从200提升到3500。这个案例告诉我们没有万能的锁策略只有最适合业务场景的并发方案。
1. ReentrantLock核心机制解析作为Java并发包中的重量级选手ReentrantLock的实现远比表面看到的复杂。其底层采用AQSAbstractQueuedSynchronizer框架构建这个设计模式堪称并发控制的瑞士军刀。AQS内部维护了一个volatile修饰的state变量和CLH队列前者记录锁的重入次数后者管理等待线程的排队秩序。锁的公平性选择直接影响系统吞吐量。非公平锁默认模式在锁释放时会允许新请求线程与队列头线程竞争这种设计虽然可能造成线程饥饿但能减少线程切换带来的性能损耗。实测在激烈竞争场景下非公平锁的吞吐量可比公平锁高出40%以上。而公平锁严格按照FIFO顺序获取锁适合需要严格顺序执行的业务场景。// 公平锁与非公平锁的底层实现差异 static final class FairSync extends Sync { final boolean initialTryLock() { Thread current Thread.currentThread(); int c getState(); if (c 0) { if (!hasQueuedThreads() compareAndSetState(0, 1)) { setExclusiveOwnerThread(current); return true; } } // 省略重入判断... } } static final class NonfairSync extends Sync { final boolean initialTryLock() { Thread current Thread.currentThread(); if (compareAndSetState(0, 1)) { // 直接尝试CAS抢锁 setExclusiveOwnerThread(current); return true; } // 省略重入判断... } }2. 锁的实战应用模式2.1 基础加锁范式正确的锁使用必须遵循获取-释放的严格配对原则。推荐使用try-finally代码块确保锁释放这种写法比synchronized更灵活但也更容易出错。特别注意lock()方法会阻塞直到获取锁而tryLock()支持带超时的非阻塞获取ReentrantLock lock new ReentrantLock(); try { if (lock.tryLock(3, TimeUnit.SECONDS)) { // 等待3秒 try { // 临界区操作 } finally { lock.unlock(); } } else { // 超时处理逻辑 } } catch (InterruptedException e) { Thread.currentThread().interrupt(); }2.2 条件变量高级用法Condition接口实现了管程模型的等待/通知机制。与Object.wait()/notify()不同单个ReentrantLock可以创建多个Condition实现精细化的线程调度。典型的生产者-消费者场景中可以分别为队列满和队列空创建独立的条件变量class BoundedBuffer { final ReentrantLock lock new ReentrantLock(); final Condition notFull lock.newCondition(); final Condition notEmpty lock.newCondition(); void put(Object x) throws InterruptedException { lock.lock(); try { while (count items.length) notFull.await(); // 队列满时等待 // 入队操作... notEmpty.signal(); // 唤醒消费者 } finally { lock.unlock(); } } // 省略take方法... }3. 性能调优实战3.1 锁竞争热点优化通过ThreadMXBean可以检测锁竞争情况。当发现某个锁的等待时间超过操作本身的10倍时就需要考虑锁细化Lock Splitting或锁分段Lock Striping。例如ConcurrentHashMap就采用了分段锁设计将数据分成多个Segment独立加锁。重要提示JDK8的StampedLock在读多写少场景下性能更好但要注意其不是可重入锁3.2 死锁预防方案开发中建议使用统一的锁获取顺序或者通过tryLock实现死锁检测。下面是一个简单的死锁检测实现public class DeadlockDetector { private static final ThreadMXBean bean ManagementFactory.getThreadMXBean(); public static void check() { long[] threadIds bean.findDeadlockedThreads(); if (threadIds ! null) { ThreadInfo[] infos bean.getThreadInfo(threadIds); for (ThreadInfo info : infos) { System.err.println(Deadlock detected: info); } } } }4. 源码级实现剖析4.1 AQS队列运作机制当锁被占用时新请求线程会被封装成Node加入CLH队列。这个虚拟队列通过CAS操作维护避免了真正的队列操作带来的性能损耗。节点状态waitStatus包含CANCELLED(1)线程已取消SIGNAL(-1)后继节点需要唤醒CONDITION(-2)处于条件等待PROPAGATE(-3)共享模式传播// AQS中的入队操作 private Node enq(Node node) { for (;;) { Node t tail; if (t null) { // 必须初始化 if (compareAndSetHead(new Node())) tail head; } else { node.prev t; if (compareAndSetTail(t, node)) { t.next node; return t; } } } }4.2 锁释放的级联唤醒释放锁时会触发unparkSuccessor操作从尾节点向前遍历找到最前面的未取消节点进行唤醒。这种反向遍历的设计是为了处理并发添加节点时next指针可能暂时为null的情况Node s node.next; if (s null || s.waitStatus 0) { s null; for (Node t tail; t ! null t ! node; t t.prev) if (t.waitStatus 0) s t; } if (s ! null) LockSupport.unpark(s.thread);5. 生产环境问题排查5.1 锁泄漏检测忘记释放锁是常见问题可以通过继承ReentrantLock重写加锁方法加入堆栈跟踪public class TracedLock extends ReentrantLock { private MapThread, Exception traces new ConcurrentHashMap(); Override public void lock() { super.lock(); traces.put(Thread.currentThread(), new Exception(Lock acquired here)); } Override public void unlock() { super.unlock(); traces.remove(Thread.currentThread()); } public void checkLeaks() { traces.forEach((thread, ex) - { System.err.println(Potential lock leak by thread.getName()); ex.printStackTrace(); }); } }5.2 锁性能监控通过自定义MBean可以暴露锁的等待时间、持有时间等关键指标public interface LockMonitorMBean { long getWaitCount(); double getAverageWaitTime(); long getHoldCount(); } // 使用时通过JMX客户端连接即可查看实时数据在实际高并发场景中我曾遇到过一个案例某支付系统使用ReentrantLock保护账户余额变更在促销期间出现性能骤降。通过ThreadDump发现锁等待链过长最终采用锁分段方案将账户按尾号分成16个锁段QPS立即从200提升到3500。这个案例告诉我们没有万能的锁策略只有最适合业务场景的并发方案。
