ReentrantLock 是 Java 并发包中可重入、可中断、支持公平/非公平策略的显式锁，需精确控制临界区、必须用 try-finally 确保解锁、按场景选公平性、并善用 Condition 实现精准线程协作。
ReentrantLock 是 Java 并发包（java.util.concurrent.locks）中可重入、可中断、支持公平/非公平策略的显式锁，比 synchronized 更灵活，适合高并发下精细控制临界区。
明确临界区范围，避免锁粒度过大
高并发场景下，锁范围过大是性能瓶颈主因。应只包裹真正需要互斥访问的共享资源操作，而非整个方法或冗长逻辑。
- ❌ 错误示例：在锁内做远程调用、IO、复杂计算
- ✅ 正确做法：提前准备参数，锁内仅执行原子读-改-写（如更新账户余额、扣减库存）
- 例如：库存扣减只锁
if (stock > 0) { stock--; }这两行，不包含日志记录或消息发送
必须搭配 try-finally 确保解锁
ReentrantLock 不具备 synchronized 的自动释放机制，一旦忘记 unlock 或异常跳出，会导致死锁或线程饥饿。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 务必在
finally块中调用lock.unlock() - 不要依赖作用域或构造器自动释放
- 示例结构：
lock.lock(); try { // 访问临界资源 } finally { lock.unlock(); // 无论是否异常，都释放 }
按需选择公平性与响应性
默认是非公平锁（吞吐量高），但可能造成线程“饥饿”；开启公平模式（new ReentrantLock(true)）可保障等待时间长的线程优先获取锁，代价是性能下降约 10%–20%。
- 高吞吐场景（如高频计数器、缓存更新）：用非公平锁（默认）
- 对响应时间敏感或需避免饥饿（如任务调度队列、权限校验）：考虑公平锁
- 注意：公平锁不能完全杜绝饥饿，只是降低概率
善用条件变量（Condition）做精准等待/通知
相比 synchronized + wait/notify，ReentrantLock 支持多个独立 Condition，可实现更清晰的线程协作逻辑。
- 例如生产者-消费者中，分别定义
notFull和notEmpty两个条件，避免虚假唤醒和无差别 notify - 使用前必须先持有锁，wait 前自动释放，被 signal 后重新竞争锁
- 推荐用
awaitNanos(timeout)或awaitUntil(deadline)实现超时控制，防止无限等待
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
