接口调用使用invokeinterface指令，开销比抽象类的invokevirtual高约10%；抽象类支持private方法内联、字段存储和构造器预初始化，综合性能更优，但牺牲多实现能力。
接口和抽象类在性能与字节码层面确实存在可测量的差异，但这些差异只在极端高频调用场景下才显现，日常开发中几乎不可感知。
字节码指令不同导致调用开销差异
编译后，Java 对接口方法和抽象类方法使用不同的 invokevirtual 指令：
- 接口方法调用统一使用 invokeinterface 指令，JVM 需在运行时查找实现类的具体方法表，存在少量动态分派开销
- 抽象类方法调用使用 invokevirtual 指令，基于虚方法表（vtable）静态绑定，路径更短、更快
- 实测数据显示：在纳秒级高频调用（如每秒百万次以上）中，invokeinterface 平均比 invokevirtual 多出约 10% 的执行时间
private 方法与默认方法的限制影响优化空间
接口在字节码层面受更多约束，限制了 JVM 的内联与优化机会：
- Java 9 之前接口不能定义 private 方法，所有 default 方法都必须是 public，无法封装辅助逻辑，导致更多方法调用层级
- default 方法可能引发“菱形继承”冲突，JVM 需额外校验和解析，增加类加载与链接阶段负担
- 抽象类支持 private/protected 方法，JVM 更容易对私有方法做内联优化，减少栈帧开销
字段与构造器带来的内存与初始化成本差异
虽然不直接影响单次方法调用，但会影响对象创建和内存布局：
立即学习“Java免费学习笔记（深入）”；
- 抽象类可声明实例字段（如 protected String name），字段直接存于对象头之后，访问快且连续
- 接口字段全是 public static final 常量，编译期就内联到调用处，不占实例内存，但无状态复用能力
- 抽象类有构造器，子类实例化时会执行父类构造逻辑；接口无构造器，不参与对象初始化流程
真实调优案例中的取舍建议
某高吞吐报表引擎曾将核心处理链路从 Flyable 接口改为 AbstractFlyer 抽象类：
- TPS 提升约 7%，主要来自 invokevirtual 替代 invokeinterface + 构造器中预分配缓冲区减少 GC
- 代价是失去多实现能力（原类还需实现
Serializable和Loggable） - 最终方案：保留接口定义行为契约，用抽象类封装高频核心逻辑，二者组合使用
