OSR是JVM JIT自动触发的运行时优化机制，通过监控循环回边计数（默认阈值约1400次）识别热点循环并编译，不依赖方法调用次数，开发者无法手动启用但可通过规范循环结构促进其触发。
栈上替换（On-Stack Replacement，OSR）不是由开发者手动“启用”或“调用”的功能，而是 JVM JIT 编译器在运行时自动触发的优化机制。它专为解决“方法调用次数少、但内部循环执行极多”的场景而设计——比如 main 中一个迭代百万次的 for 循环。你无法写代码“启动 OSR”，但可以通过合理配置和代码结构，让 JVM 更快识别并完成替换。
理解 OSR 触发的核心条件
OSR 不看方法被调用了几次，而是紧盯“回边计数”（backedge count）：即循环体末尾跳回头部的次数。当该计数超过阈值（HotSpot 默认约 1400 次），JVM 就判定这个循环是热点，并准备 OSR 编译。
- 循环必须可被准确计数：避免使用
while(true)或依赖外部中断的循环，优先用for(int i = 0; i 这类结构清晰、边界明确的循环 - 循环体不宜过小：空循环或仅含简单赋值的循环可能被逃逸分析或死代码消除掉，反而绕过 OSR；加入适度计算（如累加、位运算）有助于稳定触发
- 避免频繁分支或异常打断：OSR 需要维持栈帧上下文一致性，频繁抛异常、
break/continue跳转过深，会增加替换难度
通过 JVM 参数引导 OSR 行为
你可以用参数调整 OSR 的灵敏度与可见性，但不能强制它“立即发生”：
- -XX:CompileThreshold=1000：降低方法级编译阈值（虽不直接控制 OSR，但影响整体 JIT 调度节奏）
- -XX:OnStackReplacePercentage=140：设为方法调用计数阈值的百分比，用于计算 OSR 触发点（默认 140，即回边计数达方法阈值 × 1.4）
-
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining：观察日志中是否出现
osr标记，例如123 45 3 java.lang.Math::max (5 bytes) osr，说明 OSR 已成功应用 - -XX:ReservedCodeCacheSize=256m：确保代码缓存足够，避免因空间不足导致 OSR 编译被丢弃
验证 OSR 是否生效的实用方式
光看日志还不够，需结合性能表现交叉判断：
- 用 JMH 写微基准测试，对比开启/关闭 JIT（
-Xint）时同一循环的耗时差异。若差异显著（如 3 倍以上），且日志中出现osr记录，基本可确认 OSR 起效 - 用 jstack 或 Async-Profiler 抓取运行中线程栈，若看到循环方法名后标注
[Compiled method]或对应机器码地址，说明当前正执行 OSR 后的版本 - 注意冷启动延迟：首次执行大循环时，前几千次仍走解释器，之后才切换——这是正常现象，不代表失败
常见误区与规避建议
很多尝试“手动升级循环”的做法实际干扰了 OSR：
- 不要在循环内插入
System.gc()或Thread.yield()：这会打乱计数节奏，甚至让 JVM 误判为非热点 - 不要用反射、动态代理包裹循环逻辑：JIT 对这类间接调用优化受限，OSR 可能降级或失效
- 避免把超大循环拆成多个小方法再互相调用：这会把热点分散，导致每个方法都达不到阈值，反而错过 OSR
- 不用刻意“预热”：现代 HotSpot 会自动积累统计信息；连续执行 2–3 轮循环通常就足以触发 OSR
