非静态同步方法锁this对象，静态同步方法锁类的Class对象；锁对象不一致会导致线程安全失效，应统一锁粒度并避免误用字符串或公共常量作锁。
同步方法默认锁的是哪个对象
非静态同步方法锁的是 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()）能隐藏锁、缩小作用域、避免外部误同步。
使用场景：多个方法需要协同访问一组字段，但又不想让整个实例被锁死（比如读写分离时，只对写操作加细粒度锁）。
立即学习“Java免费学习笔记（深入）”；
- 用
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 或匿名内部类里直接用局部变量当锁对象（可能被编译器捕获成新对象）
- 调试时加日志别放在同步块外——日志输出本身不是原子的，可能掩盖真实执行顺序
