减少锁粗化范围是为了防止误用的不合理粗化，关键在缩短锁持有时间；需移出远程调用、I/O、序列化、同步日志、sleep等耗时操作；“读–处理–写”应拆分为外检查、内最小更新、后异步处理；用私有final锁对象控制作用域；连续小同步块若无状态依赖且整体≤1ms，可合理粗化。
减少锁粗化范围不是为了“避免锁粗化”，而是要识别并防止**误用的、不合理的锁粗化**——那种把本该细粒度保护的逻辑，生硬合并成一个大同步块的做法。真正影响停顿的，是锁持有时间过长，而非粗化本身。关键在于：只在必要时粗化，绝不在无关操作上延长临界区。
哪些操作必须从 synchronized 块中移出
以下耗时或非共享资源操作一旦混入同步块，就会直接拉长线程阻塞时间，引发明显停顿：
- 远程调用（HTTP、RPC、数据库查询）——这些动辄几十到几百毫秒，完全不该在锁内等待
- 文件读写、磁盘 I/O —— 与内存操作量级不同，极易拖垮锁持有时间
- JSON/XML 解析、复杂对象序列化 —— CPU 密集且无需共享状态保护
- 日志打印（尤其是同步日志框架如 Log4j 1.x）—— 可能触发磁盘刷写或锁竞争
- 睡眠（Thread.sleep）、定时等待 —— 显式放弃 CPU，却仍占着锁
如何安全地拆分“读–处理–写”流程
很多业务逻辑天然可解耦。例如订单创建中验证用户、查库存、更新缓存三步，只有最后一步真正修改共享状态：
- 先在同步块外完成所有检查（getUser、checkStock），拿到确定结果
- 仅用几行代码更新本地缓存 Map 或计数器，包裹在最小同步块中
- 更新完成后，再异步发通知、记审计日志等后续动作
这样，95% 以上执行时间脱离锁保护，线程几乎不排队。
立即学习“Java免费学习笔记（深入）”；
用私有 final 锁对象控制作用域
避免用 this 或 getClass() 作锁，否则外部代码可能意外参与锁竞争，导致不可控的停顿扩散：
- 声明 private final Object cacheLock = new Object();
- 所有涉及缓存读写的同步块统一用 synchronized(cacheLock)
- 确保这个锁对象不对外暴露、不被继承重写、不参与其他逻辑
作用域收得越紧，锁竞争面就越小，JVM 偏向锁和轻量级锁优化才更易生效。
警惕“伪粗化”：连续小同步块反而更差
如果一段逻辑里反复进出多个细粒度同步块（比如循环中每次 update 都加一次锁），JVM 反而会因频繁锁操作产生额外开销。此时合理粗化反而是优化：
- 把循环内对同一共享结构的多次修改，合并为一次批量操作
- 但前提是：这批操作之间无中间状态依赖，且整体耗时仍可控（建议 ≤ 1ms）
- 粗化后仍需排除 I/O、网络、日志等干扰项，否则就是“以粗化之名，行阻塞之实”
