17370845950

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 块，只包裹真正需要原子保护的共享状态读写。例如先查缓存、再加锁更新、最后异步刷新下游，而不是整个流程锁住。

底层锁不是一成不变的：偏向锁 → 轻量级锁 → 重量级锁

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 挂起

真实坑点：你以为锁的是业务对象，结果该对象被序列化、反序列化或被框架代理后，实际锁的对象已不是你预期的那个——务必确认锁对象的生命周期和唯一性。