synchronized如何精准锁定同步资源

本文深入剖析了Java中synchronized代码块的锁粒度设计误区与最佳实践，指出synchronized(this)因锁定整个对象实例而极易导致锁范围过宽，不仅拖慢无关操作、降低并发吞吐量，还可能因对象暴露引发跨业务锁竞争甚至死锁；文章强调应改用private final Object作为专用锁对象以实现精准、安全、解耦的细粒度同步，并进一步阐明锁粒度需严格匹配共享资源的真实边界——既不可过度粗放，也不应盲目求细，同时警示切勿在临界区内执行IO、网络调用或外部方法，确保同步逻辑轻量、可控、可靠。

为什么 synchronized(this) 容易锁过宽

用 synchronized(this) 锁整个实例，看似简单，实则常把无关逻辑也拖进临界区。比如一个对象既有计数器操作，又有日志打印、网络调用或缓存更新——这些都不该被锁住。锁范围一宽，线程阻塞概率就上升，吞吐量直线下滑。

更隐蔽的问题是：如果该对象被暴露给外部（如作为返回值、传入回调），其他代码可能也拿 this 加锁，无意中形成跨业务的锁竞争，甚至死锁。

实际建议：

• 避免在 public 方法里直接写 synchronized(this)
• 不把加锁对象作为方法返回值或参数传出
• 检查类是否实现了接口或被代理（Spring AOP 可能绕过 synchronized）

用 private final Object 作锁对象的实操要点

声明一个专用锁对象是最常用、最可控的方式。它和业务逻辑解耦，生命周期稳定，且不会被外部干扰。

正确写法示例：

private final Object counterLock = new Object();
private int count = 0;

public void increment() {
    synchronized (counterLock) {
        count++;
    }
}

关键注意点：

• 必须是 private —— 防止外部获取并误用
• 必须是 final —— 确保引用不变；若运行中重新赋值，会导致不同线程锁在不同对象上，同步失效
• 不要用 String、Integer 等常量池对象做锁，例如 synchronized("lock") 或 synchronized(127)，它们可能被 JVM 共享，引发意外交互

锁粒度要匹配共享资源的真实边界

不是“越细越好”，而是“刚好包住真正共享的部分”。比如一个类管理多个独立计数器，就不该共用一把锁：

private final Object lockA = new Object();
private final Object lockB = new Object();
private int countA = 0;
private int countB = 0;

public void incrementA() {
    synchronized (lockA) { countA++; }
}

public void incrementB() {
    synchronized (lockB) { countB++; }
}

但若两个字段存在强依赖（比如 balance 和 frozenBalance 必须原子更新），强行拆锁反而破坏一致性。此时应合并为一个锁，或改用 ReentrantLock 配合条件队列，甚至考虑 StampedLock。

判断依据：

• 多个变量是否在同一个不变性约束下（invariant）
• 是否有读写组合操作（如先 check 再 update）
• 是否被同一组业务逻辑高频并发访问

别在 synchronized 块里调用外部方法或等待 IO

这是最容易被忽略的性能雷区。一旦在临界区内调用可能阻塞或耗时的操作，等于把整把锁“焊死”在慢路径上。

典型错误：

• 在 synchronized 块里发 HTTP 请求
• 调用第三方 SDK 的同步方法（如数据库 executeUpdate()）
• 调用另一个对象的 public 方法，而该方法内部又加了锁（隐式锁嵌套）

安全做法：

• 把 IO、网络、复杂计算等移出 synchronized 块
• 只在块内做内存读写、简单判断、本地状态变更
• 必要时用双重检查 + volatile（如单例初始化），而非全程加锁

锁对象本身不能变，临界区里的操作也不能“带出”锁的控制力——这两点一旦松动，同步就形同虚设。

今天关于《synchronized如何精准锁定同步资源》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！