重磅！Java 16 正式发布

重磅！Java16正式发布Java16发布了！2020年是值得纪念的一年，这一年中我们庆祝了Java的25岁生日。经过二十多年的持续创新，Java一直在：通过适应不断变化的技术格局来保持灵活性，同时维持平台独立性。通过保持向后兼容性来保证可靠性。在不牺牲安全性的前提下加速创新来保持优势。Java凭借自身不断提高平台性能、稳定性和安全性的能力，一直是开发人员中最流行的编程语言。IDC的最新报告“JavaTurns25”显示，超过900万名开发人员（全球专职开发人员中的69%）在使用Java——比其他任何语言都多。甲骨文还在继续探索Java的持续创新之路，并自豪地宣布Java16正式发布，这也是我们转向六个月发布周期后的第七个特性版本。这种可预测水平使开发人员可以更轻松地管理他们对创新的采用计划。上图显示了自Java8以来每个版本的特性数量1Java16现在已可用甲骨文现在为所有开发人员和企业提供Java16，按照甲骨文重要补丁更新（CPU）时间表，甲骨文JDK16将至少获得两次季度更新，随后是甲骨文JDK17。Java17将于2021年9月正式发布，但是已经提供了它的早期访问版本。甲骨文再次使用开源GNU通用公共许可证v2和ClasspathException（GPLv2+CPE）将Java16作为甲骨文OpenJDK版本提供，并且针对使用甲骨文JDK版本作为甲骨文产品或服务一部分的用户，或希望能够获得商业支持的用户提供商业许可。2Java16，我们携手同行与之前的版本类似，我们将继续感谢来自OpenJDK社区中众多个人和组织对Java16所做的贡献——我们携手同行，共同构建Java！JDK16修复比率JDK的总体变化率多年来一直保持基本稳定，但是在六个月的发布周期下，可用于生产的创新交付速度已大大提高。过去，我们每隔几年在大型主要版本中发布成千上万的修复和大约一百个JDK增强提案（JEP）；而现在，我们改为更易于管理、更容易预测的六个月周期，在较小的特性版本中提供增强特性。这些更改的范围从重大特性到小型改进和例行维护、错误修复和文档改进。每个更改都在JDK错误系统中用一个问题的一次提交来表示。在Java16中标记为修复的1,897个问题中，有1,397个由甲骨文工作人员完成，还有500个由个人开发人员和为其他组织工作的开发人员贡献。我们整理了贡献者所在组织的数据，得到了以下组织分布图：上图显示每个组织贡献的修复数量甲骨文要感谢为ARM、SAP、RedHat和腾讯等组织工作的开发人员所做的杰出贡献，同时也感谢来自小型组织（如AmpereComputing、Bellsoft、DataDog、Microdoc和独立开发人员）的贡献，他们贡献了Java16中3％的修复。我们同样感谢许多审查提案更改的经验丰富的开发人员、尝试采用早期访问版本并报告问题的早期采用者、以及在OpenJDK邮件列表中提供反馈的敬业专业人员。3Java16的新特性伴随着数千个性能、稳定性和安全性更新，Java16为用户提供了十七项主要的增强/更改（称为JDK增强提案——JEP），包括三个孵化器模块和一个预览特性。孵化器模块（IncubatorModule）中引入了一些增强，这是一种将非最终API和非最终工具交给开发人员的方法，该方法允许用户提供反馈，从而改善Java平台的质量。搜索后端架构师公众号回复“架构整洁”，送你一份惊喜礼包。同样，一些增强被作为JavaSE平台的预览特性、语言或VM特性引入，这些增强已完全指定、完全实现但不是永久性的。JDK特性版本中提供了这些增强，以推动开发人员根据实际使用情况提供反馈，这可能会导致它们在将来的版本中永久保留。这为用户提供了及时反馈的机会，并让工具供应商有机会在大量Java开发人员在生产中使用特性之前为其提供支持。Java16随附的17个JEP分为六个不同类别：新语言特性

JEP394，适用于instanceof的模式匹配模式匹配（PatternMatching）最早在Java14中作为预览特性引入，在Java15中还是预览特性。模式匹配通过对instacneof运算符进行模式匹配来增强Java编程语言。模式匹配使程序中的通用逻辑（即从对象中有条件地提取组件）得以更简洁、更安全地表示。

JEP

395，记录记录（Records）在Java14和Java15中作为预览特性引入。它提供了一种紧凑的语法来声明类，这些类是浅层不可变数据的透明持有者。这将大大简化这些类，并提高代码的可读性和可维护性。JVM改进

JEP

376，ZGC并发线程处理JEP376将ZGC线程栈处理从安全点转移到一个并发阶段，甚至在大堆上也允许在毫秒内暂停GC安全点。消除ZGC垃圾收集器中最后一个延迟源可以极大地提高应用程序的性能和效率。

JEP

387，弹性元空间此特性可将未使用的HotSpot类元数据（即元空间，metaspace）内存更快速地返回到操作系统，从而减少元空间的占用空间。具有大量类加载和卸载活动的应用程序可能会占用大量未使用的空间。新方案将元空间内存按较小的块分配，它将未使用的元空间内存返回给操作系统来提高弹性，从而提高应用程序性能并降低内存占用。新工具和库

JEP

