lock不是为了替代synchronized，而是弥补其不可中断、无超时、不支持多条件唤醒等不足；必须手动加锁并用try-finally确保unlock()，支持lockinterruptibly()、trylock()等多种获取方式及condition精准唤醒。
Lock 接口不是为了“替代” synchronized 而存在，而是当 synchronized 做不到、或做得不够好时，才用 Lock 来补足。它本质是显式控制锁的生命周期，换来的是更细粒度的并发能力。
核心动作：手动加锁 + 必须 finally 解锁
synchronized 是 JVM 自动管理的，出作用域或异常都会释放；Lock 则完全由你掌控，漏掉 unlock() 就等于锁永久卡死。
- lock() 必须在 try 块之前调用，不能放在 try 内部
- unlock() 必须写在 finally 块中，确保无论是否抛异常都会执行
- 绝不能用 try-with-resources，Lock 不是 AutoCloseable
按需选择获取锁的方式
不用死守 lock()，四个获取方法对应不同业务诉求：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- lock()：等同于 synchronized 的阻塞行为，适合简单互斥、无需中断和超时的场景
- lockInterruptibly()：线程可被中断（比如用户取消任务），等待中收到 interrupt 就抛 InterruptedException 并退出
- tryLock()：非阻塞，立刻返回 true 或 false，适合“抢锁失败就走降级逻辑”的场景
- tryLock(5, TimeUnit.SECONDS)：带超时，避免无限等待，适用于有明确响应时限的服务（如网关、RPC 调用）
用 Condition 替代 wait/notify 实现精准唤醒
synchronized 只能绑定一个隐式条件（Object 的 wait/notify），而 Lock 可通过 newCondition() 创建多个独立 Condition 对象。
- 生产者只 signal 生产条件（notFull），消费者只 await 消费条件（notEmpty）
- 避免 notifyAll 唤醒所有线程再竞争，减少无效调度
- 典型应用：阻塞队列、多阶段流水线、状态驱动的协作流程
公平性与锁状态检查这些“附加能力”
ReentrantLock 构造时可选 fair = true，让等待最久的线程优先获取锁——但注意，公平锁会显著降低吞吐量，仅在压测验证确实需要且不伤性能时启用。
- isLocked()、isHeldByCurrentThread() 等方法可用于诊断、监控或实现自适应逻辑
- getHoldCount()、getQueueLength() 有助于排查死锁或线程堆积问题
- 这些能力在排查线上并发问题时非常实用，synchronized 完全不可见
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
