密封类能显著提升虚方法内联成功率，核心在于它消除了编译器对“方法可能被重写”的不确定性，明确切断继承链使编译器100%确认虚方法不可覆写，从而支持jit直接生成内联或静态调用指令。
密封类能显著提升虚方法内联成功率，核心在于它消除了编译器对“方法可能被重写”的不确定性。
明确切断继承链，让编译器100%确认虚方法不可覆写
当一个类被声明为 sealed（Java）或 @Closed（鸿蒙 ArkCompiler），或标记为 sealed class（C#），编译器就获得一条硬性保证：该类型不可能有子类，其所有虚方法（包括 override、virtual、abstract 实现）在运行时必然不会被动态分派替换。
- Java/C# 中，对 sealed 类实例调用虚方法时，JIT 可跳过 vtable 查找，直接生成内联或静态调用指令
- 鸿蒙 ArkCompiler 将未加 @Closed 的方法默认视为“潜在虚方法”，即使逻辑极简也倾向拒绝内联；加上后，内联率可从 75% 飙升至 98%+
- 关键不是“密封本身快”，而是它提供了编译器做激进优化所需的确定性——没有多态歧义，就没有保守退让
配合模式匹配，把运行时类型判断转为编译期穷尽分支
密封类天然适配 switch 表达式（Java 17+）或模式匹配（C# 12+），让原本依赖 instanceof + 强制转换的多态分发，变成紧凑的 tableswitch 字节码。
- JVM 在 C2 编译阶段会对 exhaustive switch 执行常量折叠和死代码消除，删掉不可能执行的 case 分支
- 相比 Visitor 模式双分派或 if-else 链，避免了多次虚方法调用和类型检查开销，压测显示性能提升可达 47%
- 例如：switch (shape) { case Circle c -> c.area(); case Rectangle r -> r.area(); } 编译后近乎等效于直接调用，无虚调用开销
避免“伪虚方法”干扰内联决策
很多工具类方法看似简单（如 return "key_" + id），但若未密封，编译器仍需保留重写可能性，不敢内联。这类方法往往高频调用，小延迟累积成大瓶颈。
- 将仅作内部使用的工具类、DTO 包装器、状态枚举替代类声明为 sealed / final / @Closed，可立即释放内联潜力
- 注意：仅当该类确实被用于虚方法调用路径时才有效（如实现接口、继承抽象类并被多态引用）；纯静态工具类加 sealed 无收益
- 搭配 JIT 日志（如 -XX:+PrintInlining）验证内联结果，而非凭经验猜测
与记录类协同构建高内聚数据模型
密封接口 + 记录类实现是现代 Java 高效建模的黄金组合：前者定义封闭变体集合，后者提供不可变、轻量、自动生成的标准行为。
- record 自带的 toString()、equals()、hashCode() 默认是非虚的，但若被密封接口引用（如 Shape s = new Circle(1.0)），调用 s.toString() 仍走虚分派；此时密封性确保该调用目标唯一，利于 JIT 内联
- 所有合法实例类型已知且有限，编译器可在字节码验证阶段裁剪无效分支，在运行时减少类型检查压力
- 比传统 enum 更灵活（支持携带行为），又比开放继承更安全可控，天然契合高性能领域建模需求