380，Unix-Domain套接字通道Unix-domain套接字一直是大多数Unix平台的一个特性，现在在Windows10和WindowsServer2019也提供了支持。此特性为java.nio.channels包的套接字通道和服务器套接字通道API添加了Unix-domain（AF_UNIX）套接字支持。它扩展了继承的通道机制以支持Unix-domain套接字通道和服务器套接字通道。Unix-domain套接字用于同一主机上的进程间通信（IPC）。它们在很大程度上类似于TCP/IP，区别在于套接字是通过文件系统路径名而不是Internet协议（IP）地址和端口号寻址的。对于本地进程间通信，Unix-domain套接字比TCP/IP环回连接更安全、更有效。

JEP

392，打包工具此特性最初是作为Java14中的一个孵化器模块引入的，该工具允许打包自包含的Java应用程序。它支持原生打包格式，为最终用户提供自然的安装体验，这些格式包括Windows上的msi和exe、macOS上的pkg和dmg，还有Linux上的deb和rpm。它还允许在打包时指定启动时参数，并且可以从命令行直接调用，也可以通过ToolProviderAPI以编程方式调用。注意jpackage模块名称从jdk.incubator.jpackage更改为jdk.jpackage。这将改善最终用户在安装应用程序时的体验，并简化了“应用商店”模型的部署。为未来做好准备

JEP

390，对基于值的类发出警告此特性将原始包装器类（java.lang.Integer、java.lang.Double等）指定为基于值的（类似于java.util.Optional和java.time.LocalDateTime），并在其构造器中添加forRemoval（自JDK9开始被弃用），这样会提示新的警告。在Java平台中尝试在任何基于值的类的实例上进行不正确的同步时，它会发出警告。许多流行的开源项目已经在其源中删除了包装构造器调用来响应Java9的弃用警告，并且鉴于“弃用移除”警告的紧迫性，我们可以期望更多开源项目跟上这一步伐。

JEP

396，默认强封装JDK内部元素此特性会默认强封装JDK的所有内部元素，但关键内部API（例如sun.misc.Unsafe）除外。默认情况下，使用早期版本成功编译的访问JDK内部API的代码可能不再起作用。鼓励开发人员从使用内部元素迁移到使用标准API的方法上，以便他们及其用户都可以无缝升级到将来的Java版本。强封装由JDK9的启动器选项–illegal-access控制，到JDK15默认改为warning，从JDK16开始默认为deny。（目前）仍然可以使用单个命令行选项放宽对所有软件包的封装，将来只有使用–add-opens打开特定的软件包才行。孵化器和预览特性

JEP

338，向量API（孵化器）该孵化器API提供了一个API的初始迭代以表达一些向量计算，这些计算在运行时可靠地编译为支持的CPU架构上的最佳向量硬件指令，从而获得优于同等标量计算的性能，充分利用单指令多数据（SIMD）技术（大多数现代CPU上都可以使用的一种指令）。尽管HotSpot支持自动向量化，但是可转换的标量操作集有限且易受代码更改的影响。该API将使开发人员能够轻松地用Java编写可移植的高性能向量算法。

JEP

389，外部链接器API（孵化器）该孵化器API提供了静态类型、纯Java访问原生代码的特性，该API将大大简化绑定原生库的原本复杂且容易出错的过程。Java1.1就已通过Java原生接口（JNI）支持了原生方法调用，但并不好用。Java开发人员应该能够为特定任务绑定特定的原生库。它还提供了外来函数支持，而无需任何中间的JNI粘合代码。

JEP

393，外部存储器访问API（第3个孵化器）在Java14和Java15中作为孵化器API引入的这个API使Java程序能够安全有效地对各种外部存储器（例如本机存储器、持久性存储器、托管堆存储器等）进行操作。它提供了外部链接器API的基础。

JEP

397，密封类（第二预览）这个预览特性可以限制哪些类或接口可以扩展或实现它们；它允许类或接口的控制负责实现它的代码；它还提供了比访问修饰符更具声明性的方式来限制对超类的使用。它还通过对模式进行详尽的分析来支持模式匹配的未来发展。提升OpenJDK开发人员的生产力其余更改对Java开发人员（使用Java编写代码和运行应用程序的人员）不会直接可见，而只对Java开发人员（参与OpenJDK开发的人员）可见。

JEP

347，启用C++14语言特性（在JDK源代码中）它允许在JDKC++源代码中使用C++14语言特性，并提供在HotSpot代码中可以使用哪些特性的具体指导。在JDK15中，JDK中C++代码使用的语言特性仅限于C++98/03语言标准。它要求更新各种平台编译器的最低可接受版本

JEP357，从Mercurial迁移到Git；JEP369，迁移到GitHub这些JEP将OpenJDK社区的源代码存储库从Mercurial（hg）迁移到Git，并将它们托管在GitHub上以供JDK11及更高版本使用，其中包括将jcheck、webrev和defpath工具等工具更新到Git。Git减小了元数据的大小（约1/4），可节省本地磁盘空间并减少克隆时间。与Mercurial相比，现代工具链可以更好地与Git集成。OpenJDKGit存储库现在位于/openjdk。

JEP386，AlpineLinux移植；JEP388，Windows/AArch64移植这些JEP的重点不是移植工作本身，而是将它们集成到JDK主线存储库中；JEP386将JDK移植到AlpineLinux和其他使用musl作为x64上主要C库的发行版上。此外，JEP388将JDK移植到WindowsAArch64（ARM64）。4工具链支持当前的工具链支持有助于提高开发人员的生产力。在Java16中，我们继续欢迎领先的IDE