栈上分配和标量替换是JVM基于逃逸分析的两种优化：标量替换要求对象完全可分解且仅字段被访问，栈上分配则对大小更宽容但受限于栈空间；二者均需对象不逃逸且JIT充分编译。
栈上分配和标量替换都是JVM基于逃逸分析对高频短命变量做的底层优化，目标一致——绕开堆分配、减少GC压力；但实现方式和适用边界明显不同。选对策略，比强行“调参”更有效。
看对象是否真能被“拆开”
标量替换要求对象彻底可分解：所有字段必须是基本类型（int、double等）或不可变的、仅含标量字段的简单对象（如Point、ImmutablePair），且字段本身不被外部访问、不触发反射或同步操作。
- ✅ 适合标量替换：
new BigDecimal("1.23")不行（内部含数组和复杂状态）；但new Point(10, 20)可以——只有两个int字段，无引用、无方法副作用 - ❌ 栈上分配可能接手：若对象含一个
String字段或调用了getClass()，标量替换失效，但只要不逃逸，仍可能走栈上分配
看访问模式是否“只用字段，不用对象”
标量替换生效的关键，是JIT观察到代码中只读写对象的个别字段（如p.x、p.y），而从未把整个对象当参数传入、未取其hashCode()、未作为锁使用。
- 如果方法里写了
return p;或someList.add(p);，对象已逃逸，两种优化都失效 - 如果只写
int d = p.x * p.x + p.y * p.y;，且p生命周期完全在方法内，标量替换概率极高
看对象大小与JIT编译稳定性
栈上分配对对象尺寸更宽容，但受栈空间限制；标量替换几乎无尺寸开销，却对代码结构更敏感。
- 大对象（如含10个以上字段或嵌套对象）即使不逃逸，也大概率跳过标量替换，转为栈上分配（前提是未触发同步/identityHashCode等禁用项）
- C2编译器需稳定触发（方法足够热），冷路径或启动初期的高频临时对象，可能始终走堆分配——这不是代码问题，而是JIT尚未介入
验证比猜测更可靠
别依赖日志说“已开启逃逸分析”，要实测效果：
- 加参数
-XX:+PrintEscapeAnalysis -XX:+UnlockDiagnosticVMOptions -XX:+PrintOptoAssembly（需调试版JDK），看JIT日志中是否出现scalar replaced或stack allocated - 对比开启
-XX:+EliminateAllocations前后，对应方法的GC日志中对象分配量是否下降（如G1的Allocation Rate） - 用JMH压测同一逻辑，观察分配速率（
gc.alloc.rate.norm）和吞吐变化
