我理解 sealed 接口（以及密封类）允许编译器对模式匹配和 switch 表达式进行穷尽检查，这在编译时显著提升了类型安全。

然而，我想了解 运行时 的影响。具体来说：

• JVM（尤其是HotSpot）在遇到密封接口时，是否会相较于普通的、未密封的一个接口，应用任何专门的优化？
• 例如，JIT编译器是否会主动使用 PermittedSubclasses 属性，使内联、去虚拟化或类层次分析（CHA）更积极或更稳定？
• 或者现实情况是，密封接口只在编译时强制契约，运行时它们被当作与其他接口完全相同的对象对待（受同样的标准CHA和去优化策略的约束）？

换句话说，是否存在因为接口是密封而带来的可衡量的性能提升，还是好处仅仅是编译时的穷尽性保证，可以防止错误？

解决方案

TL;DR：没有，也永远不会有优化因此被启用。因为JVM已经在做这项优化，而且很久以前就已经在做了。

不可能的优化

语言层面的Java的很多方面在编译过程后就不会保留。例如，‘泛型擦除’就是一个众所周知的例子。检查异常在JVM级别也并不存在（javac 知道 throws 的定义是什么以及意味着什么；java 运行时引擎根本不知道；它只能为了完全忽略它们而读取 throws 那一行）。

局部变量也不会保留（它们会被“压缩”成槽位）。任何依赖运行时知道在编译时不会保留的信息的优化，都是很容易就不可能实现的。

密封类就不是那样的。它们会保留：类文件格式会明确列出允许的子类。

但这并不意味着它对JVM有实质性的帮助；JVM无法对其作出有意义的利用。

Java的总体设计让运行时无法预先加载密封类：给定一个完全限定名，运行时不能加载这样的类。它只能加载带有 [fully qualified type name, classloader] 元组的类，而这并不是 sealed 系统的工作方式（只要类型的完全限定名在允许列表中就可以加载，加载它的类加载器并不重要。甚至某些动态生成的、现在甚至还不存在的类加载器也可以加载它）。从这个意义上说，“密封”并不真正地密封。在任何时刻，任意代码都可以创建一个新的类加载器，并让该加载器加载一个完全限定名在列表中的新类。可以创建、加载无限数量的被允许的类。

这意味着JVM：

• 无法断定每一个可能的子类实际都已加载。即使为 sealed 定义中列出的每一个允许子类都加载了一个类也如此。
• 也无法通过从 sealed 类型定义中的“允许子类”列表来预先加载已知的子类。

这基本上就等于说：JVM不能应用任何有意义的优化。

但……没关系——JVM已经在做了

因为JVM做的是我称之为“乐观封sealing”的事情。类似于乐观锁的概念，HotSpot编译器通常只是假设所有类型都是密封的：

如果通过假设某个类型的所有子类型都已知并且被枚举可以获得显著的性能提升，那么它就会像假设以后再也不会出现新的子类型一样进行热更新。

然后，JVM的类加载系统获得一个钩子：如果你定义了这个类型的一个子类型，就使生成的HotSpot代码失效。

这是一个“鱼和熊掌都要”的时刻：JVM获得动态加载任意你想要的子类型的全部好处，同时又能在需要避免不断动态派发时，避免其潜在的高成本。

这个系统在HotSpot编译器中已经存在了很长时间，是一个高流量的优化点：大量非常常用的类并不是 final，但很少有子类型。现在就把它们设为 final，会带来向后不兼容的问题。举一个最常用的JVM类的简单例子：ArrayList —— 它并不是final的，然而很少被扩展。

结论

因此，不需要HotSpot特别关心sealed。通过它可以应用的显而易见的优化，本质上是在不需要知道 sealed 的情况下，JVM也能同样应用这些优化。

[1] 好吧，永远不要说永远。Java语言规范非常具体，但JVM规范要宽松得多：JVM规范谈的是“保证”；一个JVM实现必须确保所有保证被充分兑现，但除此之外它可以自行决定实现细节。这一点很重要，以便允许不同平台上的JVM实现选择更高效的策略来实现这些保证。举例来说，JMM（Java内存模型）部分并未以任何方式规定应使用哪些CPU原语来确保 synchronized 和 volatile 的工作方式。它们仅以“给定这段代码，在修改X 之后，Y行在时间上的观察不能比修改前更早”为原则来表述。一旦JVM实现提供了该保证，就算实现方式不同也符合规范；实现细节如何实现并不重要。从这个意义上讲，绝对的承诺并不存在。

[2] 你可能在想：OpenJDK团队一直强调现代JVM版本在“安全性”方面非常认真，这听起来似乎不太安全！不是“安全性”的错。一般而言，如果你允许不受信任的代码在JVM上运行，你就已经在某种程度上输了，必须假设若该代码是恶意的，JVM的每个方面现在都处在恶意代码的完全控制之下——但模块系统是它的基础：你不能在同一个模块中使用允许列表中的同名类来扩展一个密封类。即便在同一个模块内，运行时也可以创建一个新的类加载器，然后加载一个完全限定名在“被允许！”名单上的类，这就意味着它可以被加载。