1. 可重入锁ReentrantLock基础解析第一次接触ReentrantLock是在处理一个多线程订单系统时遇到的。当时系统频繁出现死锁排查后发现是线程在递归调用中重复获取锁导致的。传统synchronized无法解决这个问题直到发现了ReentrantLock这个神器。1.1 什么是可重入锁可重入锁ReentrantLock是Java并发包(java.util.concurrent.locks)中提供的一种显式锁实现。它的核心特性是允许同一个线程多次获取同一把锁而不会产生死锁。这与synchronized关键字的行为类似但提供了更灵活的锁控制机制。举个例子假设有个递归方法需要加锁public void recursiveMethod(int n) { lock.lock(); try { if (n 0) return; System.out.println(执行层级 n); recursiveMethod(n - 1); } finally { lock.unlock(); } }使用普通非可重入锁时第二次调用recursiveMethod就会因为无法获取已持有的锁而阻塞。而ReentrantLock允许这种情况发生这就是可重入的含义。1.2 核心特性与优势与synchronized相比ReentrantLock有几个显著优势可中断的锁获取通过lockInterruptibly()方法可以在等待锁时响应中断尝试获取锁tryLock()方法可以立即返回获取锁的结果避免无限等待公平性选择构造函数可以指定是否为公平锁默认非公平条件变量支持可以创建多个Condition对象实现精细化的线程通信重要提示使用ReentrantLock时必须手动释放锁通常放在finally块中确保释放。忘记释放锁会导致严重问题。2. ReentrantLock实现原理深度剖析2.1 同步器AbstractQueuedSynchronizer(AQS)ReentrantLock的核心实现依赖于AQS这个并发框架的基础组件。AQS内部维护了一个FIFO的等待队列和一个state状态变量。对于ReentrantLockstate0锁未被占用state0锁被占用数值表示重入次数等待队列存储被阻塞的线程获取锁的基本流程尝试通过CAS修改state从0到1成功则设置当前线程为独占线程失败则进入等待队列2.2 公平锁与非公平锁实现差异ReentrantLock在构造时可以指定公平性public ReentrantLock(boolean fair) { sync fair ? new FairSync() : new NonfairSync(); }非公平锁实现特点新请求的线程可以直接插队尝试获取锁吞吐量更高但可能导致某些线程饥饿实现上直接尝试CAS获取锁不检查队列公平锁实现特点严格按照FIFO顺序获取锁吞吐量较低但保证公平性实现上会先检查是否有等待线程实测数据显示在高并发场景下非公平锁的性能可以比公平锁高出5-10倍。2.3 重入计数实现重入功能通过以下机制实现记录当前持有锁的线程同一线程再次获取锁时简单增加state计数释放锁时减少计数只有计数归零时才真正释放关键代码片段final boolean nonfairTryAcquire(int acquires) { final Thread current Thread.currentThread(); int c getState(); if (c 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current getExclusiveOwnerThread()) { int nextc c acquires; if (nextc 0) // overflow throw new Error(Maximum lock count exceeded); setState(nextc); return true; } return false; }3. 实战应用与性能优化3.1 典型使用模式标准的使用模板ReentrantLock lock new ReentrantLock(); //... lock.lock(); try { // 临界区代码 } finally { lock.unlock(); }高级用法示例- 带超时的锁获取if (lock.tryLock(1, TimeUnit.SECONDS)) { try { // 获取锁成功 } finally { lock.unlock(); } } else { // 超时处理 }3.2 条件变量(Condition)的使用Condition提供了类似Object.wait/notify的机制但更灵活class BoundedBuffer { final Lock 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(); items[putptr] x; if (putptr items.length) putptr 0; count; notEmpty.signal(); } finally { lock.unlock(); } } // 类似的take方法 }3.3 性能优化技巧锁粒度控制尽量减小临界区范围避免嵌套锁容易导致死锁锁分段对于高竞争场景考虑使用ConcurrentHashMap的分段锁思想读写锁选择读多写少场景考虑ReentrantReadWriteLock实测数据对比4核8G机器100万次操作锁类型耗时(ms)吞吐量(ops/s)synchronized4502222ReentrantLock(非公平)3802631ReentrantLock(公平)62016124. 常见问题与排查指南4.1 典型问题排查问题1锁未被释放症状线程池中的线程逐渐耗尽 排查方法使用jstack查看线程堆栈查找处于WAITING状态的线程检查是否所有lock()都有对应的unlock()问题2死锁症状系统无响应CPU利用率低 排查方法jstack查看死锁报告检查锁获取顺序是否一致使用tryLock设置超时4.2 调试技巧使用ThreadMXBean检测死锁ThreadMXBean bean ManagementFactory.getThreadMXBean(); long[] threadIds bean.findDeadlockedThreads();给锁设置名称便于调试ReentrantLock lock new ReentrantLock() { Override public String toString() { return OrderLock hashCode(); } };使用可视化工具如JConsole、VisualVM监控锁竞争情况4.3 最佳实践总结总是使用try-finally确保锁释放考虑使用tryLock避免无限等待高竞争场景优先选择非公平锁读写分离场景考虑读写锁避免在持有锁时调用外部方法容易导致死锁锁的获取和释放要在同一代码层级在分布式系统中ReentrantLock的本地特性使其不适用于跨JVM场景此时需要考虑分布式锁方案如Redis或Zookeeper实现。