锁消除和锁粗化通过剔除冗余同步开销提升性能：锁粗化将多次加锁合并为一次，锁消除则完全移除无竞争的同步块，二者均不改变语义，却显著减少cas、内存屏障及锁状态切换等底层开销。
因为锁消除和锁粗化不是“压榨算力”，而是**砍掉大量无意义的锁开销**，把本该花在同步机制上的CPU时间，还给真正的业务逻辑。
锁粗化：把千次加锁变成一次，省下的是系统调用和状态切换
循环体内反复对同一对象加锁，表面看只是写了个 synchronized，实际每次执行都触发：
- monitorenter / monitorexit 字节码指令执行
- JVM 检查锁状态、更新计数器、可能触发自旋或线程挂起
- 即使无竞争，轻量级锁也要做 CAS 操作；偏向锁要校验线程 ID；重量级锁会陷入内核态
粗化后，这些开销从 N 次降到 1 次。比如 1000 次循环，原本要跑 2000 次锁相关逻辑，现在只跑 2 次——释放的不是“算力”，是被锁机制长期占用的 CPU 周期和缓存一致性开销。
锁消除：连锁都不留，直接跳过同步路径
当 JIT 通过逃逸分析确认对象完全不会被其他线程看到（如方法内 new 的 StringBuffer），它就敢把整个 synchronized 块“编译掉”：
- StringBuffer.append() 原本每个调用都带 monitorenter/monitorexit
- 消除后，字节码里根本不再出现这两个指令，变成纯本地方法调用
- 没有锁对象头操作、没有监视器竞争、没有内存屏障插入
这相当于把一段“假装线程安全”的代码，还原成单线程最优路径，性能直逼 StringBuilder——不是更快了，而是终于没被自己写的 synchronized 拖慢。
它们共同绕开了 JVM 同步机制的底层代价
synchronized 的真实成本不在 Java 代码行，而在：
- 对象头中 Mark Word 的频繁读写与 CAS 更新
- 多核下为保证锁语义而插入的内存屏障（影响指令重排和缓存行刷新）
- 锁升级过程中的状态迁移开销（偏向→轻量→重量）
锁粗化减少调用频次，锁消除直接剔除路径——两者都不改变程序行为，却让 JIT 能把资源聚焦在 doSomething() 这类真正干活的代码上。
