缩小同步代码块范围比更换锁类型更有效，因其直接降低单次持锁耗时t和请求频率f的乘积，从而减少线程排队、上下文切换与cpu空转；例如将db写入移出同步块可使t从30ms降至0.2ms，吞吐提升百倍。
因为锁竞争的瓶颈不在“用什么锁”，而在“锁住多久”和“有多少线程在等”。减小同步代码块范围直接压缩临界区执行时间，从根源上降低线程排队、上下文切换和CPU空转，效果比换用 ReentrantLock 或 StampedLock 更立竿见影。
锁竞争的本质是时间与频率的乘积
可伸缩性受限于两个硬指标：单次持锁耗时（T）、单位时间内请求锁的次数（F）。总等待开销 ≈ T × F。哪怕换成号称“高性能”的 StampedLock，若里面仍包裹着 30ms 的数据库写入或网络调用，T 依然很大，其他线程照样卡住。而把耗时操作移出同步块，T 可能从 30ms 降到 0.2ms，提升百倍以上并发吞吐。
缩小范围能规避三类隐性开销
- 避免阻塞式IO拖累整个锁：比如在 synchronized 块里调用 notifyAll() 推送消息（涉及网络发送），会让所有后续线程干等；移到锁外后，仅状态变更部分受保护，推送异步化
- 减少不必要的内存可见性刷新：每次 exit 同步块，JVM 都要强制刷写共享变量到主内存；若块内混杂了无关的本地计算或日志打印，白白触发多次 volatile 语义开销
- 降低锁升级概率：synchronized 在高竞争下会从偏向锁 → 轻量锁 → 重量锁；而轻量锁依赖 CAS 自旋，一旦临界区过长，自旋失败率飙升，迅速退化为系统级互斥，引发大量上下文切换
实际优化对比：以房间进出为例
原始写法把 DB 更新和全员通知全包进 synchronized 方法里，导致每个 join/exit 操作平均持锁 18ms；优化后只保留玩家集合增删 + 房间状态判断（
高级锁不是万能解药
ReentrantLock 支持中断和超时，但不缩短临界区；StampedLock 的乐观读虽快，但写操作仍是排他锁，且一旦发生写冲突，仍需重试或降级为悲观写锁。它们解决的是“锁的功能短板”，而非“锁的时间浪费”。当核心问题是“锁太久”，最有效的动作永远是——让锁里只做最必要、最快的事。
