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。
酷纬企业网站管理系统Kuwebs是酷纬信息开发的为企业网站提供解决方案而开发的营销型网站系统。在线留言模块、常见问题模块、友情链接模块。前台采用DIV+CSS,遵循SEO标准。 1.支持中文、英文两种版本,后台可以在不同的环境下编辑中英文。 3.程序和界面分离,提供通用的PHP标准语法字段供前台调用,可以为不同的页面设置不同的风格。 5.支持google地图生成、自定义标题、自定义关键词、自定义描
这不仅是语法限制,更是语义保障:只有在同步上下文中,才能安全地检查条件并决定是否等待;也只有在锁保护下,才能确保 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 还是不是“重”,不如先确认你锁住的那段代码,是不是真的需要串行执行。










