优先选用synchronized，因其自动加锁释放、语法简洁、JVM优化成熟；仅在需中断响应、超时获取、公平锁或多Condition等精细控制时才选ReentrantLock。
选 synchronized 还是 ReentrantLock，关键不是“哪个更好”，而是“哪个更合适”。两者都能保证线程安全，但设计定位不同：synchronized 是语言级的“默认选项”，ReentrantLock 是 API 级的“增强工具”。用对场景，才能既可靠又简洁。
简单同步、快速开发优先用 synchronized
当只需要保护一段代码不被并发修改，且没有特殊控制需求时，synchronized 是首选。它自动加锁、自动释放，哪怕抛异常也不会漏解锁；语法干净，一行 synchronized 就能搞定。
- 方法级同步：
public synchronized void update() { ... } - 代码块级同步：
synchronized(obj) { ... }，锁对象明确、粒度可控 - 适合计数器增减、状态标记更新、缓存写入等常见临界区操作
需要精细控制时才选 ReentrantLock
ReentrantLock 的价值不在“替代”，而在“补充”。只有当你明确需要它提供的某项能力，才值得引入额外复杂度。
- 要响应中断？用
lockInterruptibly()，比如任务取消或超时终止场景 - 要避免无限等待？用
tryLock(3, TimeUnit.SECONDS)实现带超时的获取 - 要按不同条件唤醒线程？用多个
Condition，如生产者-消费者中区分“满”和“空”信号 - 必须按请求顺序分配锁？构造时传
true启用公平锁（注意吞吐量会下降）
性能不是主要决策依据
JDK 6 之后，synchronized 经过锁升级优化（偏向锁 → 轻量级锁 → 重量级锁），在低竞争下性能甚至优于 ReentrantLock；高并发下两者差距微小。盲目为“性能”换锁，反而增加出错风险——比如忘记 unlock() 导致死锁，或在非 finally 块中释放锁。
立即学习“Java免费学习笔记（深入）”；
- 实测表明：多数业务系统中，锁竞争并不激烈，synchronized 的自动管理带来的稳定性远胜微弱的性能优势
- 真正影响性能的，往往是锁粒度、临界区长度、是否持有锁做 I/O 或远程调用，而非锁类型本身
维护性与团队习惯很重要
synchronized 是 Java 开发者最熟悉的同步方式，阅读成本低、出错率低；ReentrantLock 需要严格遵循 lock() → try → finally → unlock() 模式，一旦遗漏或位置错误，就会埋下隐患。
- 新成员接手代码时，看到
synchronized能立刻理解意图；看到ReentrantLock则需确认是否配对、是否在 finally 中释放 - 框架底层（如 Spring、Hibernate）内部确有使用 ReentrantLock 实现高级并发逻辑，但对外暴露的 API 仍大量依赖 synchronized
- 除非团队已有成熟规范并配套了静态检查工具（如防止 unlock 缺失），否则不建议在普通业务逻辑中普遍替换
