如何在 Java 中通过 synchronized(this) 实现代码块级别的线程安全

如何在 Ja va 中通过 synchronized(this) 实现代码块级别的线程安全

为什么 synchronized(this) 不能随便用

先明确一点：synchronized(this) 确实能实现加锁，但它锁住的是当前实例对象本身。问题恰恰出在这里——一旦这个对象被外部持有、暴露或在特定框架（如Spring）中被复用，就可能引发意料之外的锁竞争，甚至直接导致死锁。

举个典型的场景：在Spring管理的单例Bean中，如果多个业务方法都使用了 synchronized(this)，那么这些方法实际上是在串行执行。表面上看代码是并发的，但性能瓶颈已经形成，排查起来还特别困难。

常见的错误现象包括：抛出 IllegalMonitorStateException（通常是因为在同步块外调用了 wait() 或 notify()）、线程莫名卡死、以及系统吞吐量断崖式下跌却没有任何错误日志。

• 适用边界：它只适用于那些生命周期明确可控的场景，比如手动 new 出来的工具类实例，并且确保这个实例不会传递给其他模块使用。
• 继承风险：如果类可能被继承，子类重写方法时也用了 synchronized(this)，父类的锁行为可能会被意外覆盖或干扰。
• 静态资源无效：它无法保护静态字段，因为 this 是实例级别的。保护静态资源需要改用 synchronized(ClassName.class)。

synchronized(this) 不能随便用，因其锁的是当前实例对象，若该对象被外部持有、复用（如Spring单例Bean），会导致全局串行、性能骤降；易引发IllegalMonitorStateException、死锁或锁失效，仅适用于生命周期可控且不被继承/暴露的手动new实例。

synchronized(this) 的正确写法和边界条件

使用它的核心原则是：确保临界区只包含真正需要互斥的操作，并且锁的粒度要与业务语义严格对齐。

以账户扣款为例，必须将“读取余额→校验→执行扣减→写回结果”这一整个操作链锁住，形成一个原子操作。如果只锁住最后一行赋值语句，前面的读取和校验步骤就可能被其他线程干扰，导致数据不一致。

public void withdraw(double amount) {
    synchronized(this) { // 锁住当前 Account 实例
        if (balance >= amount) {
            balance -= amount; // 这里才是临界操作
        } else {
            throw new IllegalStateException("Insufficient funds");
        }
    }
}

• 锁对象必须稳定：锁对象（这里是 this）引用必须是 final 或不可变的。如果在构造函数中就将 this 发布出去（例如注册为监听器或启动新线程），可能导致锁在完全初始化前就被获取，从而失效。
• 警惕外部调用：禁止在同步块内部调用外部可重入的方法（如回调函数或第三方SDK方法），否则可能因反向持锁而造成难以排查的死锁。
• 避免循环内加锁：尽量不要在循环体内部使用 synchronized(this)，尤其是当循环次数不确定时。这很容易演变成一种隐式的“长锁”，严重阻塞其他线程。

比 synchronized(this) 更安全的替代方案

坦白说，多数情况下，直接锁 this 并非最佳选择。一种更可控、更安全的做法是显式声明一个私有的锁对象，将锁的作用域严格隔离在类内部：

private final Object lock = new Object();

public void updateCache() {
    synchronized(lock) {
        cache.clear();
        cache.putAll(fetchFromDB());
    }
}

• 封装性优势：synchronized(lock) 将锁封装在类内部，外部代码无法干扰，也不依赖于对象本身的身份（identity）。
• 区分读写场景：如果需要区分读操作和写操作，应考虑使用 ReentrantReadWriteLock，而不是试图用多个 synchronized(this) 块来生硬地组合。
• 无锁化尝试：对于简单的计数器或状态更新，可以优先考虑 AtomicInteger、AtomicReference 等原子类。它们在底层通常采用CAS操作，无锁且性能更高。

立即学习“Ja va免费学习笔记（深入）”；

调试时怎么确认 synchronized(this) 真正在起作用

代码写完了，怎么验证锁真的生效了？光看代码是不够的，必须结合运行时工具。JVM 提供的 jstack 命令可以抓取当前所有线程的状态快照。分析输出时，重点查找带有 - waiting to lock <0x...>（等待锁）和 - locked <0x...>（已持有锁）字样的行，它们清晰地揭示了线程的锁竞争关系。

还有一个极易被忽略的细节：在使用了OSGi、热部署或某些模块化容器的环境中，同一个类可能被不同的 ClassLoader 加载。这时，看似相同的 this 对象，实际上可能分属不同的类副本，导致 synchronized(this) 根本无法锁住预期的目标对象。遇到这类架构，需要格外小心。