关于JVM secondary_super_cache的instanceof/checkcast性能问题的技术问询

问题背景 #

近期不少技术文章和社区讨论都在关注JDK里一个特殊的性能问题：当遍历包含多种类型对象的集合时，会出现明显的性能损耗，而同构集合（所有元素类型一致）则没有这个问题。相关测试用例专门复现了这一现象，核心指向checkcast指令的并发竞争开销。

测试的运行逻辑 #

这类测试的核心思路很直接：

• 分别构造两个集合：一个全是同一类型的对象（同构集合），另一个混合了多个子类/实现类的对象（异构集合）
• 多线程遍历这两个集合，每次遍历都对元素执行强制类型转换操作
• 对比两种场景下的执行耗时，观察性能差异

同构集合为何没有性能损耗？ #

当集合里所有元素类型完全一致时，JVM的即时编译器（JIT）会做针对性优化：

• JIT会快速识别出集合的类型单一性，在第一次成功执行checkcast后，直接把后续所有的类型检查操作完全消除——相当于跳过了checkcast指令，直接访问元素。
• 这种优化下，遍历过程几乎没有额外开销，性能和直接访问元素没差别，自然不会有性能损耗。

异构集合的性能损耗从何而来？ #

而异构集合的情况就完全不同，核心问题出在类型污染引发的checkcast并发竞争：

1. 因为集合里有多种类型的对象，JIT无法预判下一个元素是否符合转换要求，所以必须每次都执行完整的checkcast指令，没法做优化。
2. checkcast指令执行时需要访问JVM内部的共享类型元数据（比如类的继承关系、接口实现信息）。当多个线程同时执行checkcast时，会触发伪共享（false sharing）——不同线程的操作会频繁读写同一块CPU缓存行，导致缓存不断失效，不得不反复从主内存加载数据，这会大幅拖慢执行速度。
3. 另外，异构场景下JIT也没法做方法内联等进一步优化，雪上加霜，最终导致性能差距被放大。

问题本质 #

这个问题的本质是JVM在处理异构类型的强制转换时，checkcast的实现存在并发访问瓶颈。当集合被多种类型“污染”后，JVM无法进行有效的类型推断和优化，大量线程同时执行类型检查时，共享元数据的竞争就会引发显著的性能损耗——这就是所谓的“类型污染”性能问题。

内容的提问来源于stack exchange，提问作者Steven Dallas