随着 Java 的不断发展，为了减轻维护的压力，一些功能会被声明为废弃，并最终从 Java 中删除。我之前发了3个视频，介绍 Java 中即将移除的功能。这里进行一下总结。

Java 中删除功能的流程

从 Java 中移除功能有一个标准的流程。在删除之前，首先会声明为废弃的。相关的 API 会被加上 @Deprecated 注解。废弃分成两种：一种只是单纯的废弃，另外一种是废弃之后会在今后的版本中被删除。区别在于 @Deprecated 注解的属性值 forRemoval 是否为 true。

声明为废弃待删除的 API 会在之后的版本中被删除。

Applet

Java 的 Applet 是一个极具争议的技术。在 Java 的早期时代，Applet 确实是 Java 的一个杀手级应用。直接在浏览器就可以下载应用并运行。随着技术的发展，Applet的技术优势不再明显，又带来了很多的安全隐患。很多浏览器都已经移除了对 Applet 的支持。失去了浏览器的支持，Applet 技术自然也就没有了存在的必要。Applet 相关的API 在 Java 9 就已经被声明为废弃的，在 Java 17 中进一步被声明为废弃待删除。虽然还没有正式移除，但是我们已经可以对 Applet 说再见了。

Security Manager

Java 中另外一个即将被删除的功能是 Security Manager。Security Manager 在 Java 17 中被声明为废弃待删除。虽然暂时不会被删除，但是它的命运已经注定了。

为什么 Security Manager 被移除？最大的原因是 Applet 被移除了。Security Manager 在设计之初有两个目标，分别是保证客户端代码和服务器端代码的安全。这里的客户端代码指的是通过 Applet 下载到本地执行的代码。因为 Applet 是从远程不受信任的地址下载到本机的，因此只能运行在受限的环境中。Security Manager 的作用就是确保这些代码不会做一些坏的事情。具体的做法是通过权限机制来进行限制，比如不能通过 Java I/O API 来操作本地文件。Applet 技术已经被废弃，也基本上没有什么浏览器支持了。Security Manager就失去了存在的一个重要理由。

Security Manager 的第二个目标是提供一套安全相关的标准API，给服务器端应用来使用。这个出发点是好的，但是与安全相关的需求太复杂。从 Java 1.0 时代就存在的 Security Manager 在 API 设计上，存在太多局限性，无法满足现在应用的需求。基于权限的访问控制已经不流行了。相关的 API 使用起来十分繁琐。Security Manager也会带来性能问题。

基于上面两个原因，Security Manager 存在的价值已经很小，并且会带来很高的维护成本。因此 Security Manager 即将被移除。

对象终止机制

对象终止机制（Finalization ）从 JDK 1.0 就已经存在。它的设计目标是避免出现资源泄露。

JVM 的垃圾回收器负责进行内存的回收。有些对象表示的是操作系统的资源，比如文件句柄或原生内存。这些资源需要被释放回操作系统。在对象终止机制中，每个类可以声明一个 finalize 方法。在该方法的实现中，添加释放资源的逻辑，比如调用 close 方法。当对象不可达时，GC 会首先调用 finalize 方法，再回收该对象。

对象终止机制虽然看上去很巧妙，但是在实际使用中存在很多问题。比如，finalize 方法被调用的时机是不确定的，甚至可能永远不会被调用，导致资源无法被及时释放。finalize 方法还可能使得对象重生，造成一些不可预知的错误。

因为对象终止机制的这些问题，目前已经不推荐使用 finalize 方法。Effective Java 一书中有专门的一个条目，Avoid finalization 来讨论这一点。

从 Java 18 开始，对象终止机制被声明为废弃待删除。由于对象终止机制在 JDK 和流行的库中被大量使用，对象终止机制仍然是默认启用的。JVM 启动参数 --finalization=disabled 可以禁用对象终止机制。通过这个参数，可以测试应用是否依赖对象终止机制。对象终止机制虽然在短期内不会被移除，但是应该考虑对已有的代码进行迁移，使之不再依赖对象终止机制。具体的做法是，改用 try-with-resources 来主动释放资源，或使用 Java 9 增加的 Cleaner API。

如果你的应用仍在使用这些将要被删除的功能，尽早规划替代方案。