精准锁范围技巧分享

本文深入解析了synchronized同步代码块的精准锁范围控制技巧，强调“只锁真正共享、必须互斥的资源”，从锁对象选择（推荐private final Object lock）、临界区最小化（剔除IO、日志、非共享计算等无关操作）、规避嵌套调用与隐式锁竞争，到结合业务场景灵活选用细粒度对象锁或原子操作，系统性地帮助开发者在保障线程安全的同时显著提升并发性能与系统稳定性。

synchronized 同步代码块要精确缩减锁对象范围，核心是：只对真正需要互斥访问的共享资源加锁，且锁对象必须是多个线程共同可见、不可变（或生命周期稳定）的最小粒度对象。

锁对象必须是共享且唯一的

锁对象不能是局部变量、this（除非明确所有调用都走同一实例）、或每次新建的对象。否则起不到同步作用。

• ✅ 推荐：用 private final Object lock = new Object(); 作为专用锁对象
• ✅ 若操作的是某个具体业务对象（如账户 account），可用 account 本身作锁（前提是该对象在多线程间稳定共享且不被替换）
• ❌ 避免：用 new Object()、String 字面量（可能因字符串常量池导致意外锁竞争）、或方法内临时对象

只包裹真正需要保护的临界区

把耗时操作、IO、日志、非共享变量计算等全部移出 synchronized 块。仅保留读写共享状态的最小语句集。

• ❌ 错误示例：
  synchronized(lock) {
    log.info("before");
    balance += amount;
    notifyAll();
    sendEmail(); // 不该在这里
  }
• ✅ 正确示例：
  log.info("before");
  synchronized(lock) {
    balance += amount;
    notifyAll();
  }
  sendEmail();

避免锁升级和嵌套扩大范围

不要在已持锁的情况下调用外部方法（尤其不可控的第三方方法），防止隐式锁竞争或死锁；也不要在 synchronized 块内创建新锁或调用其他 synchronized 方法（除非明确设计为可重入且粒度合理）。

• 检查被调方法是否内部也用了 synchronized —— 若锁对象不同，可能形成交叉锁；若锁对象相同，虽可重入但延长了持锁时间
• 对复合操作（如“先查再改”），考虑用更细粒度锁（如 ConcurrentHashMap 的分段锁）或 CAS 类原子操作替代

结合业务语义选择锁粒度

不是越小越好，而要匹配并发场景。例如：

• 用户级操作（如充值）→ 锁住 user.getId() 对应的唯一对象（可用 ConcurrentMap 缓存锁对象）
• 库存扣减 → 锁住 itemId 对应的锁，而非整个库存服务实例
• 全局计数器 → 可用 AtomicInteger，无需 synchronized

好了，本文到此结束，带大家了解了《精准锁范围技巧分享》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！