jvm逃逸分析不直接内联，而是通过判定arrays中间对象是否逃逸来支撑标量替换或方法内联；需用-xx:+printescapeanalysis等参数验证实际逃逸状态，再结合-xx:+printeliminateallocations确认优化生效。
评估 JVM 逃逸分析对 Arrays 工具类中临时中间对象（如 Arrays.asList() 返回的内部 List、Arrays.sort() 中的辅助数组等）是否触发内联优化，关键不是看“有没有内联”，而是看逃逸分析是否让这些对象不逃逸 → 进而支撑标量替换或方法内联等后续优化。HotSpot 并不支持栈上分配，所谓“优化”本质是 JIT 消除对象创建逻辑或拆解字段为寄存器操作。
先确认这些中间对象是否真的“不逃逸”
Arrays 类多数静态方法返回的是轻量封装对象（如 ArrayList 的子类 Arrays$ArrayList），它们的逃逸行为高度敏感：
-
Arrays.asList(new Integer[]{1,2,3})：传入的数组本身可能被外部持有，JVM 直接放弃逃逸分析（日志显示global escape） -
Arrays.stream(...).map(...).toArray()：Stream 链中中间对象（如Spliterator、Node）常被 lambda 捕获或传入未知方法，极易判定为arg escape -
Arrays.fill(arr, val)或Arrays.equals(a,b)：不返回新对象，仅操作入参数组 → 无新建对象，逃逸分析不介入，但方法本身易被内联
用诊断参数观察真实编译决策
仅靠代码结构无法判断，必须启用 JIT 日志验证：
- 加参数：
-XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis -XX:CompileThreshold=10（加速编译，仅测试用） - 运行含
Arrays调用的热点循环，观察日志中对应方法是否标记为does not escape；若出现escapes method或arg escapes，说明后续优化基本失效 - 再配合
-XX:+PrintEliminateAllocations：若某段代码本应 new 出Arrays$ArrayList却无 alloc 日志，且逃逸分析显示未逃逸，才说明标量替换或内联消除生效
内联优化依赖逃逸分析的前提条件
逃逸分析本身不直接“做内联”，但它为方法内联扫清障碍：
- 若
Arrays.binarySearch()接收一个未逃逸的Comparable对象作为参数，JIT 更可能将其内联（因可证明该对象不会被其他线程修改） - 若
Arrays.copyOf()中新建的数组被判定为局部未逃逸，且方法体足够小，C2 编译器更倾向将整个方法内联进调用方，进而把数组分配逻辑一并消除 - 但若调用链中存在虚方法（如
Object.equals()）、反射（Array.get()）、或非 private 方法调用，JIT 会保守放弃内联，逃逸分析结果也失去意义
实操建议：写法比参数更重要
与其调参数，不如控制对象生命周期：
- 避免将
Arrays.asList()结果赋值给字段、传给线程池、或作为返回值暴露出去 - 优先用原始类型数组 + 手动遍历，替代
Arrays.stream().boxed().collect()等易逃逸链路 - 对高频调用场景，用
@ForceInline（JDK 19+）标注自定义工具方法，并确保其参数和返回值都满足不逃逸条件 - 用 JMH 基准测试对比：关闭逃逸分析（
-XX:-DoEscapeAnalysis）后性能下降明显，说明原有优化确实在起作用
