synchronized通过JVM的monitor机制实现互斥，线程需获取对象关联的monitor锁才能执行同步代码，锁的是对象而非代码块，支持重入且推荐细粒度的同步块而非方法级同步。
为什么synchronized能阻止多个线程同时执行同一段代码
synchronized 本质是基于 JVM 的 monitor（监视器）机制，每个对象都有一个与之关联的 monitor。当线程执行 synchronized 块或方法时，必须先获取该对象的 monitor 锁；获取失败就阻塞等待，直到持有锁的线程释放它。这保证了临界区（critical section）的互斥访问。
注意：锁的是“对象”，不是代码块本身。所以两个线程调用不同对象上的同步实例方法，不会互相阻塞；而调用同一个对象的同步方法，才会排队执行。
-
synchronized(this)和同步实例方法等价，锁的是当前实例对象 -
synchronized(ClassName.class)或同步静态方法，锁的是类的Class对象，对所有实例全局唯一 - 锁重入（reentrant）：同一线程可多次进入同一把锁保护的区域，JVM 会维护锁计数器
synchronized 方法 vs synchronized 块：选哪个更合理
方法级同步粒度太粗，容易造成不必要的阻塞。比如一个长方法里只有几行要保护，却让整个方法串行执行，吞吐量明显下降。
推荐优先使用同步块，明确指定锁对象和保护范围：
立即学习“Java免费学习笔记（深入）”；
public void transfer(Account from, Account to, BigDecimal amount) {
// 只对账户余额操作加锁，不锁整个方法逻辑
synchronized(from) {
synchronized(to) {
from.balance = from.balance.subtract(amount);
to.balance = to.balance.add(amount);
}
}
}
- 避免死锁：若需多把锁，始终按固定顺序（如对象哈希值排序）获取
- 不要用
this或String字面量作锁对象——前者可能被外部误用，后者因字符串常量池共享易引发意外竞争 - 尽量用私有 final 对象作锁，比如
private final Object lock = new Object();
常见误用：看似加锁，实则无效的写法
以下几种情况，synchronized 看似存在，但根本没起到线程安全作用：
- 同步方法但锁对象不一致：两个线程分别操作
new Counter()的不同实例，synchronized实例方法互不影响 - 锁的是可变引用：比如
synchronized(list)，但 list 被重新赋值过，后续加锁对象已变 - 读操作没加锁：写用
synchronized，读却是普通方法，JVM 可能因指令重排或缓存导致读到脏数据（虽然 happens-before 存在，但非 volatile + 同步配对时仍易出错） - 锁住的是基本类型包装类（如
Integer）：自动装箱导致每次都是新对象，锁失效
典型错误示例：synchronized(new Integer(1)) { ... } —— 每次都新建锁对象，完全无意义。
性能开销和替代方案的取舍点
在 JDK 6 之后，synchronized 经过大量优化（偏向锁、轻量级锁、自旋、锁消除、锁粗化），在无竞争或低竞争场景下性能接近甚至优于 ReentrantLock。但仍有不可忽视的边界：
- 无法实现超时获取锁（
tryLock(long, TimeUnit)）、中断响应、条件变量（Condition）等高级控制 - 锁的释放只能由 JVM 在退出同步块/方法时自动完成，不能手动控制
- 高竞争下仍可能触发重量级锁膨胀，导致线程挂起/唤醒开销显著上升
真正需要细粒度控制、公平性、或配合条件等待时，才应切换到 ReentrantLock；日常简单互斥，synchronized 更简洁、不易出错，也更难写出死锁逻辑（因为隐式释放）。
最容易被忽略的是：锁的粒度和生命周期必须匹配业务语义。比如缓存加载场景中，用单个锁保护整个缓存 map，会成为瓶颈；改用分段锁或 ConcurrentHashMap 才是正解——这时候再纠结 synchronized 性能就没意义了。
