ReentrantLock 是 Java 高并发下比 synchronized 更灵活的互斥锁工具，需手动 lock/unlock 且 unlock 必在 finally 中；应最小化锁范围、避免锁内耗时操作、多资源用多锁；高频场景优先 tryLock；读多写少用 ReadWriteLock；默认非公平锁性能更优。

ReentrantLock 是 Java 中处理高并发资源互斥访问的主力工具，它比 synchronized 更灵活、可控，尤其适合对响应性、重试逻辑和锁粒度有要求的场景。

明确锁的作用范围，避免过度加锁

ReentrantLock 不会自动绑定代码块，必须手动调用 lock() 和 unlock()，且 unlock() 必须放在 finally 块中，否则一旦异常抛出，锁可能永远无法释放，导致死锁或线程阻塞。

• 只包裹真正操作共享资源的最小代码段，比如仅对 list.add() 加锁，而不是整个方法体
• 不要在锁内做耗时操作（如远程调用、文件读写），否则其他线程会长时间等待
• 多个独立资源尽量使用不同锁实例，避免“一把锁管所有”，降低争抢概率

高频场景优先用 tryLock 避免无意义等待

当资源访问是“快进快出”型（如缓存读取、计数器更新），用 tryLock() 比直接 lock() 更合理——它不阻塞，能快速判断是否可执行。

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 成功获取 → 执行业务逻辑，然后 unlock()
• 返回 false → 可走降级路径：返回本地副本、触发异步刷新、或返回默认值
• 带超时的 tryLock(100, TimeUnit.MILLISECONDS) → 控制最大等待时间，防止雪崩式排队

读多写少时换用 ReentrantReadWriteLock

如果资源被读取的频率远高于修改（比如配置项、权限缓存、静态字典），继续用 ReentrantLock 会让所有读请求串行化，严重拖慢吞吐量。此时应改用 ReentrantReadWriteLock。

立即学习“Java免费学习笔记（深入）”；

• 读锁可被多个线程同时持有，读-读不互斥
• 写锁是独占的，写操作会阻塞所有读和写，读操作也会阻塞写操作
• 注意：读锁升级为写锁不被允许（即不能先 lock(read) 再 tryLock(write)），必须先释放读锁再申请写锁

按需选择公平性，多数情况保持非公平

ReentrantLock 默认是非公平锁，新线程可以“插队”尝试获取锁，这减少了线程挂起/唤醒的开销，在请求密集、持有时间短的场景下吞吐更高。

• 除非观察到明显线程饥饿（某线程反复获取不到锁），否则不要启用公平模式
• 启用公平锁需显式传参：new ReentrantLock(true)，但会带来约 10%～20% 的性能损耗
• 非公平锁的“插队”行为由底层 CAS + AQS 队列机制保障，不是随机调度，仍保证整体安全性