for-each中的Iterator无法标量替换，因其必须传给虚调用的hasNext()/next()、含强引用字段（如ArrayList.this）、字段被状态机逻辑耦合，不满足不逃逸、全标量、独立使用三条件。
不能通过调整 JVM 参数让 for-each 中的临时迭代器对象真正“在栈上分配”，因为 HotSpot JVM（JDK 8–21）根本不支持对 Iterator 类型做栈上分配；你观察到的优化效果，实际来自标量替换 + 方法内联的组合，而 Iterator 几乎无法满足标量替换的前提条件。
为什么 for-each 的 Iterator 无法被标量替换
标量替换要求对象：不逃逸、字段全为标量、且所有字段被独立使用。Iterator（如 ArrayList$Itr）天然违反这三条：
- 它必须作为参数传给 hasNext() 和 next() —— 这两个是虚方法调用，JIT 默认视为“可能逃逸”，即使最终内联成功，逃逸分析日志也常显示 escapes method
- 它包含引用类型字段（如 ArrayList.this、cursor、lastRet、expectedModCount），其中 this 是外部对象强引用，直接阻断标量替换
- 它的字段不是被“独立读写”，而是被封装在状态机逻辑中（比如 cursor 变更伴随 modCount 校验），JIT 无法安全拆解并寄存器化
实测验证：Iterator 永远不会被标量替换
加参数启动并观察关键日志：
- -XX:+DoEscapeAnalysis -XX:+PrintEscapeAnalysis → 日志中只会出现 ArrayList$Itr escapes method，绝无 scalar replaceable
- -Xlog:gc+allocation=debug → 循环执行 10 万次，仍可见稳定堆分配（如 allocated=24B per iteration）
- -XX:+PrintOptoAssembly（配合 hsdis）→ 汇编中清晰存在 newinstance、store oop 等指令，说明对象真实创建于堆
真正有效的替代方案
与其强行优化 Iterator，不如绕过它：
- 对数组用普通 for：编译后就是纯索引访问，零对象、零方法调用，性能最优
- 对 ArrayList 用传统 for + get(i)：避免 iterator() 创建，且 get(i) 是 final 方法，易内联；只要 list 不为空，JIT 通常能消除边界检查
- 用原始类型集合库（如 Eclipse Collections 或 Trove）：避免泛型装箱 + Iterator 对象，直接操作 int[]/long[] 等原生数组
- Java 16+ 可考虑 SequencedCollection + for (var e : list)：虽语法不变，但未来 JIT 可能针对新接口做更激进的逃逸判定（当前尚未落地）
哪些对象才真的适合标量替换
如果你的目标是减少堆分配，应聚焦在真正符合标量替换条件的轻量数据结构上：
- record Point(int x, int y) 或 class Vec2d { final double x,y; }
- 仅含基本类型字段（无任何 Object、String、List 引用）
- 只在方法内构造、计算、返回字段值（如 return p.x + p.y），不赋值给变量、不传参、不调用任何实例方法
- 配合 -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 确认关键方法已被内联
