JVM通过标量替换和栈上分配优化避免堆分配：标量替换拆解不逃逸对象为局部变量；栈上分配将不逃逸对象内存置于栈帧中；二者均依赖逃逸分析，需编写逃逸友好代码并结合JVM参数验证。
Java虚拟机（JVM）通过标量替换（Scalar Replacement）和栈上分配（Stack Allocation）优化，可在满足条件时避免对象在堆上分配，从而降低GC压力、提升性能。但这些优化由JVM自动触发，开发者无法直接调用，需理解其原理并编写“友好”的代码来促成它们。
标量替换：拆解对象，只保留用得到的字段
标量替换是指JVM在JIT编译阶段，若判定某个对象不会逃逸出当前方法作用域，且仅被当作若干独立字段使用（如读取obj.x、obj.y），就可能将该对象“拆开”，直接用局部变量存储其字段值，完全不创建对象实例。
- 前提条件：对象必须是“不逃逸”的——不能被赋值给静态变量、不能作为参数传入其他方法、不能被其他线程访问、不能被写入堆中对象的字段
- 典型适用场景：短生命周期的工具类对象，如
Point p = new Point(1, 2); int d = p.x + p.y;，若p未逃逸，JVM可能只生成两个int变量x和y - 验证方式：启用
-XX:+PrintEscapeAnalysis和-XX:+PrintOptoAssembly（配合调试版JDK），或观察GC日志中对应对象分配量是否显著下降
栈上分配：对象仍在，但内存不在堆里
栈上分配是逃逸分析的延伸结果：当JVM确认对象不会逃逸，且标量替换不可行（例如对象被整体传参、调用非平凡方法、或存在反射/同步等阻碍拆解的操作），就可能将其内存分配在当前线程的Java栈帧中，而非堆内存。对象随方法退出自然消亡，无需GC介入。
- 注意：HotSpot JVM自Java 6u23起支持逃逸分析，但默认开启；Java 8及以后版本中，栈上分配实际效果受限于JIT编译稳定性与对象复杂度，并非所有不逃逸对象都会被栈分配
- 常见失效原因：对象有
synchronized块（即使锁对象是自身）、调用了getClass()或wait()/notify()、被System.identityHashCode()取过哈希码、或字段类型含未inline的方法调用 - 可配合
-XX:+DoEscapeAnalysis -XX:+EliminateAllocations显式启用相关优化（后者控制是否执行标量替换与栈分配）
让代码更“逃逸友好”的实用建议
优化成败关键在于协助JVM准确判断逃逸性。以下写法更容易触发优化：
立即学习“Java免费学习笔记（深入）”；
- 避免将局部对象赋值给
static字段或类级别集合（如CACHE.put(key, obj)） - 方法内创建的对象，尽量只用于计算、返回基本类型或final字段值，少用
toString()、clone()等易引发逃逸的操作 - 用
record（Java 14+）定义简单数据载体，其不可变性和紧凑结构更利于JIT分析 - 对频繁创建的小对象（如包装类、临时DTO），考虑复用对象池——但需权衡同步开销；标量替换本质是比对象池更轻量的“零成本复用”
别依赖，但可观察与引导
标量替换与栈上分配属于JIT运行时优化，受代码路径、循环次数、方法内联深度、JVM版本及参数影响极大。同一段代码在不同负载下可能有时优化、有时不优化。
- 不要为迎合优化而牺牲可读性，例如强行拆解逻辑清晰的对象为多个原始变量
- 优先用JMH做微基准测试，对比开启/关闭逃逸分析（
-XX:-DoEscapeAnalysis）时的吞吐量与GC次数变化 - 生产环境关注G1或ZGC的GC日志中
Allocation Rate是否平稳下降，比纠结某次是否栈分配更有实际意义
