synchronized关键字使用技巧与详解

本文深入剖析了Java中synchronized关键字的核心机制与实战要点：它并非锁定方法本身，而是基于对象（实例方法锁this、静态方法锁Class）实现互斥；强调synchronized代码块需谨慎选择锁对象，推荐使用私有final对象以避免死锁和意外共享；明确wait/notify必须在对应锁的synchronized块内调用，以保障条件检查与状态更新的原子性；同时指出JDK 6后synchronized已通过偏向锁、轻量级锁等优化大幅提升性能，在低竞争场景下表现优异——但真正影响并发性能的往往不是锁本身，而是锁粒度是否合理、临界区是否包含不必要的耗时操作。

为什么synchronized方法锁的是this对象而不是方法本身

synchronized 实例方法等价于在方法体开头加 synchronized(this)，所以锁住的是当前实例对象（this），不是方法字节码或类定义。多个线程调用同一个对象的不同 synchronized 实例方法时，仍会互斥；但调用不同对象的同名方法，则不互斥。

常见误解是“方法被锁住了”，实际是“调用该方法的对象被锁住了”。这也是为什么静态 synchronized 方法锁的是 Class 对象——因为没有 this，只能锁类元数据。

• 同一对象：两个 synchronized 实例方法不能并发执行
• 不同对象：即使方法签名完全一样，也能并发执行
• 静态方法和实例方法之间不互斥，因为锁对象不同（MyClass.class vs this）

synchronized代码块为什么要显式指定锁对象

使用 synchronized(obj) 代码块时，必须传入一个非 null 的引用类型对象作为锁。这个对象决定了同步粒度和作用范围。选错锁对象是并发 bug 的高发区。

典型错误包括：synchronized(new Object())（每次新建对象，根本没锁住）、synchronized(this) 在 public 方法中暴露锁（外部可恶意持有导致死锁）、synchronized(字符串常量)（可能因字符串驻留意外共享锁）。

• 优先用私有 final 对象作锁：private final Object lock = new Object();
• 避免用 this、public 字段、getClass()、字符串字面量作锁
• 若需保护某字段，锁对象应与该字段生命周期一致（如用该字段所属对象）

wait/notify必须在synchronized块里调用的原因

wait()、notify()、notifyAll() 是 Object 的 native 方法，它们操作的是对象的“内置锁（intrinsic lock）”和“等待队列（wait set）”。JVM 要求调用线程必须已持有该对象的锁，否则抛 IllegalMonitorStateException。

这不仅是语法限制，更是语义保障：只有在同步上下文中，才能安全地检查条件并决定是否等待；也只有在锁保护下，才能确保 notify() 唤醒后条件已被正确更新。

• 必须在 synchronized(obj) 块内调用 obj.wait() 和 obj.notify()
• 推荐用 while 循环检查条件，而非 if（防止虚假唤醒）
• 不要假设 notify() 一定唤醒某个特定线程——唤醒顺序不可控

synchronized在JDK 6之后的性能到底还差吗

从 JDK 6 开始，HotSpot 对 synchronized 做了大量优化：偏向锁 → 轻量级锁 → 重量级锁的升级路径、锁消除、锁粗化。在无竞争或低竞争场景下，synchronized 性能已接近甚至优于 ReentrantLock。

但这些优化有前提：偏向锁默认开启（JDK 15+ 已移除），且依赖运行时逃逸分析和锁对象的使用模式。一旦发生多线程竞争，偏向锁会撤销并膨胀为轻量级锁；持续竞争则升级为重量级锁（系统互斥量），此时开销明显上升。

• 单线程主导场景：synchronized 几乎零开销（偏向锁生效）
• 短临界区 + 低竞争：轻量级锁自旋成功，避免挂起线程
• 长临界区或高竞争：升级为重量级锁，性能下降显著
• 注意：-XX:-UseBiasedLocking 可关闭偏向锁，便于压测真实竞争表现

真正容易被忽略的是锁的粒度和持有时间——再快的锁，如果包裹了 IO、远程调用或复杂计算，都会成为瓶颈。与其纠结 synchronized 还是不是“重”，不如先确认你锁住的那段代码，是不是真的需要串行执行。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~