共计 4579 个字符，预计需要花费 12 分钟才能阅读完成。
2020 年是值得纪念的一年，这一年中咱们庆贺了 Java 的 25 岁生日。通过二十多年的继续翻新，Java 始终在：
- 通过适应一直变动的技术格局来放弃灵活性，同时维持平台独立性。
- 通过放弃向后兼容性来保障可靠性。
- 在不就义安全性的前提下减速翻新来放弃劣势。
Java 凭借本身一直进步平台性能、稳定性和安全性的能力，始终是开发人员中最风行的编程语言。IDC 的最新报告“Java Turns 25”显示，超过 900 万名开发人员（寰球专职开发人员中的 69%）在应用 Java——比其余任何语言都多。
甲骨文还在持续摸索 Java 的继续翻新之路，并骄傲地发表 Java 16 正式公布，这也是咱们转向六个月公布周期后的第七个个性版本。这种可预测程度使开发人员能够更轻松地治理他们对翻新的采纳打算。
上图显示了自 Java 8 以来每个版本的个性数量
Java 16 当初已可用
甲骨文当初为所有开发人员和企业提供 Java 16，依照 甲骨文重要补丁更新（CPU）时间表，甲骨文 JDK 16 将至多取得两次季度更新，随后是甲骨文 JDK 17。Java 17 将于 2021 年 9 月正式公布，然而 jdk.java.net 曾经提供了它的晚期拜访版本。
甲骨文再次应用开源 GNU 通用公共许可证 v2 和 Classpath Exception（GPLv2+CPE）将 Java 16 作为甲骨文 OpenJDK 版本提供，并且针对应用甲骨文 JDK 版本作为甲骨文产品或服务一部分的用户，或心愿可能取得商业反对的用户提供商业许可。
Java 16，咱们携手同行
与之前的版本相似，咱们将持续感激来自 OpenJDK 社区中泛滥集体和组织对 Java 16 所做的奉献——咱们携手同行，独特构建 Java！
JDK 16 修复比率
JDK 的总体变化率多年来始终放弃根本稳固，然而在六个月的公布周期下，可用于生产的翻新交付速度已大大提高。
过来，咱们每隔几年在大型次要版本中公布成千上万的修复和大概一百个 JDK 加强提案（JEP）；而当初，咱们改为更易于治理、更容易预测的六个月周期，在较小的个性版本中提供加强个性。这些更改的范畴从重大个性到小型改良和例行保护、谬误修复和文档改良。每个更改都在 JDK 谬误零碎 中用一个问题的一次提交来示意。
在 Java 16 中标记为修复的 1,897 个问题中，有 1,397 个由甲骨文工作人员实现，还有 500 个由集体开发人员和为其余组织工作的开发人员奉献。咱们整顿了贡献者所在组织的数据，失去了以下组织分布图：
甲骨文要感激为 ARM、SAP、RedHat 和腾讯等组织工作的开发人员所做的杰出贡献，同时也感激来自小型组织（如 Ampere Computing、Bellsoft、DataDog、Microdoc 和独立开发人员）的奉献，他们奉献了 Java 16 中 3%的修复。
咱们同样感激许多审查提案更改的经验丰富的开发人员、尝试采纳晚期拜访版本并报告问题的晚期采纳者、以及在 OpenJDK 邮件列表中提供反馈的敬业业余人员。
Java 16 的新个性
随同着数千个性能、稳定性和安全性更新，Java 16 为用户提供了十七项次要的加强 / 更改（称为 JDK 加强提案——JEP），包含三个孵化器模块和一个预览个性。
孵化器模块（Incubator Module）中引入了一些加强，这是一种将非最终 API 和非最终工具交给开发人员的办法，该办法容许用户提供反馈，从而改善 Java 平台的品质。
同样，一些加强被作为 Java SE 平台的预览个性、语言或 VM 个性引入，这些加强已齐全指定、齐全实现但不是永久性的。JDK 个性版本中提供了这些加强，以推动开发人员依据理论应用状况提供反馈，这可能会导致它们在未来的版本中永恒保留。这为用户提供了及时反馈的机会，并让工具供应商有机会在大量 Java 开发人员在生产中应用个性之前为其提供反对。
Java 16 随附的 17 个 JEP 分为六个不同类别：
新语言个性
- JEP 394，实用于 instanceof 的模式匹配
模式匹配（Pattern Matching）最早在 Java 14 中作为预览个性引入，在 Java 15 中还是预览个性。模式匹配通过对 instacneof 运算符进行模式匹配来加强 Java 编程语言。
模式匹配使程序中的通用逻辑（即从对象中有条件地提取组件）得以更简洁、更平安地示意。
- JEP 395，记录
记录（Records）在 Java 14 和 Java 15 中作为预览个性引入。它提供了一种紧凑的语法来申明类，这些类是浅层不可变数据的通明持有者。这将大大简化这些类，并进步代码的可读性和可维护性。
JVM 改良
- JEP 376，ZGC 并发线程解决
JEP 376 将 ZGC 线程栈解决从平安点转移到一个并发阶段，甚至在大堆上也容许在毫秒内暂停 GC 平安点。打消 ZGC 垃圾收集器中最初一个提早源能够极大地提高应用程序的性能和效率。
- JEP 387，弹性元空间
此个性可将未应用的 HotSpot 类元数据（即元空间，metaspace）内存更疾速地返回到操作系统，从而缩小元空间的占用空间。具备大量类加载和卸载流动的应用程序可能会占用大量未应用的空间。新计划将元空间内存按较小的块调配，它将未应用的元空间内存返回给操作系统来进步弹性，从而进步应用程序性能并升高内存占用。
新工具和库
- JEP 380，Unix-Domain 套接字通道
Unix-domain 套接字始终是大多数 Unix 平台的一个个性，当初在 Windows 10 和 Windows Server 2019 也提供了反对。此个性为 java.nio.channels 包的套接字通道和服务器套接字通道 API 增加了 Unix-domain（AF_UNIX）套接字反对。它扩大了继承的通道机制以反对 Unix-domain 套接字通道和服务器套接字通道。Unix-domain 套接字用于同一主机上的过程间通信（IPC）。它们在很大水平上相似于 TCP/IP，区别在于套接字是通过文件系统路径名而不是 Internet 协定（IP）地址和端口号寻址的。对于本地过程间通信，Unix-domain 套接字比 TCP/IP 环回连贯更平安、更无效。
- JEP 392，打包工具
此个性最后是作为 Java 14 中的一个孵化器模块引入的，该工具容许打包自蕴含的 Java 应用程序。它反对原生打包格局，为最终用户提供天然的装置体验，这些格局包含 Windows 上的 msi 和 exe、macOS 上的 pkg 和 dmg，还有 Linux 上的 deb 和 rpm。它还容许在打包时指定启动时参数，并且能够从命令行间接调用，也能够通过 ToolProvider API 以编程形式调用。留神 jpackage 模块名称从 jdk.incubator.jpackage 更改为 jdk.jpackage。这将改善最终用户在装置应用程序时的体验，并简化了“利用商店”模型的部署。
为将来做好筹备
- JEP 390，对基于值的类收回正告
此个性将原始包装器类（java.lang.Integer、java.lang.Double 等）指定为基于值的（相似于 java.util.Optional 和 java.time.LocalDateTime），并在其结构器中增加 forRemoval（自 JDK 9 开始被弃用），这样会提醒新的正告。在 Java 平台中尝试在任何基于值的类的实例上进行不正确的同步时，它会收回正告。
许多风行的开源我的项目曾经在其源中删除了包装结构器调用来响应 Java 9 的弃用正告，并且鉴于“弃用移除”正告的紧迫性，咱们能够冀望更多开源我的项目跟上这一步调。
- JEP 396，默认强封装 JDK 外部元素
此个性会默认强封装 JDK 的所有外部元素，但要害外部 API（例如 sun.misc.Unsafe）除外。默认状况下，应用晚期版本胜利编译的拜访 JDK 外部 API 的代码可能不再起作用。激励开发人员从应用外部元素迁徙到应用规范 API 的办法上，以便他们及其用户都能够无缝降级到未来的 Java 版本。强封装由 JDK 9 的启动器选项–illegal-access 管制，到 JDK 15 默认改为 warning，从 JDK 16 开始默认为 deny。（目前）依然能够应用单个命令行选项放宽对所有软件包的封装，未来只有应用–add-opens 关上特定的软件包才行。
孵化器和预览个性 JEP 338，向量 API（孵化器）
该孵化器 API 提供了一个 API 的初始迭代以表白一些向量计算，这些计算在运行时牢靠地编译为反对的 CPU 架构上的最佳向量硬件指令，从而取得优于等同标量计算的性能，充分利用单指令多数据（SIMD）技术（大多数古代 CPU 上都能够应用的一种指令）。只管 HotSpot 反对主动向量化，然而可转换的标量操作集无限且易受代码更改的影响。该 API 将使开发人员可能轻松地用 Java 编写可移植的高性能向量算法。
- JEP 389，内部链接器 API（孵化器）
该孵化器 API 提供了动态类型、纯 Java 拜访原生代码的个性，该 API 将大大简化绑定原生库的本来简单且容易出错的过程。Java 1.1 就已通过 Java 原生接口（JNI）反对了原生办法调用，但并不好用。Java 开发人员应该可能为特定工作绑定特定的原生库。它还提供了外来函数反对，而无需任何两头的 JNI 粘合代码。
JEP 393，内部存储器拜访 API（第 3 个孵化器）
在 Java 14 和 Java 15 中作为孵化器 API 引入的这个 API 使 Java 程序可能平安无效地对各种内部存储器（例如本机存储器、持久性存储器、托管堆存储器等）进行操作。它提供了内部链接器 API 的根底。
- JEP 397，密封类（第二预览）
这个预览个性能够限度哪些类或接口能够扩大或实现它们；它容许类或接口的作者管制负责实现它的代码；它还提供了比拜访修饰符更具申明性的形式来限度对超类的应用。它还通过对模式进行详尽的剖析来反对模式匹配的
晋升 OpenJDK 开发人员的生产力
其余更改对 Java 开发人员（应用 Java 编写代码和运行应用程序的人员）不会间接可见，而只对 Java 开发人员（参加 OpenJDK 开发的人员）可见。
- JEP 347，启用 C++14 语言个性（在 JDK 源代码中）
它容许在 JDK C++ 源代码中应用 C++14 语言个性，并提供在 HotSpot 代码中能够应用哪些个性的具体指导。在 JDK 15 中，JDK 中 C++ 代码应用的语言个性仅限于 C++98/03 语言规范。它要求更新各种平台编译器的最低可承受版本
- JEP 357，从 Mercurial 迁徙到 Git；JEP 369，迁徙到 GitHub
这些 JEP 将 OpenJDK 社区的源代码存储库从 Mercurial（hg）迁徙到 Git，并将它们托管在 GitHub 上以供 JDK 11 及更高版本应用，其中包含将 jcheck、webrev 和 defpath 工具等工具更新到 Git。Git 减小了元数据的大小（约 1/4），可节俭本地磁盘空间并缩小克隆工夫。与 Mercurial 相比，古代工具链能够更好地与 Git 集成。
Open JDK Git 存储库当初位于 https://github.com/openjdk。
- JEP 386，AlpineLinux 移植；JEP 388，Windows/AArch64 移植
这些 JEP 的重点不是移植工作自身，而是将它们集成到 JDK 主线存储库中；JEP 386 将 JDK 移植到 Alpine Linux 和其余应用 musl 作为 x64 上次要 C 库的发行版上。此外，JEP 388 将 JDK 移植到 Windows AArch64（ARM64）。