Lambda表达式本身不直接内联，JIT只对生成的私有静态方法（如lambda$xxx）按热点、大小、可推测性等条件内联；但因常通过接口引用间接调用，易受虚方法分派、多实现混用、容器包装及动态代理等因素阻碍。
函数式接口的Lambda表达式与内联关系不直接
Java中函数式接口本身不是方法，它只是一个带单抽象方法的接口类型。真正参与JIT内联的是其实现体——尤其是通过Lambda生成的私有静态方法（如lambda$xxx）或内部类中的方法。JIT不会因为“用了函数式接口”就特殊优待，它只看最终调用目标是否满足内联条件：是否热点、是否小、是否可稳定推测。
Lambda生成的方法天然具备高内联潜力
编译器将简洁Lambda（如a -> a.length()）编译为private static合成方法，这类方法：
- 字节码极短（常仅3–5条指令），远低于
-XX:MaxInlineSize=35默认阈值 - 是static方法，无多态风险，无需类层次分析（CHA）
- 若被高频调用（如Stream.forEach中反复执行），很快成为热点，触发C2编译和内联
但实际内联常被间接调用链阻断
问题不出在Lambda本身，而出在它被调用的方式上：
-
通过Function等接口引用调用：如
func.apply(x)是虚方法调用，JIT需确认是否单态。若运行时只绑定一个实现（如始终是同一个lambda实例），Profile数据积累后可能内联；但若存在多个lambda或方法引用混用，就会标记not inlineable (virtual) - 被包装在Stream/Optional等容器中：中间操作（如map、filter）本身是泛型+接口回调，调用链深、类型擦除、且常含分支逻辑，导致内联深度受限或被异常结构干扰
- 捕获外部变量过多：虽不直接影响字节码大小，但可能使合成方法包含对象字段访问、null检查等，略微增加控制流复杂度，影响C2对内联收益的评估
对比传统private方法更难稳定内联
一个显式写的private static int compute(int x)，只要短小、热，几乎必内联；而Lambda对应的合成方法虽也private static，但它的调用点总绕不过一层接口方法分派。这意味着：
立即学习“Java免费学习笔记（深入）”；
- 必须等JIT完成足够采样，确认该invokeinterface调用点99%命中同一目标
- 若应用启动初期就有大量不同lambda实例，Profile数据混乱，内联会延迟甚至失败
- Spring AOP、动态代理等框架可能将lambda包装成代理对象，彻底转为不可推测的虚调用
