你好，我是猿java。
当你还在 JDK 8驰骋沙场，大张旗鼓搞可扩展性时，JDK 15却已暗度陈仓："偷偷摸摸"搞起了 Sealed Classes（封闭类）的功能，为何一向主张可扩展性的 Java，却会反其道而行之，推出封闭类这个功能？今天就让我们一起来聊聊这期中的原委。
申明：本文基于 jdk-17.0.5
2020年，给 JDK 15增加 Sealed Classes（封闭类）的提案被提交，在经历了 JDK 16版本的迭代后，最终该功能在 JDK 17正式发布，Sealed Classes发展的 JEP如下：
JEP: JDK Enhancement Proposal, JDK增强建议，JEP是一个JDK核心技术相关的增强建议文档；
什么是封闭类
Sealed Classes：翻译为 密封类、封闭类。代表该类/接口是一个封闭的类/接口，只有许可的类/接口 才能继承或实现该类/接口。如下图来自 JDK真实封闭类源码：
因此，用 sealed关键字修饰的类就是封闭类。
为什么需要封闭类
像Java 这种面向对象的编程语言，可扩展性是衡量设计优劣的一个重要指标，可是 Java为何要引入封闭类？ 这不是明晃晃的限制扩展性吗？
其实，这是安全性和扩展性权衡的一个结果。
可能有小伙伴会说：控制继承能力，用 Java现有的方式就ok，为何还需要多增加一个封闭类呢？
那我们先看看 Java现有的 2种控制继承能力的方法：
- 用关键字 final修饰类，类就成了终态类，无法被继承；比如我们经常使用的 String类。
将类定义为 final后，类就完全失去了扩展性，简单粗暴，适合完全不需要扩展的类/接口。
- package-private类，也就是非 public类，这样只有同包下的类才能继承，比如：java.nio中的 Bits类；
将类申明为非 public（package-private），只有同包下的类才能继承，尽管在同包下还是保留了扩展，但是可能会出现下面的安全问题。
再来看看继承带来的安全问题：
如下代码为 java.io.FileCleanable 源码，该类主要是用来清理文件。在 JDK中，FileCleanable类被申明成 final，也就意味着该类不能被继承，不能被扩展了，为什么要把FileCleanable类申明成 final呢？
final class FileCleanable extends PhantomCleanable<FileDescriptor> {
// 省略部分代码
@Override
public void clear() {
if (remove()) {
super.clear();
}
}
}
假如去掉 FileCleanable类的final关键字，因此就可以实现自定义类 MyFileCleanable去继承 MyFileCleanable类，并且覆写 clear()，或者新增add()方法，代码示例如下，这样会带来什么问题呢？
public class MyFileCleanable extends FileCleanable {
// 省略代码
@Override
public void clear() {
// 实现自定义文件删除逻辑，删除所有文件
cearAllFolders();
}
public void add(){
}
}
原本 FileCleanable类中的 clear方法只能JVM 内部调用，如果开放扩展性，自定义类就可以覆写clear()方法，因此可以任意修改 clear()的逻辑，假如用户A 本来并没有操作clear()的权限，但是因为类的继承扩展而获得了该权限，如果不小心删除了重要文件，结果可能是直接去财务室结账走人...
因此子类继承父类，获得扩展性主要会带来2个影响：
- 子类可以覆写父类中的现有方法；
- 子类可以为父类添加新方法；
上述两个影响都可能带来安全性的问题，因此我们在设类时需要多思考一些安全性相关的问题：
- 类有没有必要被子类扩展，被扩展后会不会有安全问题，该类能不能被定义成 final？
- 类中的方法，被子类拿到会不会有安全问题，能不能被定义成 final？
综上，使用 final和 package-private 两种限制方式的粒度都比较粗，不限制的话又可能带来一些安全隐患，所以我们就会想，有没有粒度细一点又能解决安全隐患的问题，因此，封闭类就"粉墨登场"了。
如何使用封闭类
有了封闭类，要如何使用呢？我们先看下 JDK 12引入的几个源码类（在jdk 17 中被加上了 sealed修饰）：
public sealed interface ConstantDesc
permits ClassDesc,
MethodHandleDesc,
MethodTypeDesc,
Double,
DynamicConstantDesc,
Float,
Integer,
Long,
String {
// 省略代码
}
public sealed interface ClassDesc
extends ConstantDesc,
TypeDescriptor.OfField<ClassDesc>
permits PrimitiveClassDescImpl,
ReferenceClassDescImpl {
// 省略代码
}
final class PrimitiveClassDescImpl
extends DynamicConstantDesc<Class<?>> implements ClassDesc {
// 省略代码
}
public abstract non-sealed class DynamicConstantDesc<T>
implements ConstantDesc {
// 省略代码
}
在解释上述源码之前，铺垫 JDK 17中因密封类而增加了几个重要关键词：
- sealed：（封闭）用于修饰类/接口，代表这个类/接口为密封类/接口；
- non-sealed：（非封闭）用于修饰类/接口，代表这个类/接口为非密封类/接口；
- permits：（允许）用于 extends和 implements之后，指定能够继承或实现封闭类的子类/接口；
了解了 JDK17增加的几个关键字之后，我们再来分析上面的源码，从源码中我们可以发现，sealed 通常和 permits关键字一起使用。
首先通过关键字 sealed申明一个封闭的接口 ConstantDesc，然后用 permits关键字允许 ClassDesc,
MethodHandleDesc,
MethodTypeDesc,
Double,
DynamicConstantDesc,
Float,
Integer,
Long,
String 能够实现或者继承 ConstantDesc这个接口。
然后，扩展类 PrimitiveClassDescImpl 定义成 final，代表它是一个终态类，无法被继承，DynamicConstantDesc 被定义成 non-sealed，代表它的子类还可以继续继承扩展它。
最后，我们对封闭类总结如下：
- 申明封闭类：在类前面加 sealed关键字；
- 给封闭类开放扩展权限：在类声明后加上 permits关键字，后面加上需要授权的类；
- 许可类可以申明成 final，关闭扩展性；可以声明为 sealed，延续扩展性；也可以申明成 non-sealed，支持扩展性不受限；
- permits 关键字指定的许可子类（permitted subclasses），必须和封闭类处于同一模块（module）或者包空间（package）里；
总结
- sealed通常和 permits关键字一起使用；
- sealed封闭类提供了更精细粒度的可扩展性；
- sealed封闭类可以更好地控制代码的安全性和健壮性；
- 尽管目前国内大部分业务的代码还是运行在 JDK8环境上，但是了解 JDK的新特性对可以帮助我们更好的了解它以后的一个发展趋势；
学习交流
文章总结不易，如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注：猿java，持续输出硬核文章。
