Java16是一个重要的特性发布，它为JAVA带来了许多JVM特定的更改和语言特定的更改。它遵循了自JavaJava10以来引入的Java发布步调，并于2021年3月发布，仅在Java15发布后的六个月内发布。

Java 16是一个非LTS版本。

338:	Vector API (Incubator) 矢量API（孵化）
347:	Enable C++14 Language Features 启用C++14语言功能
357:	Migrate from Mercurial to Git 从Mercurial迁移到Git
369:	Migrate to GitHub 迁移到GitHub
376:	ZGC: Concurrent Thread-Stack Processing ZGC：并发线程堆栈处理
380:	Unix-Domain Socket Channels Unix域套接字通道
386:	Alpine Linux Port Alpine Linux端口
387:	Elastic Metaspace 弹性元空间
388:	Windows/AArch64 Port Windows/AArch64 Port
389:	Foreign Linker API (Incubator) 外部链接商API（孵化）
390:	Warnings for Value-Based Classes 基于值的类的警告
392:	Packaging Tool 打包工具
393:	Foreign-Memory Access API (Third Incubator) 外部内存访问API（第三次孵化）
394:	Pattern Matching for instanceof 增强instanceof
395:	Records 新增Record类
396:	Strongly Encapsulate JDK Internals by Default 默认情况下严格封装JDK内部
397:	Sealed Classes (Second Preview) 密封类（第二次预览）

JEP 338: Vector API (Incubator)

详情参阅java16学习笔记-Vector API

JEP 347: Enable C++14 Language Features

允许在JDK C++源代码中使用C++14语言功能，并就哪些功能可以在HotSpot代码中使用给出具体指导。

JEP 357: Migrate from Mercurial to Git

将OpenJDK社区的源代码库从Mercurial（hg）迁移到Git

JEP 369: Migrate to GitHub

在GitHub上托管OpenJDK社区的Git存储库。结合JEP 357Migrate from Mercurial to Git，这将把所有单一存储库OpenJDK项目迁移到GitHub，包括JDK功能版本和JDK 11及更高版本的更新版本。

JEP 376: ZGC: Concurrent Thread-Stack Processing

将ZGC线程堆栈处理从安全点转移到并发阶段。

Z垃圾收集器目标是解决JVM中的GC暂停和可扩展性问题。目前我们已经将所有随堆大小和元空间大小而扩展的GC操作，从安全点操作转移到并发阶段。这些包括标记、重定位、引用处理、类卸载和大多数根处理。
在GC安全点中仍然完成的唯一活动是根处理的一个子集和有时间限制的标记终止操作。根包括Java线程堆栈和各种其他线程根。这些根是有问题的，因为它们会随着线程的数量而扩展。大型机器上有许多线程，根处理成为一个问题。
为了超越我们今天所拥有的，并满足在GC安全点内花费的时间不超过一毫秒的期望，即使在大型机器上，我们也必须将每个线程的处理（包括堆栈扫描）转移到并发阶段。
在这项工作之后，ZGC安全点操作内部基本上不会做任何有意义的事情。
作为该项目的一部分构建的基础设施最终可能会被其他项目（如Loom和JFR）使用，以统一延迟堆栈处理。

JEP 380: Unix-Domain Socket Channels

对于本地，过程间通信，UNIX域插座比TCP/IP环回连接更安全，更有效。

UNIX域插座严格用于同一系统上的过程之间的通信。不打算接受远程连接的应用程序可以通过使用Unix-Domain插座来提高安全性。
Unix域插座受到强制执行的基于文件系统的访问控件的操作系统进一步保护。
与TCP/IP环回连接相比，Unix-Domain插座具有更快的设置时间和更高的数据吞吐量。
对于容器环境的TCP/IP套件，Unix-Domain插座可能是更好的解决方案，在该容器环境中，需要同一系统上的容器之间的通信。这可以使用位于共享量的插座来实现。

Unix-Domain插座长期以来一直是大多数UNIX平台的功能，现在在Windows 10和Windows Server 2019中得到支持。

为了支持Unix-Domain插座通道，我们将添加以下API元素：

一个新的插座地址类java.net.UnixDomainSocketAddress；
UNIX现有枚举的恒定值java.net.StandardProtocolFamily；
新的open工厂方法SocketChannel，ServerSocketChannel指定协议家族
更新到 SocketChannel规格ServerSocketChannel，以指定通向UNIX域插座行为的渠道。

JEP 386: Alpine Linux Port

将JDK移至Alpine Linux，以及其他使用MUSL作为主要C库的Linux发行版，都可以在X64和AARCH64架构上。

JEP 387: Elastic Metaspace

更及时地将未使用的HotSpot类元数据（即元空间）内存还给操作系统，减少元空间的占用，并简化元空间代码，以降低维护成本。

