synchronized 锁的是对象而非代码块或方法名，本质是给对象加监视器锁；实例方法锁 this，静态方法锁类对象，同步代码块锁指定非 null 对象；锁自动获取释放，可重入但易因耗时操作拖长锁周期，JVM 会按竞争动态升级锁。
锁的是对象，不是代码块或方法名
synchronized 本质是给某个对象加监视器锁（monitor lock），不是“锁住这段代码”。哪怕两个线程调用的是同一个 synchronized 方法，只要它们操作的是不同实例，就互不干扰；反过来，哪怕调用的是完全不同的方法，只要锁的是同一个对象（比如都用 synchronized(this) 或都锁 MyClass.class），就会串行执行。
- 实例方法：隐式锁对象是
this - 静态方法：锁对象是
MyClass.class - 同步代码块：
synchronized(obj)中的obj必须是非null对象，锁的就是它
常见错误：传入 null 导致 NullPointerException；或误以为 synchronized 方法会锁住整个类，结果发现 new 出多个对象后仍并发——其实是没锁到同一把锁。
锁的获取和释放由 JVM 自动完成，但时机很关键
进入 synchronized 块/方法时尝试获取锁，退出（无论正常 return 还是抛异常）时自动释放锁。这点比 Lock 更省心，但也更难干预。
- 异常不会导致锁泄漏——这是
synchronized最稳的一点 - 但锁持有时间 = 整个方法体或代码块执行时间，容易因耗时操作（如 I/O、sleep、远程调用）拖长锁周期，引发线程排队
- 不能中断等待锁的线程（不像
Lock.tryLock()可设超时）
实操建议：把耗时逻辑移出 synchronized 块，只包裹真正需要原子保护的共享状态读写。例如先查缓存、再加锁更新、最后异步刷新下游，而不是整个流程锁住。
立即学习“Java免费学习笔记（深入）”；
底层锁不是一成不变的：偏向锁 → 轻量级锁 → 重量级锁
JVM（HotSpot）会根据竞争情况动态升级锁：无竞争时用偏向锁（只记录线程 ID），轻度竞争转为轻量级锁（CAS 操作），高竞争才膨胀为重量级锁（依赖操作系统 mutex）。这个过程对开发者透明，但影响性能感知。
- 偏向锁默认开启（JDK 6+），但在大量线程反复竞争场景下反而成为负担，可加
-XX:-UseBiasedLocking关闭 - 锁升级不可逆，一旦升级为重量级锁，即使后续竞争消失，也不会降级
-
wait()/notify()必须在synchronized块内调用，且会释放锁并进入 monitor 的 wait set；而单纯阻塞等待锁的线程在 entry set 中排队
容易被忽略：用 System.identityHashCode(obj) 或 JOL 工具观察对象头 mark word 变化，能验证锁是否真的升级了——别只看代码，要看运行时行为。
可重入性是默认保障，但嵌套使用仍要小心死锁
synchronized 是可重入锁：同一线程重复获取同一把锁不会阻塞。所以 methodA() 调 methodB()，两者都是 synchronized，没问题。
- 但跨对象嵌套加锁极易引发死锁，比如 A 锁
obj1后去等obj2，B 锁obj2后去等obj1 - 没有 try-finally 手动释放机制，也无法用
isHeldByCurrentThread()检查——这些只能靠设计规避 - 调试时注意：jstack 输出中
- waiting to lock表示在 entry set 排队；- in Object.wait()表示在 wait set 挂起
真实坑点：你以为锁的是业务对象，结果该对象被序列化、反序列化或被框架代理后，实际锁的对象已不是你预期的那个——务必确认锁对象的生命周期和唯一性。
