Java无显式方法内联缓存，HotSpot通过类型推测与单态/多态内联实现类似优化：单态时硬编码方法入口，多态时生成类型检查分支，超态则回退虚表查找。
Java 中没有传统意义上的“方法内联缓存（Inline Cache）”这个概念，它其实是 动态语言（如 Ruby、Smalltalk、JavaScript）中用于加速虚方法/动态分派的运行时优化机制。JVM 本身不公开暴露或让用户直接操作“Inline Cache”，但 HotSpot 虚拟机在底层确实实现了类似思想的优化——主要是通过 类型推测（type profiling）和单态/多态内联（monomorphic/polymorphic inlining） 来提升虚方法调用性能。
为什么 Java 没有显式的 Inline Cache？
Java 是静态类型语言，方法调用绑定在编译期就已确定大部分路径：
- private / static / final 方法 → 直接内联（无需查虚表）
- 普通实例方法 → 编译为 invokevirtual 字节码，运行时需查虚方法表（vtable）或接口方法表（itable）
- 但 JVM 不像 Ruby 那样每次调用都“缓存上次调用的目标类+方法地址”，而是依赖 运行时类型信息（profiling data） 做更激进的推测性优化
HotSpot 实际怎么“模拟” Inline Cache 的效果？
HotSpot 在解释执行阶段会收集方法调用点（call site）的接收者类型统计，这就是它的“隐式 inline cache”：
- 单态（Monomorphic）：99%+ 调用都是同一类（如总是 String），JIT 就直接硬编码该类的方法入口，跳过虚表查找
- 多态（Polymorphic）：常见 2~4 个类（如 ArrayList / LinkedList / Vector），生成带类型检查的快速分支（type check + jump）
- 超态（Megamorphic）：类型过多（>4），退化为标准虚表查找，不再尝试内联
这些行为可通过 -XX:+PrintCompilation -XX:+TraceClassLoading 观察，也可用 JMH + perfasm 看汇编中是否出现 cmp + je 类型判断跳转。
立即学习“Java免费学习笔记（深入）”；
如何影响 JVM 的“内联缓存”行为？
你不能手动设置 inline cache，但可以引导 JVM 做出更好推测：
- 避免在热点路径上频繁切换实现类（比如 List 接口变量反复赋值为不同子类）
- 对稳定类型使用 final 类或 sealed 类，减少可能的子类数量
- 启用分层编译（默认开启）和 profile-based optimization：-XX:+UseTypeSpeculation
- 必要时用 @HotSpotIntrinsicCandidate 或 @ForceInline（JDK17+）提示内联，但仅限于 JIT 认为安全的场景
和真正 Inline Cache（如 Ruby 的 IC）的关键区别
Java 的优化是“一次推测、长期生效”，而 Ruby 的 inline cache 是每个 call site 维护一个可变缓存槽（cache slot），支持快速失效与更新：
- Ruby：每次调用先比对缓存中的 klass，命中则跳转；不命中则更新缓存并慢路径查找
- HotSpot：解释器记录类型频次 → C1/C2 编译时生成定制代码 → 若后续加载新类导致类型假设失效，则去优化（deoptimization）并重新编译
- 所以 Java 更重“编译决策”，Ruby 更重“解释执行时的缓存管理”
基本上就这些。理解这点能帮你更合理地写高性能 Java 代码——不是靠“手写缓存”，而是让 JVM 的推测更稳、更准。
