JDK 16 昨日正式发布，新特性实践尝鲜来啦！

▐  其他的新特性

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候选版下载（http://jdk.java.net/16/）。

由于要方便的在系统中针对多个JDK版本进行切换，可以使用jenv（https://github.com/jenv/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预发版本

（https://www.jetbrains.com/zh-cn/idea/nextversion/）来提前体验（也可以等待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源码仓库（https://github.com/openjdk/jdk），可以一边阅读源代码，一边做笔记并提交，方便持续学习JDK源码。使用Git的upsteam保持JDK源码的更新，同时也保持自我更新。

• 如网速够快，通过Github在线阅读代码的工具Github1s（https://github.com/conwnet/github1s），快速在浏览器中翻阅JDK 16源码（https://github1s.com/openjdk/jdk/releases/tag/jdk-16%2B35）也是非常方便。

如果是在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：https://openjdk.java.net/jeps/282）来减少Java运行时的大小，我们可以从DockerHub上获取镜像：

16-jdk-alpine（https://hub.docker.com/_/openjdk?tab=tags&page=1&name=16-jdk-alpine&ordering=last_updated）。

或者如下Docker命令：

docker pull openjdk:16-jdk-alpine

▐  运行Spring Boot

先准备一个Spring Boot的FatJar程序，可以从Spring Boot官网获取Hello World！样例程序（https://spring.io/guides/gs/rest-service/）。

创建一份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-argJAR_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-p8080: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的时候，就可以非常方便的定义与使用：

ListfindTopMerchants(List 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 instanceofString) {

String s = (String) obj;

…

}

使用模式匹配后的等价代码：

if (obj instanceofString s) {

// 通过使用模式匹配可以直接使用s局部变量

…

}

代码看起来是不是整洁了许多。

使用instanceof获取对象类型是一种条件提取形式，在获得到对象类型之后，总是要将对象强制转换为该类型。

以前在instanceof之后必须进行显式类型转换，这是一种繁琐的操作，而融合这些操作的好处不仅仅是为了简洁，它还消除了一个常见的错误来源：在剪切和粘贴instanceof及强制转换代码，容易在修改了 instanceof的类型之后忘记修改强制转换类型，这就给了漏洞一个藏身之处。通过instanceof的模式匹配消除了这个问题，我们还可以消灭所有这种类型的bug。

另一个需要经常的做此类“先检测后强制转换”的地方是equals方法。

再来看一个例子：

publicbooleanequals(Object o) {

if (!(o instanceof Point))

returnfalse;

Point other = (Point) o;

return x == other.x && y == other.y;

}

使用模式匹配后的等价代码：

publicbooleanequals(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!

…

最后

一次偶然，从朋友那里得到一份“java高分面试指南”，里面涵盖了25个分类的面试题以及详细的解析：JavaOOP、Java集合/泛型、Java中的IO与NIO、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、数据结构、算法、Elasticsearch 、Kafka 、微服务、Linux。

这不，马上就要到招聘季了，很多朋友又开始准备“金三银四”的春招啦，那我想这份“java高分面试指南”应该起到不小的作用，所以今天想给大家分享一下。

请注意：关于这份“java高分面试指南”，每一个方向专题（25个）的题目这里几乎都会列举，在不看答案的情况下，大家可以自行测试一下水平 且由于篇幅原因，这边无法展示所有完整的答案解析
f Point p) {

// p is in scope

…

} else {

// p not in scope here

}

// p not in scope here

if (b instanceof Point p) { // Sure!

…

最后

一次偶然，从朋友那里得到一份“java高分面试指南”，里面涵盖了25个分类的面试题以及详细的解析：JavaOOP、Java集合/泛型、Java中的IO与NIO、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、数据结构、算法、Elasticsearch 、Kafka 、微服务、Linux。

这不，马上就要到招聘季了，很多朋友又开始准备“金三银四”的春招啦，那我想这份“java高分面试指南”应该起到不小的作用，所以今天想给大家分享一下。

[外链图片转存中…(img-da5wBZ0N-1718543532580)]

请注意：关于这份“java高分面试指南”，每一个方向专题（25个）的题目这里几乎都会列举，在不看答案的情况下，大家可以自行测试一下水平 且由于篇幅原因，这边无法展示所有完整的答案解析