栈上分配与标量替换是JIT基于逃逸分析的优化：若对象不逃逸，则优先标量替换（拆解为标量存栈/寄存器），否则栈上分配，均避免堆分配与GC；二者依赖C2编译，默认开启，对短生命周期小对象效果显著。
栈上分配：让对象避开堆内存
栈上分配（Stack Allocation）是JIT编译器在方法执行期间，将本该分配在堆上的对象，改为直接分配在当前线程的Java虚拟机栈帧中。前提是JIT能**确定该对象的生命周期完全局限在当前方法内**，且不会逃逸到其他线程或方法外。
关键判断依据是**逃逸分析（Escape Analysis）**的结果。如果JIT发现一个新创建的对象： - 没有被赋值给静态字段或堆中已有对象的字段； - 没有作为参数传递给可能“逃逸”的方法（如非私有、非final方法，或可能被子类重写的方法）； - 没有被同步块（synchronized）作为锁对象使用（因为锁对象需在堆上保证可见性与一致性）； - 方法返回值不包含该对象（或其引用）； 那么它就属于“不逃逸”对象，具备栈上分配的前提条件。
栈上分配的好处很直接：避免堆内存分配开销和后续GC压力。对象随方法栈帧一起自然消亡，无需GC介入回收。但要注意：这不是JVM规范要求的行为，而是HotSpot JIT（特别是C2编译器）的优化策略，默认开启（-XX:+DoEscapeAnalysis），且仅对已触发C2编译的热点方法生效。
标量替换：拆解对象，只留有用字段
标量替换（Scalar Replacement）常与栈上分配配合出现，但它更进一步——不是把整个对象放栈上，而是**彻底不分配对象内存，只单独分配其内部的基本类型字段（标量）到栈上或寄存器中**。
所谓“标量”，指无法再分解的、无ID的数据单元，比如int、long、double、boolean，以及不逃逸的、不可变的、仅含标量字段的简单对象（如Point、ImmutablePair）。只要对象满足不逃逸条件，且所有字段本身也满足标量条件（即字段不指向堆对象、不被外部访问），JIT就可能将其“打散”。
例如：
public Point createPoint() {
return new Point(10, 20); // Point只有两个int字段x,y，且未逃逸
}JIT可能优化为：不创建Point实例，而直接把10和20作为局部变量存在栈/寄存器中，后续用到x、y的地方直接读取对应位置。连对象头、对齐填充等开销都省了。
这项优化对短生命周期的小对象（如中间计算封装类、函数式接口中的临时容器）效果显著，但对含引用字段、数组、或重写了finalize()的对象无效——因为它们无法安全“去对象化”。
两者关系与触发前提
栈上分配和标量替换不是互斥选项，而是优化链条上的不同层级：
- 先做逃逸分析，判定对象是否逃逸；
- 如果不逃逸，优先尝试标量替换（更激进、收益更高）；
- 若标量替换不可行（比如对象含引用字段但该字段本身也不逃逸），才考虑栈上分配；
- 若连栈上分配都不满足（比如栈空间不足、方法太复杂导致分析失败），则回落到常规堆分配。
二者都依赖C2编译器的深度分析能力，因此只在方法被频繁调用、触发分层编译（Tiered Compilation）并最终被C2编译后才生效。可通过-XX:+PrintEscapeAnalysis和-XX:+PrintOptoAssembly观察分析日志和汇编结果。
实际影响与调优注意点
这些优化对开发者透明，但理解它们有助于写出更易被JIT友好的代码：
- 避免不必要的对象封装，尤其是短生命周期的“数据搬运工”类；
- 尽量让小对象保持不可变、字段为基本类型或同样不逃逸的轻量对象；
- 减少对对象引用的过度传播（如层层传参、塞入集合、赋值给static字段）；
- 不必手动“复用对象”或搞对象池——现代JIT在合适场景下比人更懂何时该省；
- 启用逃逸分析（默认已开），但禁用它（-XX:-DoEscapeAnalysis）可用于对比性能差异，验证优化是否生效。
需要强调的是：这些是运行时动态决策，取决于具体执行路径、数据流和编译时机，不能靠代码写法100%保证。但遵循简洁、局部、不可变的原则，就是在为JIT铺路。
