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”，而是判断哪几行代码构成一个不可分割的原子操作——这个边界一旦画错，要么锁不住，要么锁过头。业务语义永远优先于语法习惯。