标量替换不适用于局部变量表中的基本类型，因其作用对象是未逃逸的对象而非基本类型值；基本类型本就存于栈帧局部变量表，无堆分配过程，也无逃逸概念，故无法触发该优化。
局部变量表中的基本类型无法触发标量替换，根本原因在于：标量替换作用对象是“对象”，而非“基本类型变量”本身。
标量替换只针对堆中对象的拆解
标量替换（Scalar Replacement）是JVM逃逸分析后的一种优化手段，其核心动作是：将一个未逃逸的对象，拆解成它所包含的若干个基本类型字段（即标量），然后直接在栈上分配这些字段值，避免在堆中创建完整对象。
- 它处理的是对象实例的内存布局，比如 new User() 这样的对象，内部有 int age、String name 等字段；
- 而局部变量表里的 int num = 10 本身就是基本类型值，早已直接存于栈帧局部变量表的 slot 中，没有“对象结构”可拆；
- 标量替换不是把“基本类型变量”再进一步优化，而是把“本该在堆里、但可被拆开的基本类型字段”搬到栈上。
局部变量表本身已是栈上存储，无需替换
Java虚拟机规范明确：方法的局部变量（含基本类型和引用）都保存在当前线程栈帧的局部变量表中。这个区域天然就在栈上，访问快、生命周期短、自动回收。
- int、boolean、double 等基本类型值，直接写入 slot，不涉及对象头、引用关系或GC管理；
- 既然它们本来就不在堆里，自然不存在“从堆移到栈”的优化路径，标量替换也就无从谈起；
- 真正需要优化的是那些 new 出来但仅限本方法使用的对象——它们本该进堆，却因逃逸分析被判定为“可拆”，才轮到标量替换出手。
标量替换的前提是对象未逃逸，而基本类型变量无“逃逸”概念
逃逸分析判断的是对象的动态作用域：是否被赋值给堆中其他对象、是否作为返回值传出、是否被其他线程访问等。只有对象才有“逃逸”与否的问题。
- 局部变量中的基本类型（如 long x = 42L）是纯值，没有身份、没有引用、不可共享，谈不上“逃逸”；
- JVM不会、也不能对一个独立的 int 变量做逃逸分析，更不会基于它生成任何优化决策；
- 所以，没有逃逸分析结论 → 没有标量替换触发条件 → 基本类型局部变量始终原样留在局部变量表中。
简单说：标量替换不是给基本类型“升级”，而是给轻量级对象“减负”。它解决的是“不该堆分配却堆分配了”的问题，而不是“栈上变量还能怎么更快”。