JEP 388: Windows/AArch64 Port

将 JDK 移植到 Windows/AArch64。

JEP 389: Foreign Linker API (Incubator)

引入一个 API，提供对本机代码的静态类型、纯 Java 访问。此 API 与外部内存 API （JEP 393）一起，将大大简化绑定到本机库的容易出错的过程。

详情可以查看文章 Foreign-Memory Access API外部内存API -CSDN博客

JEP 390: Warnings for Value-Based Classes

将原始包装器类指定为基于值的，并弃用其构造函数，提示新的弃用警告。提供有关在 Java 平台中任何基于值的类。

对于用构造函数创建包装类的java语句例如：Double d = new Double(Math.random())

java8会给出建议

java9-java15

java16代码给出警告（飘红），但是可以运行，

JEP 392: Packaging Tool

提供用于打包独立 Java 应用程序的工具。jpackage

该工具由 JEP 343 作为孵化工具引入 JDK 14。在 JDK 15 中，它仍然是一个孵化工具，以便有时间获得额外的反馈。现在，它已准备好从孵化提升为生产就绪功能。由于此转换，模块的名称将从更改为。jpackagejpackagejdk.incubator.jpackagejdk.jpackage

相对于 JEP 343 的唯一实质性变化是，我们将该选项替换为更通用的选项，如下：--bind-services--jlink-options

基本用法

$ jpackage --name myapp --input lib --main-jar main.jar

如果所打包文件没有Main-Class属性，则必须指定主类

$ jpackage --name myapp --input lib --main-jar main.jar \--main-class myapp.Main

模块化

$ jpackage --name myapp  --module-path --input lib --main-jar main.jar \--main-class myapp.Main

JEP 393: Foreign-Memory Access API (Third Incubator)

引入一个 API，允许 Java 程序安全高效地访问 Java 堆之外的外部内存。

详情可以查看文章 Foreign-Memory Access API外部内存API -CSDN博客

JEP 394: Pattern Matching for instanceof

通过运算符的模式匹配来增强 Java 编程语言。模式匹配允许程序中的通用逻辑，即条件提取对象中的组件，以更简洁、更安全地表达。instanceof

详情可以查看文章 java14学习笔记-part1-CSDN博客

JEP 395: Records

使用Records增强 Java 编程语言充当不可变数据的透明载体。

记录由 JEP 359 提出，并在 JDK 14 中作为预览功能提供。

为了响应反馈，JEP 384 对设计进行了改进，并在 JDK 15 中作为预览功能。第二次预览的改进如下：

在第一个预览版中，规范构造函数需要为 . 在第二个预览中，如果规范构造函数是隐式声明，则其访问修饰符与 record 类相同;如果规范构造函数被显式声明，然后它的访问修饰符必须提供至少与 Record 类一样多的访问权限。public
注释的含义被扩展为包括注释方法是显式声明的访问器方法的情况记录组件。@Override
为了强制执行紧凑构造函数的预期用途，它变成了编译时 error 分配给构造函数正文中的任何实例字段。
能够声明本地记录类、本地枚举类和本地接口被介绍。

本 JEP 建议在 JDK 16 中完成该功能，并进行以下改进：

放宽长期以来的限制，即内部阶级不能声明显式或隐式静态的成员。这将成为合法的特别是，将允许内部类声明作为记录类的成员。

根据进一步的反馈，可能会进行其他改进。

详情可以查看文章 java14学习笔记-part1-CSDN博客

JEP 396: Strongly Encapsulate JDK Internals by Default

默认情况下，强封装 JDK 的所有内部元素，但用于关键的内部 API，例如 .允许结束用户选择宽松的强封装，即一直自 JDK 9 以来的默认值。sun.misc.Unsafe

持续提升 JDK 的安全性和可维护性

鼓励开发者从使用内部元素迁移到标准 API，以便他们和他们的用户都可以在没有对未来的 Java 版本大惊小怪。

JEP 397: Sealed Classes (Second Preview)

使用密封的类和接口增强 Java 编程语言。密封的类和接口限制了哪些其他类或接口可以扩展或实现它们。这是 JDK 16 中的预览语言功能。

密封类是由 JEP 360 提出的，并且在 JDK 15 中作为预览功能交付。

本 JEP 建议在 JDK 16 中重新预览该功能，并进行以下改进：

指定上下文关键字的概念，取代先前的概念JLS 中的受限标识符和受限关键字。引入字符序列、和作为上下文关键字。sealednon-sealedpermits
与匿名类和 lambda 表达式一样，局部类可能不是密封类的子类，在确定隐式声明的允许类或接口的子类时。sealedsealed
增强缩小引用转换，以执行更严格的检查相对于密封类型层次结构的转换。