Java内联警告指JIT编译日志中出现的“too big”“too complex”等提示，表明因方法体过大或过复杂（如多嵌套、大量try-catch），JIT放弃将其内联进调用方，受MaxInlineSize（默认35）和FreqInlineSize（默认100）阈值控制。
Java内联警告实际指什么
这不是编译器警告，也不是JVM启动时打印的WARNING日志——它通常出现在JIT编译日志（如-XX:+PrintCompilation或-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining）里，表现为类似too big、hot method too big或inline failed: too large的提示。核心意思是：JIT编译器在尝试把某个被频繁调用的方法“展开”进调用方时，因方法体过大而放弃内联。
哪些方法会被JIT判定为“太长”
JIT对“长度”的判断不只看行数，而是综合字节码指令数、控制流复杂度、异常表大小等因素。默认阈值由MaxInlineSize（非热点方法，缺省35）和FreqInlineSize（热点方法，缺省100）控制；但即使没超阈值，含大量if/switch嵌套、多个try-catch块、或大量常量字符串拼接的方法，也容易触发too complex类拒绝。
-
MaxInlineSize影响所有方法，可通过-XX:MaxInlineSize=45微调，但盲目调大可能增加代码缓存压力 -
FreqInlineSize只对已进入C2编译队列的热点方法生效，调大需配合-XX:CompileThreshold观察效果 - 含
synchronized块的方法内联开销更高，JIT更倾向跳过；若必须同步，优先考虑ReentrantLock或无锁结构
怎么确认某个方法是否真的没被内联
光看日志不够，得验证实际行为。开启-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions后，搜索目标方法名，重点看末尾状态：
- 出现
inline (hot)或inline (cold)→ 成功内联 - 出现
too big、too complex、too many bytecodes→ 明确被拒 - 出现
not inlineable→ 可能含invokedynamic、JNI调用或反射，这类方法根本不可内联
注意：-XX:+PrintInlining输出极多，建议配合grep过滤，例如：java -XX:+PrintInlining MyApp 2>&1 | grep "MyUtils\.parse"
立即学习“Java免费学习笔记（深入）”；
内联失败的真实代价是什么
不是“变慢一点”，而是可能引发级联性能塌方：一个未被内联的热点方法，每次调用都要走完整的栈帧分配、参数压栈、返回地址保存流程；若该方法本身又频繁调用其他小方法（比如String::length()、Objects::nonNull()），这些调用也无法被进一步内联，最终生成大量冗余字节码执行路径。
- 典型症状：CPU火焰图中出现异常高占比的
Interpreter帧，或C2 CompilerThread持续高负载 - 对比测试时，禁用内联（
-XX:-UseInline）比仅调整阈值更能暴露问题边界 - 现代JDK（17+）对
record构造器、sealed类的switch匹配有专门优化，但前提是方法体足够“干净”——空行、冗余注释、未使用的局部变量都会计入复杂度
真正难处理的是那些逻辑必须集中、又无法拆分的校验方法——这时候与其硬调FreqInlineSize，不如用@HotSpotIntrinsicCandidate标记关键路径，或提前用javac -parameters保留参数名辅助JIT分析。
