synchronized修饰实例方法会锁住当前对象,因为JVM隐式以this为锁对象,同一对象的多线程互斥执行,不同对象则互不影响;静态方法锁Class对象,所有线程竞争同一把锁。

为什么synchronized修饰实例方法会锁住当前对象
因为 synchronized 修饰非静态方法时,JVM 会隐式使用 this 作为锁对象。同一对象的多个线程调用该方法时,只能有一个进入,其余阻塞;但不同对象的调用互不影响。
常见错误是以为“加了 synchronized 就全局安全”,结果多实例场景下仍出现竞态——比如每个请求创建新 Counter 实例,synchronized increment() 完全无效。
- 适用场景:共享同一对象状态的多线程访问,如单例工具类、缓存容器实例
- 等价写法:
public void increment() { synchronized(this) { count++; } } - 注意:若方法内抛出异常且未捕获,锁仍会自动释放,这点比手动
ReentrantLock更省心
synchronized静态方法锁的是Class对象
静态方法属于类而非实例,所以锁的是 MyClass.class。这意味着所有线程调用该静态方法时,无论通过哪个实例或直接通过类名,都竞争同一把锁。
典型误用:把本该保护全局计数器的逻辑放在实例方法里,却期望跨实例生效;正确做法是改用静态同步方法或显式锁 MyClass.class。
立即学习“Java免费学习笔记(深入)”;
- 等价写法:
public static synchronized void addGlobalCount() { globalCount++; }⇔public static void addGlobalCount() { synchronized(MyClass.class) { globalCount++; } } - 兼容性提示:Java 8+ 中
static synchronized与显式Class锁行为完全一致,无版本差异 - 性能影响:高并发下调用频繁的静态同步方法可能成为瓶颈,应优先考虑
AtomicInteger或分段锁
同步代码块比同步方法更灵活也更易出错
同步方法锁粒度固定(整个方法体),而同步代码块可精确控制锁范围和锁对象,但必须确保所有访问共享变量的路径都走同一把锁——漏掉一个就前功尽弃。
常见坑:用局部变量、new 出的对象或不同引用作为锁,导致实际没锁住;或者在同步块内调用外部可重入方法,引发死锁风险。
- 正确示例:保护共享
map的读写private final Map
cache = new HashMap<>(); private final Object lock = new Object(); public Object get(String key) { synchronized(lock) { return cache.get(key); } } public void put(String key, Object value) { synchronized(lock) { cache.put(key, value); } } - 危险写法:
synchronized(new Object())—— 每次新建对象,根本没锁住任何东西 - 锁对象建议:优先用
final字段,避免被意外修改或置为 null
不要在synchronized中调用外部可变对象的方法
如果在同步块内调用第三方对象的 toString()、hashCode() 或回调接口,而这些方法内部又尝试获取其他锁,极易触发死锁。JVM 不会帮你检测这种跨锁依赖。
最隐蔽的问题是日志:看似无害的 log.debug("value={}", obj),若 obj.toString() 耗时或加锁,就会拖慢整个临界区,甚至卡死其他线程。
- 安全做法:在同步块外准备好日志所需字符串,再进块操作数据
String logMsg = "before update: " + obj.getState(); // 先计算 synchronized(lock) { log.debug(logMsg); // 进块后只做轻量记录 obj.update(); } - 尤其警惕:集合类的
toString()可能遍历全部元素,若集合本身也被其他同步逻辑保护,就构成锁嵌套 - 调试技巧:线程 dump 中看到
WAITING on java.lang.Object@xxx且堆栈含toString或format,基本可定位到这类问题
synchronized,而是判断“到底该锁什么”“锁多久”“谁和谁必须串行”。很多并发 bug 表现在业务逻辑层,根源却在锁对象的选择和临界区边界划定上。










