引用类型调用方法有额外开销，核心在于运行时需动态查虚函数表或接口方法表、无法内联、需维护元数据及受gc影响。
引用类型调用方法之所以有额外开销，核心在于运行时需要动态确定具体执行哪个实现，而不是在编译期就绑定好目标函数地址。这种机制带来多层间接性，直接影响执行效率。
间接寻址：多一次内存跳转
引用类型（如接口、父类引用）调用方法时，JVM 或 C++ 运行时不能直接跳转到函数地址，而必须先查虚函数表（vtable）或方法表（vtable / itable），再通过表中指针定位实际方法。这个“查表→取指针→跳转”过程比直接调用多 1–2 次内存访问，在现代 CPU 上容易引发缓存未命中和分支预测失败。
- Java 中接口方法调用（invokeinterface）比普通 invokevirtual 多一层接口方法表（itable）查找
- C++ 中每个含虚函数的对象额外携带一个 vptr（通常 8 字节），指向其类的 vtable
- 哪怕只是读取 vptr 和查表，也打断了指令流水线的连续性
无法内联：编译器优化受限
内联是编译器提升性能的关键手段——把小函数代码直接展开，省去调用开销。但引用类型调用的目标在运行时才确定，编译器无法确认最终调用哪个实现，因此绝大多数情况下放弃内联。
- final 方法、private 方法、static 方法可被内联；而被 override 的虚方法基本不可内联
- 即使 JIT 编译器后期做“去虚拟化”（devirtualization），也需要足够运行时 profile 支持，且仅对热点路径有效
- 泛型擦除后的桥接方法、反射调用、Lambda 生成的合成类方法，同样绕过静态绑定
运行时类型检查与表维护成本
为支持多态，系统需在对象创建、继承关系变更、类加载等阶段维护元信息结构，这些隐式开销常被忽略：
- C++ 中每个含虚函数的类生成一份 vtable，多重继承时可能多个 vptr，对象尺寸增大
- Java 的方法区（元空间）要存储类结构、方法签名、分发表，类越多、越复杂，元数据压力越大
- 某些场景下（如频繁创建/销毁对象），vtable 初始化、类加载验证也会拖慢启动或响应速度
垃圾回收与内存布局间接影响
引用类型本身驻留在堆上，其生命周期由 GC 管理。这虽不直接属于“调用开销”，但会放大整体性能负担：
- 堆对象分配比栈分配慢（涉及同步、TLAB 分配等）
- GC 停顿期间所有线程暂停，而大量引用类型对象会延长标记/清理阶段耗时
- 对象分散在堆中，方法调用伴随的数据访问局部性差，进一步削弱 CPU 缓存效率
