内联优化由函数调用点触发，取决于函数大小、调用可确定性、副作用可控性及优化等级；临界点是编译器基于指令规模、调用热度与收益预估的多维权衡结果，递归、取地址、变长参数等构成硬性边界。
编译器对跳转指令执行极致内联优化，并不取决于程序计数器（PC）本身，而是由函数调用行为触发、受控于编译器对“是否值得内联”的综合判断。PC只是被动反映结果——内联后，原本的call指令消失，PC不再跳转到函数入口，而是自然流向下一条被展开的指令。
内联发生的本质条件
内联不是针对“跳转指令”做优化，而是针对“函数调用点”。只要该调用满足以下条件，编译器就可能将其替换为内联代码，从而消除跳转：
- 函数体足够小（如单条赋值、简单比较、短循环），开销远小于一次
call+ret的寄存器保存/恢复+PC修改成本 - 调用上下文可静态确定（无虚函数、无函数指针间接调用、非递归入口）
- 编译器能确认副作用可控（例如无全局状态依赖、参数无别名冲突）
- 优化等级开启（如 GCC 的
-O2或 Clang 的-Oz），且未显式禁用（如加__attribute__((noinline))）
临界点不是固定值，而是多维权衡
所谓“临界点”，其实是编译器内部启发式模型的输出结果，主要参考三类动态指标：
- 指令规模阈值：HotSpot JIT 默认对字节码 ≤ 35 行的方法尝试内联；GCC 对 IR 中基本块数 ≤ 10、总指令数 ≤ 50 的函数倾向内联
- 调用热度信号：JIT 通过方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）识别热点；解释执行阶段累计调用超 1500 次（C1 默认阈值），即触发首次内联编译
- 收益预估权重：编译器会估算内联后节省的跳转开销 vs 增加的代码体积（影响指令缓存命中率）。当函数被频繁调用但体积略大时，仍可能内联；反之，若仅调用一次却体积极大，则大概率放弃
如何验证是否达到内联临界点
不能只看源码或汇编跳转是否存在，要结合工具链观察实际生成结果：
- GCC/Clang 加
-fopt-info-vec-optimized或-fopt-info-inline，编译时输出内联决策日志 - 在 GDB 中对函数下断点，若断点无法命中（或显示
<inlined></inlined>），说明已被内联 - 用
objdump -d查看目标文件，确认调用点是否还存在call指令；若已展开为连续算术/访存指令，即表明越过临界点 - JVM 可加
-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions，运行时打印每处内联是否成功及原因（如too big、hot method too big）
真正卡住内联的硬性边界
以下情况会直接导致编译器放弃内联，构成事实上的“不可逾越临界点”：
- 函数含递归调用（除非启用特定递归内联扩展，如 GCC 的
-frecursive-inline，但极少见） - 函数地址被取址（
&func）、作为参数传给函数指针或虚表，编译器必须保留可寻址入口 - 函数含变长参数（
...）、内联汇编（asm volatile）或异常处理块（try/catch），破坏控制流可分析性 - 跨编译单元调用且无 LTO（Link-Time Optimization），缺少函数体定义，无法展开
