不幸的是，进行这种分析需要耗费大量时间。所以在实际过程中，确定一个调用点是否单态是个不太可取的方法。对此，JIT编译器倾向于使用一种替代方法：列出哪些类可以在此调用点被调用，接着根据之前的N个相同的调用猜测此调用点是否是单态的。以假定某个调用点永远为单态，来进行投机性质的优化往往是可取的行为。因为这样的优化往往都是正确的，但也因它无法确保永远正确，编译器需要在方法调用之前注入一个用于检查方法类型的防护机制。
除了单态的调用点以外，还有两种调用点我们希望对其进行优化。一种称为双态（bimorphic）调用点，在该点上有两个候选方法。对此你依然可以实现内联——借助防护代码，让其检测应调用哪一个方法，并引导程序跳转至内联在调用点的两个方法体中真正对应的那一个。这样的方式还是比查看所有虚拟表的方式要快得多。但在某些情况下，我们得利用内联缓存来进行优化。内联缓存需要借助一张特定的跳转表（ jump table），这种表类似于对虚拟表查找做的一份缓存。hotsopt JIT编译器支持双态内联缓存，并定义那些拥有三个及三个以上候选方法的调用点为超多状态（megamorphic）调用点。
这就使得我在基准测试与探究当中，需要额外地把调用情况划分为三类：单态、双态、超多状态。
结果让我们把结果分类组织，以便研究细节。我已经提供了统计产生的原始数据。但我们的兴趣点不应放在性能测试结果的具体数值上，而应是不同类型的方法调用的性能开销之间的比率以及各自的错误率是否够低。如果最快与最慢的结果之间比率为6.26，则说明这是一个显著性差异。由于测试时使用的是空方法（详见源代码），所以在实际应用中，这样的差异会更大。
你可以在 github上查看此次基准测试的源代码。为了避免产生困惑，待会所有的结果将分块显示。最后显示的多态的基准测试是在 PolymorphicBenchmark 类中进行，其它的则在 JavaFinalBenchmark 类中。
简单调用点最先看到的的一组结果，是比较调用一个 virtual 方法、一个 final 方法和一个拥有很深的层级结构，同时被所有子类重写的方法所带来的开销。注意，调用这些方法的时候我们都强制编译器不要内联它们。我们可以看到：三者在时间花费上相差甚微，并且各自的误差率都小到可以忽略。对此我们可以断定，仅添加一个 final 关键字并不会大幅度提升调用性能，重写一个方法也不见得会带来什么影响。
内联简单调用现在，我���在开启内联的情况下再来一次相同的测试。由结果可见，final 方法和 virtual 方法的时间花费依旧相近，并比在没有内联的情况下快了4倍，我将此归功于内联优化。相比而言，被所有子类重写的方法的结果可就没那么好看了。我推测这是由于此方法有多个子类实现，使得编译器必须插入一个类型保护。有关的细节我们将在研究多态性的结果时进行阐述。
类层次结构的影响
哇噢——这儿有好几个的方法！方法名称的编号（1~4）代表该方法调用的层次。因此，parentMethod4 表示我们调用的方法位于class的上面第四级。（译注：在源代码中该方法位于顶层的父类）。由此结果我们能断定，结构层次的深度对性能开销没有影响。在开启内联的实例中，结论也是一样。这个测试中，被内联的方法的性能与 inlinableAlwaysOverriddenMethod 相当，但稍逊于 inlinableVirtualInvoke。我依旧认为这与使用了类型保护有关。事实上JIT编译器能剖析所有候选方法，从而只内联对应的那一个，但这并不证明它总会这么干。
类的层级结构对final方法的影响