多态引发内联缓存溢出？探讨替代继承的关联对象方案

关于内联缓存的理解 #

你的理解基本正确：常规内联缓存不会主动遍历隐藏类的继承树——这么做会大幅提升检查成本，得不偿失。虽然基类的属性x在所有子类实例中的内存偏移量是一致的，但当函数f被大量不同子类的实例调用时，内联缓存会因为匹配到多个不同的隐藏类，从单态降级为多态甚至超态，此时属性访问会退化为慢路径（比如遍历原型链或字典查找），也就是你说的“缓存溢出”。

不过现代JS引擎（比如V8）针对这种场景做了针对性优化：

• 原型内联缓存（Prototype IC）：如果访问的是原型链上层的属性，引擎会记录该属性在原型上的偏移量，而非仅匹配当前对象的隐藏类。只要子类没有重写该属性，哪怕传入不同子类实例，缓存依然能命中，不会溢出。
• 类型反馈优化：TypeScript的类型标注能帮助引擎更好地推断类型，减少缓存的多态性，变相提升命中效率。

关联对象方案 vs 子类继承的性能对比 #

你提出的关联对象方案确实能让函数f始终命中单态内联缓存——所有传入的A<T>实例的隐藏类完全一致（TypeScript的类型参数不影响JS层面的隐藏类，A类只有x和extension两个属性）。但这个方案的实际性能影响得从多维度权衡：

优势 #

• 稳定的单态缓存：p.x的访问始终走最快的单态路径，不会随着子类数量增加而退化。
• 避免隐藏类碎片化：子类越多，继承链上的隐藏类变体就越多；而关联对象模式下A类的隐藏类唯一，不会产生碎片化问题。

劣势 #

• 额外内存开销：每个子类实例都要额外创建一个A实例，既增加了内存占用，也提升了垃圾回收的压力。
• 属性访问的间接性：如果要从子类实例访问x，必须走b1.a.x，多了一层属性查找；反过来从A实例访问子类属性也要通过extension.y，这会新增一次缓存查找（单态场景下开销很小，但多态时依然会有影响）。
• 代码复杂度上升：关联对象需要维护双向引用，写法比继承啰嗦得多，可读性和可维护性都会下降。

实际场景中的选择 #

除非你已经通过性能测试确认两个前提：

1. 函数f是核心性能热点，且被大量不同子类实例频繁调用；
2. 引擎的原型内联缓存优化没有生效（比如子类重写了基类属性，或者引擎无法识别继承关系）。

否则优先用子类继承——现代JS引擎对继承的优化已经非常成熟，原型内联缓存能覆盖绝大多数场景，关联对象的额外开销和代码复杂度往往得不偿失。

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