synchronized代码块应只包裹真正需要互斥的语句：锁对象推荐private final Object lock，避免用this或可变对象；禁放IO、耗时计算、外部调用等无关操作；细粒度锁需权衡死锁与开销。
synchronized 代码块必须只包住真正需要互斥的语句，否则锁范围过大，会直接拖垮并发吞吐量。
锁对象选 this 还是自定义 private final Object lock？
用 this 是最常见错误起点：一旦该对象被暴露给外部（比如作为返回值、被传入其他方法），就可能被意外加锁，造成死锁或不可控阻塞。
自定义锁对象才是可控方案：
-
private final Object lock = new Object();确保锁对象唯一、不可变、不对外暴露 - 避免与业务逻辑耦合——比如别用
private Integer count当锁，因为Integer是可变对象（自动装箱会创建新实例），导致锁失效 - 若需多个独立临界区（如读写分离），应为每个区域配独立锁对象，而非共用一个
哪些语句绝对不能放进 synchronized 块里？
任何与共享状态无关的操作，都属于“污染临界区”的行为，会无谓延长持锁时间。
- I/O 操作（
System.out.println、文件读写、网络请求）——它们耗时且不涉及锁保护的数据 - 耗时计算（比如字符串拼接、JSON 序列化、循环遍历大集合）
- 调用外部方法（尤其是你无法确认其是否也加锁或阻塞的方法），容易引发锁嵌套或死锁
- 对象构造（
new SomeObject()）本身不需同步，除非构造过程修改了被保护的共享状态
怎么验证锁范围是否真的缩到最小？
不能靠“看起来不多”来判断，得看实际执行路径和竞争热点：
- 用 JFR（Java Flight Recorder）或 Arthas 的
thread -b查看线程是否在synchronized块内长时间 WAITING / BLOCKED - 把疑似冗余代码临时移出同步块，再压测对比 QPS 和平均响应时间变化；如果性能没提升，说明那部分本来就不该在锁里
- 检查是否误将“读操作”锁住了——多数只读场景无需加锁，除非读取过程依赖多个变量的原子一致性（这时考虑
volatile或StampedLock）
为什么细粒度锁不一定总比粗粒度好？
锁太碎会引入额外开销和逻辑复杂度，不是越小越好：
- 多个细粒度锁之间若存在固定访问顺序（比如先锁 A 再锁 B），而不同线程按相反顺序申请，极易死锁
- 频繁新建锁对象（如每次方法调用都 new 一个
Object）会增加 GC 压力 - 当临界区极短（比如仅一行
counter++），用AtomicInteger替代synchronized更轻量，且无锁升级开销
真正难的不是“怎么写 synchronized”，而是判断哪几行代码构成一个不可分割的原子操作——这个边界一旦画错，要么锁不住，要么锁过头。业务语义永远优先于语法习惯。
