Java同步关键字使用详解

本文深入剖析Java中synchronized关键字的核心原理与实战陷阱，直击开发者最易踩坑的锁对象混淆问题：非静态同步方法锁定的是this实例，静态方法锁定的是Class对象，二者完全隔离，混用将导致线程安全形同虚设；强调必须统一锁粒度，坚决避免用字符串字面量或公共常量作锁，并推荐使用private final Object自定义锁以提升安全性与可控性；同时指出同步代码块在临界区短小场景下的性能优势，但警示过度拆分反而增加开销；最后揭示synchronized“看似失效”的本质——锁对象不一致、逃逸或时序依赖未被满足。掌握这些，才能真正让并发控制从“写了synchronized”升级为“锁对了对象、锁准了范围、锁住了本质”。

同步方法默认锁的是哪个对象

非静态同步方法锁的是 this，也就是当前实例；静态同步方法锁的是当前类的 Class 对象，即 MyClass.class。这点容易混淆，尤其在单例或工具类里混用静态和非静态同步方法时，会误以为“加了 synchronized 就线程安全”，其实锁根本不在一个维度上。

常见错误现象：NullPointerException 没有出现，但并发修改仍发生——因为两个线程分别调用不同实例的同步方法，锁互不干扰。

• 如果要保护实例状态（比如 counter 字段），用非静态同步方法或 synchronized(this)
• 如果要保护类级别资源（比如缓存、配置加载），必须用静态同步方法或 synchronized(MyClass.class)
• 别在一个类里一半用 synchronized(this)，一半用 synchronized(MyClass.class) 去保护同一份数据

synchronized(this) 和 synchronized(obj) 的区别在哪

锁对象不同，直接影响可重入性、粒度和死锁风险。用 this 是最直白的，但暴露了锁对象本身；用自定义 obj（比如 private final Object lock = new Object()）能隐藏锁、缩小作用域、避免外部误同步。

使用场景：多个方法需要协同访问一组字段，但又不想让整个实例被锁死（比如读写分离时，只对写操作加细粒度锁）。

• 用 this：适合简单场景，但若该对象被传给外部代码，别人也能 synchronized(obj)，可能引发意外阻塞或死锁
• 用私有 lock 对象：推荐做法，锁不可见，可控性强；注意必须是 final，否则可能因重新赋值导致锁对象变更
• 千万别用字符串字面量（如 synchronized("lock")）或公共常量作锁——字符串常量池会让看似无关的代码共享同一把锁

同步代码块比同步方法更省资源吗

是的，但只在「临界区很短、方法体很长」时才有明显收益。JVM 对 synchronized 有锁消除和偏向锁优化，但前提是它能确定锁的作用范围足够小、逃逸分析通过。

性能影响：同步方法本质是给整个方法加 monitor entry/exit，哪怕你只在末尾改一个字段；而同步代码块可以精准包裹那行赋值语句，减少线程等待时间。

• 优先选同步代码块，尤其是方法里只有几行要同步，其余都是 I/O 或计算
• 不要为了“看起来更细”而拆得太碎——频繁进出 monitor 本身也有开销，特别是高竞争下
• 注意：同步代码块里的变量必须是方法内可见的（局部变量没问题），但不能依赖同步外的判断结果做同步内操作（典型问题：先检查再执行，没锁住检查逻辑）

为什么有时候 synchronized 看似没生效

最常见原因是锁对象不一致。比如用了两个不同的 new Object() 作为锁，或者在循环里每次都新建锁对象，等于没锁。

另一个隐蔽坑：synchronized 只保证原子性和可见性，不保证顺序性。如果业务逻辑依赖“先 A 后 B”的严格时序，仅靠 synchronized 不够，还得配合 volatile 或显式锁的 condition。

• 确认锁对象是同一个：打印 System.identityHashCode(lock) 看是否恒定
• 别在 lambda 或匿名内部类里直接用局部变量当锁对象（可能被编译器捕获成新对象）
• 调试时加日志别放在同步块外——日志输出本身不是原子的，可能掩盖真实执行顺序

同步的本质是“谁等谁”，不是“有没有加关键字”。锁对象选错，就像拿钥匙开了隔壁房间的门，看着上了锁，其实谁都进得去。

本篇关于《Java同步关键字使用详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！