JDK 16在2021年2月18日已完成最终候选版本，并于2021年3月16日正式发布。和JDK 15一样，JDK 16也会是一个短期版本，仅支持六个月。而计划在2021年9月发布的JDK 17将会是一个长期支持（LTS）版本，并获得数年的支持。虽然JDK 16是个短期版本，并且大部分的企业或者项目还依然停留在2018年9月发布的JDK 11（甚至更早的于2014年3月发布的JDK 8），但不妨碍Javaer对新版JDK的期待与持续学习的热情。
本文将与大家一起来玩一玩 JDK 16。
新特性一览
在开始之前，先让我们来一起浏览一下JDK 16版本所带来的17个新特性吧。
▐ 本文将解读的新特性
357: OpenJDK源代码仓库从Mercurial迁移至Git。努力推动这一改变，将会在版本控制系统元数据大小、可用工具以及托管等方面体现优势。
369: 迁移到GitHub，这个变化是基于OpenJDK源码库迁移至Git的，JDK 16源代码仓库将出现在最流行的程序员社交网站上。
386: 在x64和AArch64架构上，将JDK移植到Alpine Linux和其他使用musl作为其主要C库的Linux发行版。Musl是 ISO C和Posix标准中描述的标准库功能的Linux实现。Alpine Linux由于其镜像小而被广泛应用于云部署、微服务以及容器环境中。Linux版本的Docker容器镜像小于6MB。让Java在此类设置中开箱即用地运行，并允许Tomcat、Jetty、Spring和其它流行的框架在这些环境中工作。通过使用jlink来减少Java运行时的大小，用户可以创建一个更小的镜像，以运行特定的应用程序。
394: instanceof操作符的模式匹配，在JDK 14和JDK 15中都已预览过，将于JDK 16最终确定。模式匹配使程序中的通用逻辑（即从对象中有条件的提取组件）可以更简洁、更安全的表达。
395: 提供Record记录类，作为不可变数据的透明载体。
▐ 其他的新特性
347: 启用C++ 14语言功能，允许在JDK C++源代码中使用C++ 14功能，并提供有关在HotSpot代码中可以使用哪些功能的具体指导。
376: 将ZGC（可扩展低延迟垃圾收集器）线程堆栈处理从安全点移至并发阶段。ZGC垃圾收集器旨在使HotSpot中的GC暂停和可伸缩性问题成为过去。
380: 添加Unix-Domain Socket Channels，其中Unix-Domain（AF_UNIX）套接字的支持被添加到nio.channels包中的Socket Channel和Server Socket Channel API中。
387: 弹性Metaspace功能可将未使用的HotSpot虚拟机的Class Metadata(Metaspace)占用的内存更迅速的返回给操作系统，从而减少Metaspace的占用并简化Metaspace的代码以降低维护成本。
388: 将JDK移植到Windows/AArch64平台。
389: 孵化阶段的外部链接程序API，支持静态类型的纯Java方式访问本地代码。此计划的目的在于通过用更高级的纯Java开发模式来替换JNI（Java本机接口），以提供与C语言的交互。它的性能将会比JNI更加优越。
390: 基于值的类的警告建议：将原始包装类指定为基于值的类，弃用其构造函数以进行移除，并提示新的弃用警告。在Java平台中对于任何基于值的类的实例进行同步的错误尝试会予以警告。
392: 提供用于打包独立的Java应用程序的jpackage工具。
396: 默认情况下，JDK内部结构是强封装的，而关键内部API（例如misc.Unsafe）除外。此计划的目标包括提高JDK的安全性和可维护性，并鼓励开发人员从直接使用内部元素逐渐迁移为使用标准API，这样开发人员和最终用户都可以轻松地升级到 Java 的未来版本。
397: 之前在JDK 15中进行过预览，JDK 16中二次预览的密封类和接口限制了可以扩展或实现它们的类和接口。此计划的目标包括允许类或接口的创建者控制负责实现它的代码，提供比访问修饰符更声明性的方式来限制超类的使用，并通过提供模式分析基础来支持模式匹配的未来发展。
338: 孵化阶段的矢量API（JDK将配备一个孵化器模块），jdk.incubator.vector，以表达在可支持的CPU架构上编译为最佳硬件指令的矢量计算，以实现优于等效标量计算的性能。
393: 孵化阶段的外部存储器访问API，允许Java程序安全的访问Java堆外的外部存储器（包括本地、持久化介质以及托管堆存储器）。
如上新特性前编号为JDK Enhancement Process的标识符，详见文末参考资料
立即尝鲜
浏览完17个新特性后，我都迫不及待的想尝试一下JDK 16，以及其中一些对工程上有所帮助的特性了。
那么先通过JDK官网进行JDK 16候选版下载。
由于要方便的在系统中针对多个JDK版本进行切换，可以使用jenv。我们把下载好的JDK16路径添加到jenv，在做如下设置即可使用。
jenv add ${JDK16_Path} jenv global openjdk64-16
如果一切顺利，那么查看JDK版本时，会有类似如下信息的返回。
java -version openjdk version "16" 2021-03-16 OpenJDK Runtime Environment (build 16+36-2231) OpenJDK 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)
如果你在使用较早的IDEA版本作为开发工具，那么使用JDK 16运行程序时，可能收到如下的错误：
Cannot determine path to 'tools.jar' library for 16 (path/to/jdk-16) when running from IDEA, you should update to the latest version.这是由于JDK9对Java运行时做了重构，已删除了rt.jar、tools.jar、dt.jar以及其它各种内部JAR包。而在较早的开发工具通常对这类JAR包有依赖，通过升级IDEA可以解决。
到官网获取一个IDEA 2021.1 EAP预发版本来提前体验（也可以等待2021.3的正式版本）。
新特性解读
▐ 迁移到GitHub
早在2020年9月，OpenJDK已将Github上的jdk仓库作为JDK 16源码的主读取/写入仓库。随着JDK 16的正式发布，这将是OpenJDK在Github上开发完成的初代JDK版本。
而促使将OpenJDK源代码仓库从Mercurial迁移到Git的三个主要原因：版本控制系统元数据，可用工具和可用托管的大小。
- 版本控制元数据大小方面，转换后的存储库的初始原型已显示出版本控制元数据的大小显着减少。例如，使用Git的jdk仓库的.git目录大约为300MB，而使用Mercurial的.hg目录大约为1.2GB。减少元数据可保留本地磁盘空间并减少克隆时间，同时减少传输的数据。
- 可用工具方面，与Mercurial相比，Git可用的工具更多。所有的文本编辑器都可以本地或通过插件实现Git集成。此外，几乎所有的IDE都带有Git集成，包括Eclipse、Visual Studio、IDEA。
- 可用托管方面，有许多选项可用于托管Git仓库，无论是自托管还是作为服务托管。使用外部源码托管提供程序的原因包括性能、与开发人员进行交互的Web API的访问权限控制 以及 蓬勃发展的社区。
OpenJDK迁移到Github之后，对于Java开发者而言还是有不少的便利：
- 通过fork一份JDK 16源码仓库，可以一边阅读源代码，一边做笔记并提交，方便持续学习JDK源码。使用Git的
upsteam保持JDK源码的更新，同时也保持自我更新。 - 如网速够快，通过Github在线阅读代码的工具Github1s，快速在浏览器中翻阅JDK 16源码也是非常方便。
如果是在IDEA下工作与学习，clone好JDK 16源码，
打开Project Structure (command+;)，设置Project SDK为JDK 16，并设置Project language level到16。
之后就可以愉快的看JDK 16源码了。
▐ 将JDK移植到Alpine Linux
在云原生时代，个人理解提升效率是第一原则：
- 更小的镜像体积分发时会更加迅速
- 应用程序/容器的启动要迅速
这样就能保障系统水平伸缩够快、问题出现时回滚处理够快。
另外，出于降低成本考虑，更小的镜像体积内存占用会更小，分发时耗用的资源也更小。
Alpine Linux就是与云原生的提升效率原则契合的一款独立的非商业性的通用Linux发行版。
其关注于安全性、简单性和资源效率，围绕musl libc和busybox构建。这使得它比传统的GNU/Linux发行版更小。
JDK移植到Alpine Linux后，将允许Tomcat、Jetty、Spring和其它流行的框架在其中工作。用户可以创建一个更小的镜像，以启动、运行特定的应用程序。
提前准备好Docker，我们先构建一个Alpine Linux镜像，然后添加JDK 16，最后运行一个简单的Spring Boot程序来演示一下。
▐ 构建Alpine Linux镜像
# 获取Alpine Linux镜像 docker pull alpine # 运行镜像 docker run alpine echo 'Hello Alpine!'
通过docker images命令查看镜像大小会发现，alpine在截止本文完成时，镜像大小仅仅只有5.6MB。相对于debian、ubuntu、centos等系统动则几十甚至上百MB的镜像来说，alpine可是真的小！
REPOSITORY TAG IMAGE ID CREATED SIZE alpine latest 7731472c3f2a 7 weeks ago 5.61MB
▐ 添加JDK 16
OpenJDK通过使用jlink（JEP 282）来减少Java运行时的大小，我们可以从DockerHub上获取镜像：16-jdk-alpine。或者如下Docker命令：
docker pull openjdk:16-jdk-alpine
▐ 运行Spring Boot
先准备一个Spring Boot的FatJar程序，可以从Spring Boot官网获取Hello World！样例程序。
创建一份Dockerfile，使用openjdk:16-jdk-alpine，并添加Spring Boot程序。
FROM openjdk:16-jdk-alpine VOLUME /tmp ARG JAR_FILE ADD ${JAR_FILE} app.jar ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
▐ 构建并运行
# 构建镜像，设置JAR_FILE参数指向Spring Boot程序Jar包路径 docker build --build-arg JAR_FILE=target/rest-service-0.0.1-SNAPSHOT.jar -t alpine-jdk16-app:latest . # 查看镜像 docker images # 根据镜像，启动容器运行 # -d参数 后台运行 # -p参数 Spring Boot默认端口8080，映射到容器端口8080 docker run -d -p 8080:8080 alpine-jdk16-app:latest # 查看容器运行 docker ps # 验证成功之后可以停止容器 docker stop ${CONTAINER_ID} # 访问应用 curl -w '\n' http://127.0.0.1:8080/greeting?name=jdk16
至此，通过Alpine Linux系统带JDK 16运行时的Spring Boot已经启动并可以正常的访问了。
Alpine系统JDK 16镜像大小约为321MB。相比Oracle官方的Linux版本镜像的467MB，减少30%+。
记录类
从JDK 14开始提供了Record记录类的预览特性，这一特性将成为JDK 16的一项永久性特性。Record记录类作为不可变数据的透明载体，其是为了回应有关Java过于冗长拘谨的抱怨。此计划的目标包括设计一个表示简单值集合的面向对象的构造函数，帮助开发人员专注于对不可变数据的建模而不是扩展行为，自动实现数据驱动的方法（例如 equals() 和 属性的访问器）。
通过较新版IDEA可以创建此类型：
声明Record记录类后，几乎不需要添加额外的代码，一组隐式声明让其代码书写很简洁：
- 隐式声明了属性
- 隐式声明了构造器
- 隐式声明了equals()、hashCode()、toString()
- 隐式声明了属性的访问器，访问器名称与属性同名
public record Point(int x, int y) {}
Record记录类支持Local Classes特性，那么当需要临时使用Record的时候，就可以非常方便的定义与使用：
List<Merchant> findTopMerchants(List<Merchant> merchants, int month) { // Local record record MerchantSales(Merchant merchant, double sales) {} // 使用MerchantSales Record类临时包装merchant和sales，方便做处理。 return merchants.stream() .map(merchant -> new MerchantSales(merchant, computeSales(merchant, month))) .sorted((m1, m2) -> Double.compare(m2.sales(), m1.sales())) .map(MerchantSales::merchant) .collect(toList()); }
Record记录类将可以代替Tuple、Pair等之前在JDK之外的工具库提供的元组功能，在与下面将介绍的模式匹配特性配合，可使代码将变得非常简洁。
▐ 模式匹配
从JDK 14开始引入了一种模式匹配的预览特性，这一特性也将成为JDK 16的一项永久性特性。因此虽然JDK 16是个短期版本，也不妨碍我们在未来的JDK版本中继续使用模式匹配特性。
模式匹配的现阶段仅限于一种模式（类型模式）和一种语言构造（instanceof），但这只是完整特性的一部分。即便如此，我们也已经获得了一个显著的好处：冗余的强制转换消失了，消除了冗余的代码，使更重要的代码得到了更清晰的关注，同时消除了隐藏bug的地方。
举个例子：
我们在开发中当需要解析对象会用到类似如下的方式
if (obj instanceof String) { String s = (String) obj; ... }
使用模式匹配后的等价代码：
if (obj instanceof String s) { // 通过使用模式匹配可以直接使用s局部变量 ... }
代码看起来是不是整洁了许多。
使用instanceof获取对象类型是一种条件提取形式，在获得到对象类型之后，总是要将对象强制转换为该类型。
以前在instanceof之后必须进行显式类型转换，这是一种繁琐的操作，而融合这些操作的好处不仅仅是为了简洁，它还消除了一个常见的错误来源：在剪切和粘贴instanceof及强制转换代码，容易在修改了 instanceof的类型之后忘记修改强制转换类型，这就给了漏洞一个藏身之处。通过instanceof的模式匹配消除了这个问题，我们还可以消灭所有这种类型的bug。
另一个需要经常的做此类“先检测后强制转换”的地方是equals方法。
再来看一个例子：
public boolean equals(Object o) { if (!(o instanceof Point)) return false; Point other = (Point) o; return x == other.x && y == other.y; }
使用模式匹配后的等价代码：
public boolean equals(Object o) { return (o instanceof Point other) && x == other.x && y == other.y; }
这段代码起到同样的效果，但更简单直接，因为我们可以只使用一个复合布尔表达式来表达一个等价的条件，而不是使用控制流语句。
模式匹配的绑定变量（如上代码例子中 obj instanceof String s 的s就是一个绑定变量）除了特殊的声明位置以外，其作用域也与"普通"局部变量有所不同。
比如我们可以这样写：
if (a instanceof Point p) { // p is in scope ... } else { // p not in scope here } // p not in scope here if (b instanceof Point p) { // Sure! ... }
这样特殊的作用域让我们能够在if-else的多分支情况下，自由的重新声明绑定变量，也考虑未来在switch中的case也是如此便利。如：
if (x instanceof Integer num) { ... } else if (x instanceof Long num) { ... } else if (x instanceof Double num) { ... }
如果模式匹配可以消除Java代码中99%的强制类型转换操作，那么它肯定会很流行。但还不仅限于此，随着时间的推移，将会出现其他类型的模式，它们可以进行更复杂的条件提取，使用更复杂的方式来组合模式，以及提供其他可以使用模式的构造：比如switch，甚至是catch，再加上目前已永久支持的Record类以及在预览中的密封类等相关特性，模式匹配未来一定能够大大简化我们编写的代码。
尾声
本文从JDK 16版本所带来的17个新特性中抽取对工程工作和学习比较有帮助的几个特性展开解读，快速了解了这些特性。
大部分的企业或者项目还在使用JDK 8（其依然占据JDK市场的80%，绝对的主流），
源于JDK 8的超豪华新特性，如函数式接口、Lambda表达式、方法引用 / 构造器引用、更强的Steam API、接口的增强、Optional、JVM中Metaspace取代PermGen空间等等。
我们也能够看到Java为了跟上当下技术更迭的快节奏，不断的推陈出新。
从JDK 9开始，Java版本的发布改为每6个月一次，JDK 11是长期支持版本以及下半年将发布的JDK 17。
JDK 9~JDK15也不乏一些重要的新特性，如
- JDK 9 模块系统、JShell交互式命令行
- JDK 10 局部变量类型推断
- JDK 11 ZGC试用、HTTP Client API、Steam等增强
- JDK 12 switch表达式扩展、增加基于JMH的一套微基准套件
- JDK 13 Socket API 重构、文本块（多行文本）
- JDK 14 更有价值的NPE错误信息、JDK 16特性的部分预览
- JDK 15 密封类、Record类等JDK 16特性的预览
希望这种快速版本迭代的策略能够让Java保持持续的活力，能够让开发者使用的更高效、更健壮！
