Java是否会在调用点多数代码为死码时内联大型方法？

答案是会的，而且这正是HotSpot JIT编译器（尤其是服务器端的C2编译器）聪明的地方——它不会只盯着方法的原始字节码大小做内联决策，而是会结合调用点的上下文和死码消除（Dead Code Elimination, DCE）来动态判断。

为什么原始大小不是唯一标准？ #

HotSpot的内联逻辑本质是在代码膨胀风险和调用开销节省+后续优化空间之间做权衡。如果一个方法看起来很大，但在某个特定调用点，大部分代码都是死码（比如分支永远不会走、变量从未被使用等），那内联后的实际代码量可能远小于原方法，甚至比一些小方法还小，这种情况下内联的收益会非常可观。

JIT具体是怎么做的？ #

• 先分析再决策：C2会先对调用点的上下文做初步分析，比如检查传入的参数是不是常量、有没有分支可以直接折叠。举个例子：如果你的方法里有1000行代码，但调用时传入的参数让其中90%的if分支都不会执行，JIT会先识别这些死码，再评估内联后的实际代码膨胀情况，而不是直接被原始大小劝退。
• 先内联再清理：有时候JIT会先大胆内联大型方法，再在后续的优化阶段把死码彻底砍掉。比如一个方法包含多种业务逻辑分支，但某个调用点只触发其中一种，内联后JIT会把其他分支全部删除，最终得到的代码可能比原方法小很多，完全不会有膨胀问题。
• 灵活的阈值调整：HotSpot有默认的内联大小阈值（比如-XX:MaxInlineSize默认是35字节码），但这不是硬限制。如果JIT发现内联后能通过DCE大幅缩减代码，会主动突破这个阈值。另外针对高频调用的方法，还有-XX:FreqInlineSize（默认热点方法阈值更高），因为高频调用的内联收益更大，哪怕原始方法大，只要死码占比高，就值得做。

例外情况 #

当然也有边界情况：比如极端庞大的方法（比如上万行字节码），即使有大量死码，JIT可能还是会犹豫——因为分析这么大的方法本身就会消耗不少编译资源，得不偿失。另外客户端编译器C1的策略更保守，更依赖原始方法大小，这种智能判断主要是C2的强项。

内容的提问来源于stack exchange，提问作者Mark VY