synchronized 锁住的是 monitor 对象而非语法结构，具体锁目标取决于写法：this 锁实例、Class.class 或 static synchronized 锁类、自定义 final Object 锁更安全；字符串字面量和 Integer 缓存作锁易引发意外竞争。
synchronized 锁住的是 monitor 对象，不是方法、代码块或变量本身
这是最常被误解的一点：synchronized 并不“锁住方法”或“锁住代码”，它锁的是某个具体的 Java 对象（更准确地说，是该对象关联的 monitor）。JVM 通过对象头里的 Mark Word 记录锁状态，而这个 monitor 的归属对象，取决于你写法——this、Class.class 或任意一个 Object 实例。
常见错误现象：
- 以为
public synchronized void methodA()和public synchronized void methodB()是“两个独立的锁”，其实它们共用同一个对象锁（this），线程 A 调用methodA()时，线程 B 就无法进入methodB() - 在工具类中误用静态方法加
synchronized，结果所有调用方被串行化，性能骤降（比如一个全局StringUtils.format()被加了static synchronized）
对象锁 vs 类锁：看锁目标是不是 Class 对象
判断依据非常简单：锁对象是实例（this）还是类（XXX.class）。两者完全不冲突，可以同时被不同线程持有。
使用场景与对应写法：
立即学习“Java免费学习笔记（深入）”；
-
对象锁：保护单个对象的状态。适用于有状态的实例，如
BankAccount.withdraw()、Counter.increment() -
类锁：保护类级别的共享资源，比如静态缓存、单例初始化、类加载时的元数据注册。典型写法：
public static synchronized void init()或synchronized (MyClass.class) { ... }
注意：类锁本质仍是对象锁，只是锁的对象是 MyClass.class 这个特殊的 Class 实例——而每个类在 JVM 中只有一份 Class 对象，所以它天然具有“全局唯一性”。
synchronized(this)、synchronized(XXX.class)、synchronized(staticObj) 的区别
这三种写法锁的目标完全不同，直接影响并发粒度和线程阻塞范围：
public class Counter {
private int instanceCount = 0;
private static int staticCount = 0;
private static final Object STATIC_LOCK = new Object();
// ✅ 锁 this：每个 Counter 实例互不影响
public synchronized void incInstance() {
instanceCount++;
}
// ✅ 锁 Counter.class：所有实例共享一把锁
public static synchronized void incStatic() {
staticCount++;
}
// ✅ 锁自定义静态对象：语义更清晰，且可避免反射/继承干扰
public void incWithCustomLock() {
synchronized (STATIC_LOCK) {
staticCount++;
}
}
}
关键差异：
-
synchronized(this)→ 锁当前实例，多个实例之间无竞争 -
synchronized(Counter.class)→ 锁整个类，等价于static synchronized方法 -
synchronized(STATIC_LOCK)→ 锁一个私有静态对象，推荐用于显式控制类级同步，避免意外暴露Counter.class（比如被外部恶意synchronized(Counter.class)阻塞）
容易踩的坑：字符串字面量、Integer 缓存、锁泄漏
这些看似普通的对象，作为锁目标时极易引发隐蔽问题：
-
字符串字面量作锁：
synchronized("key")—— 因为字符串常量池共享，不同模块可能无意中锁同一字符串，导致跨业务阻塞 -
Integer 等包装类作锁：
synchronized(Integer.valueOf(127))在 -128~127 范围内会命中缓存，等同于锁住一个全局共享对象，风险同上 -
锁对象被重新赋值：
private Object lock = new Object(); ... lock = new Object();→ 原锁失效，后续同步块不再受控 -
锁对象为 null → 运行时报
NullPointerException，且发生在monitorenter字节码处，堆栈不直观
建议统一用 private final Object lock = new Object(); 声明私有锁对象，避免任何隐式共享或生命周期问题。
真正难的从来不是“怎么加锁”，而是“锁谁、锁多大范围、会不会被别人意外拿到同一把锁”。monitor 机制本身很稳定，但锁目标选错，轻则性能瓶颈，重则死锁或功能紊乱——而这几乎全靠开发者对对象生命周期和共享边界的清醒判断。
