synchronized同步代码块应精准缩小锁范围：只对共享资源加锁，锁对象须共享唯一、稳定不变；推荐private final object lock；临界区仅含必要语句；避免锁嵌套与外部调用；按业务选细粒度锁或原子操作。
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
