synchronized实例方法锁的是this对象而非方法本身，等价于synchronized(this)，因此同一对象的多个同步方法互斥，不同对象则不互斥；静态方法锁Class对象；synchronized代码块需显式指定锁对象，应避免用this、字符串常量等；wait/notify必须在synchronized块中调用以确保线程安全；JDK6后synchronized经优化（偏向锁、轻量级锁等）在低竞争下性能接近ReentrantLock。
为什么synchronized方法锁的是this对象而不是方法本身
synchronized 实例方法等价于在方法体开头加 synchronized(this)，所以锁住的是当前实例对象（this），不是方法字节码或类定义。多个线程调用同一个对象的不同 synchronized 实例方法时，仍会互斥；但调用不同对象的同名方法，则不互斥。
常见误解是“方法被锁住了”，实际是“调用该方法的对象被锁住了”。这也是为什么静态 synchronized 方法锁的是 Class 对象——因为没有 this，只能锁类元数据。
- 同一对象：两个 synchronized 实例方法不能并发执行
- 不同对象：即使方法签名完全一样，也能并发执行
- 静态方法和实例方法之间不互斥，因为锁对象不同（
MyClass.classvsthis）
synchronized代码块为什么要显式指定锁对象
使用 synchronized(obj) 代码块时，必须传入一个非 null 的引用类型对象作为锁。这个对象决定了同步粒度和作用范围。选错锁对象是并发 bug 的高发区。
典型错误包括：synchronized(new Object())（每次新建对象，根本没锁住）、synchronized(this) 在 public 方法中暴露锁（外部可恶意持有导致死锁）、synchronized(字符串常量)（可能因字符串驻留意外共享锁）。
立即学习“Java免费学习笔记（深入）”；
- 优先用私有 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 还是不是“重”，不如先确认你锁住的那段代码，是不是真的需要串行执行。
