synchronized(this) 不能随便用，因其锁的是当前实例对象，若该对象被外部持有、复用（如Spring单例Bean），会导致全局串行、性能骤降；易引发IllegalMonitorStateException、死锁或锁失效，仅适用于生命周期可控且不被继承/暴露的手动new实例。
为什么 synchronized(this) 不能随便用
它确实能加锁，但锁的是当前实例对象（this），一旦这个对象被外部持有、暴露或复用，就可能引发意外的锁竞争甚至死锁。比如 Spring 管理的单例 Bean，多个业务方法都用 synchronized(this)，实际是全类串行执行——性能崩了还查不出原因。
常见错误现象：IllegalMonitorStateException（没在同步块里调用 wait()/notify()）、线程卡死、吞吐量骤降但无报错。
- 只适用于明确控制对象生命周期的场景，例如手动 new 出来的工具类实例，且不传给其他模块
- 若类会被继承，子类重写方法并也用
synchronized(this)，锁行为可能被意外覆盖 - 不能保护静态字段，因为
this是实例级，静态资源需用synchronized(ClassName.class)
synchronized(this) 的正确写法和边界条件
必须确保临界区只包含真正需要互斥的操作，且锁粒度与业务语义对齐。例如账户扣款，要锁住“读余额→校验→扣减→写回”整个原子链，不能只锁最后一行赋值。
public void withdraw(double amount) {
synchronized(this) { // 锁住当前 Account 实例
if (balance >= amount) {
balance -= amount; // 这里才是临界操作
} else {
throw new IllegalStateException("Insufficient funds");
}
}
}- 锁对象必须是 final 或不可变引用；如果
this在构造中被发布（如注册监听器、启动线程），可能导致锁失效 - 禁止在同步块内调用外部可重入方法（如回调、第三方 SDK 方法），否则可能反向持锁造成死锁
- 不要在循环体内部放
synchronized(this)，尤其当循环次数不确定时——容易演变成隐式长锁
比 synchronized(this) 更安全的替代方案
多数情况下，你应该避免直接锁 this。更可控的方式是显式声明私有锁对象，隔离作用域：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
private final Object lock = new Object();
<p>public void updateCache() {
synchronized(lock) {
cache.clear();
cache.putAll(fetchFromDB());
}
}-
synchronized(lock)把锁封装在类内部，外部无法干扰，也不依赖对象身份 - 若需区分读写，改用
ReentrantReadWriteLock，而不是靠多个synchronized(this)块硬凑 - 简单计数/状态更新优先考虑
AtomicInteger、AtomicReference，它们无锁且更快
调试时怎么确认 synchronized(this) 真正在起作用
光看代码没法验证锁是否生效，得结合线程 dump 和日志观察。JVM 提供 jstack <pid> 可抓当前所有线程状态，重点关注 - waiting to lock <0x...> 和 - locked <0x...> 行。
容易被忽略的一点：同一个对象在不同 ClassLoader 下的 this 不等价。如果你的应用用了 OSGi、热部署或模块化容器，synchronized(this) 可能根本没锁住预期的对象——因为看似相同的类其实是不同 ClassLoader 加载的副本。
