抽象类不直接导致性能问题，但设计不当会因多层虚方法分派、阻碍JIT内联、抽象调用链等降低执行效率；应精简继承层级、用组合替代深层继承、优先使用final方法和具体实现、避免抽象方法内同步与装箱。
抽象类本身不直接导致性能问题，但设计不当会引入额外的方法调用开销，尤其在高频调用路径（如循环体、实时计算、网络协议编解码）中，多层抽象方法跳转可能影响JIT内联效果和执行效率。关键不是“去掉抽象类”，而是让抽象类的调用链更扁平、更可控。
精简继承层级，避免“接口→抽象类→抽象类→实现类”嵌套
每多一层抽象父类，就多一次虚方法分派（virtual dispatch），JVM需在运行时查虚方法表。深度继承链还可能阻碍JIT将方法内联——一旦内联失败，就会保留方法调用指令，增加栈帧切换开销。
- 把两层抽象合并为一层：例如将
AbstractVehicle → AbstractCar → Sedan改为AbstractCar直接定义通用行为（如startEngine()、brake()），子类只负责差异化逻辑 - 用组合替代深层继承：把可复用的行为封装成工具类或策略对象，通过字段持有而非继承获取能力，调用变为直接引用+方法调用，更易被JIT优化
- 若必须多层，确保上层抽象类中90%以上方法是
final或具体实现，减少虚方法数量
优先使用具体方法，延迟抽象化
抽象类里混用具体方法和抽象方法是合理设计，但性能敏感路径应尽量走具体方法分支。提前提供默认实现，避免子类被迫重写简单逻辑（比如空校验、基础状态转换）。
- 把“模板方法模式”中的钩子方法设为
protected且带空实现，而非强制抽象；子类仅在需要时才覆盖 - 对高频调用的方法（如
calculateScore()、isValid()），优先在抽象类中给出高效默认实现（如位运算、数组查表），子类用@Override仅当确实需要不同语义 - 避免在抽象方法内部再调用另一个抽象方法，形成“抽象调用链”，这会显著增加分派深度
用 final 修饰可确定不变的行为
JVM对 final 方法能更激进地内联，尤其是被频繁调用的小方法。抽象类中那些逻辑稳定、子类从不重写的公共方法，应显式声明为 final。
立即学习“Java免费学习笔记（深入）”；
- 例如：
public final String getFullId() { return prefix + "-" + id; }，比非final版本更容易被JIT识别为热点并内联 - 构造函数中初始化的
final字段，也能帮助JIT做逃逸分析和标量替换，间接减少方法调用时的对象传递开销 - 注意：不要为“未来可能扩展”而预留非final方法，先写死，等真有需求再重构——性能优先场景下，可维护性让位于确定性
配合JIT友好写法：避免“抽象方法+同步块+装箱”组合
某些看似无害的写法，在抽象方法上下文中会放大开销。例如在抽象方法里做 synchronized、或返回 Integer 而非 int，会导致JIT放弃内联或触发额外GC。
- 把同步逻辑提到调用方，或改用
java.util.concurrent中的无锁结构，避免抽象方法体内加锁 - 高频方法签名尽量用基本类型（
int,long,boolean），避免包装类作为参数或返回值 - 抽象方法参数尽量少而明确，避免传入泛型集合或复杂DTO；必要时用
record或紧凑的struct-like类替代
