破解“一人用Java全员大买单”：版本任你发，我用java8

说在前面

在40岁老架构师 尼恩的读者社区(50+)中，最近有小伙伴拿到了一线互联网企业如美团、拼多多、极兔、有赞、希音的面试资格，遇到一几个很重要的面试题：

• 你们用什么版本的jdk？
• 为啥你们还在用java8？
• 聊一聊不同版本的jdk的新特性？
• Oracle JDK 和 OpenJDK 的对比
• ……

这里尼恩给大家做一下系统化、体系化的梳理，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。

也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典》V87版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

《尼恩 架构笔记》《尼恩高并发三部曲 》《尼恩Java面试宝典》 的PDF文件，请到公号【技术自由圈】获取

Oracle的JAVA收费新规则：一人使用全员买单

2023年1 月 23 日，甲骨文公司公布名为《 Oracle Java SE Universal Subscription Global Price List 》的文件，对 Java SE 制定了新的收费标准。

Oracle表示，全新的Java SE收费标准将基于企业员工的总数进行收费，

注意，是员工总数，而不是企业中使用Java的开发人员数量。

简单来说就是：1人使用，全员买单。

文件中，甲骨文公司在新发布订阅文件中将 Java SE 收费标准划分为 8 个不同档位：

• 总员工数量 1-999：$15 /人/月
• 总员工数量 1000-2999：$12 /人/月
• 总员工数量 3000-9999：$10.5 /人/月
• 总员工数量 10000-19999：$8.25 /人/月
• 总员工数量 20000-29999：$6.75 /人/月
• 总员工数量 30000-39999：$5.70 /人/月
• 总员工数量 40000-49999：$5.25 /人/月
• 总员工数量 50000+：没有给出具体定价，需要详询甲骨文。

按照文件 估计，我们假设有一家公司，员工总数为 500 人（包括全职和兼职员工以及代理、顾问和承包商），

在500 人中有 20 个 Java 开发人员。

按照旧模式的收费标准，每年将被收取 20 X 25 X 12 = 6000 美元（旧版本付费按 25 美元/月来举例）；

按照新模式的收费标准，每年将被收取 500 X 15 X 12 = 90000 美元。

由此可见，一个 在500 人的公司每年在 Java SE 上的支付成本将上升 15 倍。

简单推算，一个5W人的公司，假设还是20 个 Java 开发人员， 每年提升 1500倍， 费用要到 900W 美元，5000千多人民币。

像阿里、华为这种员工人数在20W人以上的公司， 每年要给Oracle 纳贡 2个亿以上。

更要命的是，那种规模庞大、人数众多的外包公司，也是需要大量纳贡的。外包公司本来利润微薄，这次全部要给 Oracle 纳贡了。

据估算，全球约有 150 亿台设备在运行 Java™。约900万 Java 程序员… 看起来，oracle 可以狠狠的撸一波了。

JDK各大版本的收费情况

打开 oracle jdk的 下载链接，尼恩给大家 展示一下，各大 JDK 版本的收费情况

Java Archive | Oracle

一个小小的例外情况：oracle 官方 曾经发过通知，说JDK17可以免费商用，但是那是有时间限制的，时间截止到2024年9月，共计3年。

这其实又是一个坑，为啥？如果 用了JDK17，就可能回不去了

所以，尼恩这里把JDK17 归类为 潜在收费版本，最终还是要费用的，所以，JDK17其实还是 收费版本。

最后的晚餐：jdk-8u202 免费版本

从图中可以看到，Java8及之前的版本都是免费， jdk-8u202所有jdk中最后一个免费的版本，jdk-8u202就是最后的晚餐。

那是不是我们就下载jdk-8u202呢？并不是，而是他的前一个版本，也就是jdk-8u201。

这就是另一个知识要点。这也是 jdk版本的一个小常识

• Java SE 重要补丁更新 (CPU) 包含安全漏洞修复和重要漏洞修复。Java SE CPU 版本号采用奇数编号。
• Java SE 补丁集更新 (PSU) 包含相应 CPU 中的所有修复以及其他非重要修复。

Java SE CPU 版本号采用奇数编号。反过来说：奇数编号版本，包含了安全漏洞修复和重要漏洞修复。

并且，Oracle 官方也是强烈建议所有 Java SE 用户及时升级到最新的 CPU 版本。

换句话说，oracle官方推荐大家下载奇数编号的版本。

所以说，jdk-8u202之前的那个版本，也就是jdk-8u201是“天选之子”，

所以说，jdk-8u201天选打工人的最爱

天选之子的地址如下：

Java Archive Downloads - Java SE 8 (oracle.com)

jdk-8u202之后的版本，到底谁来收钱？

jdk-8u202之后的版本是收费版本，但是也没有支付链接，大家从官方也能下载的，不用付款也能安装的。

安装完了之后，大家直接用，也是没人来收钱的。

于是，大家对收费版本有一种误解：不用白不用，反正没人管。

尼恩只能说：呵呵。用吧。

如果大胆一点，甚至可以像 Google一样， 敞开了用。

要知道，世界级大厂 Google也就是不付钱，直接 敞开了 用 jdk。

没有过多久，最后收到的 法院一张超级大传票：“因为在Android中用了Java，Oracle向Google索赔88亿美元”

所以，大家 如果 敞开了用JDK收费版本，就得要像Google一样，有着雄厚的家底，最好就想google一样：有 超过88亿美元的雄厚家底。然后，等着法院的超级大传票.

如果没有超过88亿美元的雄厚家底，那就最好 不敞着用哈。

其实，除了JDK收费版本，到国外一些大公司的软件都能下载安装使用，比如IBM、Oracle都可以在官网上下载，

正常情况下，是要购买他们的lisence的，一般是按用户量收费或者按CPU核数收费。

那么，为什么他们没有来找你，两个原因：

• 第一，养猪要养肥后才杀，公司大了，肥了就有人联系你了；
• 第二, 打这种跨国官司也有成本的。如果 收费还不够 官司的成本，他们也不急于 收钱。

版本任你发，我用java8

从1996年初JDK1.0发布到现在已经二十多年了， Oracle的版本发布已经形成了一个规律：

• Oracle 每隔6个月就会有一个短期维护版本(non-LTS)发布出来；
• 然后每隔2年，就会发布一款得到8年长期支持维护（LTS）的JDK版本，

所谓LTS版本就是可以得到至少八年产品支持的版本。

到目前为止，有四个LTS版本，JDK 7、JDK 8、JDK 11、JDK 17，下一个LTS版本是JDK 21。

最新一个版本已经到 JDK 20，JDK17是最新的一个LTS(Long-Term Support)版本。

“版本任你发，我用java8”

虽然 JDK 疯狂升级，但是java社区一直都是 “版本任你发，我用java8”，

不管哪个版本发出来，很少有人愿意升级，不升级的原因，就是大家有两个大的担忧：

• 第一个大担忧：收费的 达摩克斯之剑
• 第二个大担忧：使用新版本 容易踩坑

那么，通过市场调查，来具体看看，大家的Jdk版本如何选择?

JDK的版本首选LTS版本。 根据调查，各个jdk LTS 版本的近三年的使用情况如下图：

jdk LTS版本增长情况

从这份结果可以看出，很多公司要么用了openjdk，如果是盲目用Oracle JDK新版本的，就慢慢被养成一条被宰的肥猪了。

2023年 ， 56%的公司使用Java11 ， 呵呵，这些公司估计得找 oracle 缴费了。如果没有缴费，并且有只要一个服务器使用了oracle jdk11，将来的某一天，就等着oracle公司发过来的巨大额度的收费清单吧

另外 %9 的公司，使用了Java17， 这些公司在时间截止到2024年9月，共计3年，是免费的。从明年开始，如果没有主动缴费，并且有只要一个服务器使用了oracle jdk17， 呵呵，将来的某一天，同样就等着oracle公司发过来的巨大额度的收费清单吧

用openjdk 固然能避免收费，但是用了就回不去了。

尼恩通过后面的分析给大家证明：

jdk新版本的250个特性的性能提升，指标不治本、外层挠痒痒， 根本没啥用。升了还不如别升，jdk8更稳定。

著名中间件如spring依赖jdk17

虽然企业不能轻易升级，但是oracle 有很多 好队友，小跟班，他们带节奏，跟着升，怎么办？

这些oracle小跟班，就是各大开源软件厂商

不知道这些oracle小跟班，是不是收到oracle的投资，总之就是，现在各开源软件前后呼应的追赶Jdk新版本，也正在全面拥抱jdk17.

另外，spring6 和springboot3 相继推出直接要求最低依赖是jdk17，spring 和springboot的版本升级强制要求JDK版本升级17。

如果某些中间件，一定要用java 17， 然后咱们主要的java版本，是java8 或者java11，怎么办？

• 使用对于的免费版本，也就是OpenJDK版本， 能用阿里的就阿里的，不行就是Oracle的OpenJDK
• 使用容器的方式，容器里边用免费的OpenJDK版本

比如 ，尼恩在讲 云原生架构的时候， 发现 Jenkins 就是依赖了 jdk11，导致尼恩作为一个Java8的铁杆用户，最终只能通过 容器的方案绕过安装 Java11，去通过容器安装Jenkins。

免费的OpenJDK

虽然 Oracle JDK 是Java官方Oracle公司基于OpenJDK构建，收费。

除了官方的Oracle JDK，大家可以使用 开源的 OpenJDK。这个是免费的。

如何选择免费的OpenJDK

要注意的是，要关注第 三方openJDK的稳定性及可用度。

一般来说，建议使用经历过大规模生产历练、 长时间稳定运行、有强大的技术团队支撑的版本。

比如 建议是 阿里的 Dragonwell JDK。

只是， 阿里的 Dragonwell JDK只适配 Java 8 和 Java 11， 没有其他的JDK 版本的适配。

主要的开源 OpenJDK 版本

接下来，看看主要的开源 OpenJDK 版本：

1.OpenJDK

OpenJDK 是 JDK 的社区版，社区主要由Oracle主导，免费。

OpenJDK

Java的开源版本OpenJDK，OpenJDK目前由Oracle主导，汇聚了社区的力量进行开发，IBM，红帽等企业都有参与。

使用Oracle的openJDK，需要及时跟进版本更新，可能需要比较高的开发迁移能力。

另外，可以使用第三方发布的openJDK，不过，取决于三方openJDK的稳定性及可用度。

2.阿里巴巴Dragonwell JDK

Alibaba Dragonwell 是阿里巴巴公司基于OpenJDK的构建，免费。

Dragonwell-Java 开发工具包 (OpenJDK) - 阿里云 (aliyun.com)

3.腾讯Kona JDK

腾讯 Kona(Tencent Kona) 是腾讯公司基于OpenJDK的构建，免费。

腾讯开源的TencentKona 8是腾讯基于OpenJDK的一个免费的、生产级别的开源产品。Kona是腾讯内部默认JDK，针对超大规模的大数据、机器学习以及云计算环境做了特别的优化。

4.华为毕昇JDK

华为毕昇JDK 是华为公司基于OpenJDK的构建，免费

5.Eclipse Temurin

Eclipse Temurin(曾用名：AdoptOpenJDK) 是Eclipse基金会基于OpenJDK的构建，支持Oracle公司的HotSpot虚拟机和Eclipse基金会的OpenJ9虚拟机，免费。

6.Azul Zulu OpenJDK

Azul Zulu OpenJDK 是总部位于加州桑尼维尔的Azul公司基于OpenJDK的构建，免费。

7.SAP SapMachine

SAP SapMachine 是OpenJDK 项目的贡献者之一SAP公司基于OpenJDK的构建，免费。

8.Red Hat build of OpenJDK

Red Hat build of OpenJDK 是Red Hat(红帽子)公司基于OpenJDK的构建，免费。

9.Microsoft Build of OpenJDK

Microsoft Build of OpenJDK 是微软公司基于OpenJDK的构建，免费。

java 性能不高的核心原因

java 性能不高的原因很多，非常非常多， 很多人通过博客的形式，从不同的维度进行各种分析

但是尼恩在这里，浓缩再浓缩，归纳再归纳，

本质上java 性能不高的核心原因， 有两个本质的架构缺陷，具体如下

• 核心原因之一：一对一线程架构缺陷
• 核心原因之二：二元运行架构缺陷

一个一个来看吧。

核心原因之一：一对一线程架构缺陷

用户线程和内核线程一对一绑定，导致多线程场景 用户态和内核态频繁切换。

和Java相比，GO的线程架构就优越得多， 去掉了 用户线程和内核线程一对一绑定。

GO的业务线程的切换以及线程操作，发生在用户态，所以不需要系统调用，省去了大量的 系统调用开销和 用户态和内核态频繁切换开销。

核心原因之二：二元运行架构缺陷

为了跨平台，Java的执行架构进行了彻底的解耦，将一元的二进制程序，解耦为二元运行架构，包括一份 JVM程序 和 一份二进制业务程序。

Java 将执行 字节码程序的程序进行独立，独立为 JVM。

并且，不同的操作系统，Java提供不同的JVM实现版本，通过这种变JVM不变业务字节码的方式，实现跨平台。

不同的平台， 使用同一份 字节码业务程序，从而 实现： 一次编译，到处运行，最终完成 业务代码的跨平台执行。

Java二元的运行架构，实现了：跨平台执行。然而，任何事情都是双面的， Java二元的运行架构的有一个大的缺陷：运行速度慢、启动速度慢。

**运行速度慢的根本原因：**主要是字节码还不是机器码，字节码需要解释执行。

那么，JVM如何提升运行速度呢？通过进行热点字节码编译成为 二进制机器码的方式，进行不断的优化进行不断的性能提升，运行的速度也有质的飞越。运行速度慢慢慢得到了解决

但是，启动速度慢是一个巨大的硬伤，没法解决。Java 的JVM字节码执行程序和 业务程序 分离之后 ，启动的时候，需要把大量的 字节码文件，加载在内存， 然后进行解释执行，或者 预编译执行。Java中单个类的字节码文件的 加载过程，需要进行大量的 安全校验、 符号解析、初始化等工作，是非常耗时间的。一个Java应用可能涉及成百上千的Java类，这就是一个很长的时间周期。

在线上我们常常发现， 一个springboot应用的启动过程要 10s，甚至30s，这是一段非常长的时间周期。

和Java相比，GO不存在Java的这个问题，GO的一元运行架构。

GO的跨平台方式是跨平台编译， 不同平台，编译出一份不同的 可执行文件。GO程序在执行的时候，不存在 Java的那种单个类文件的 加载过程， 哪怕成百上千的GO结构体，也是很短的时间内实现启动。

这使得在Golang中，程序的启动速度非常快，可以在数十毫秒内启动一个应用程序。

jdk的迭代之路，并没有治本

接着，我们来简单看下，从jdk9到jdk17都有哪些新特性。

从 JDK 诞生到现在，其长期支持的版本主要有 JDK 7、JDK 8 、JDK 11以及 JDK 17，JDK 17 将是继 Java 8 以来最重要的LTS版本，是 Java 社区八年努力的成果。

首先，我们看下jdk 8 到jdk 19各版本新增特性的数量如下：

jdk各版本新特性

从上图可以看到从 Java 8 到 Java 19 总共引入了超过 250 个新特性，其中 Java 9 中包含了 91 个新特性，这是由于之前的发布周期较长所导致的，在应用新的发布模型后，各版本的新增特性数量都维持在 10 个左右的水平。

后面的内容，尼恩给大家列了250 个新特性。

虽然新特性足够多，但是这些特性都是指标不治本，没有解决 本质上java 性能不高的核心原因， 就是没有解决这两个本质的架构缺陷：

• 核心原因之一：一对一线程架构缺陷
• 核心原因之二：二元运行架构缺陷

Java当然想解决这个两个架构缺陷，但是这两个问题都是JVM里边核心的核心， 牵一发而动全身的架构。

总之，不论他们是没有魄力、或者他们是没有耐心，总之就是没有解决。所以，java的版本升级，就是指标不治本， 没有质的飞跃。

既然如此，与其用新版本导致后面被oracle 巨额收费，还不如用java 8。

3高场景Java8应用如何降本增效

Java由于其最早的开放性， 造就了他的 最为活跃的 开源社区， 最为全面的开源生态。

用Java开发的应用，如果 从1qps 一路成长，如果平滑升级到 1亿qps，而不去换语言的话，那么java是最佳选择，为什么？ 很简单，java生态体系中的工具链、中间件是最全的、最完善的。

但是，使用java的劣势是：单体服务性能低，比较耗费资源，如果要提供其他高性能语言一样的能力，Java需要做大量的横向扩展。

尼恩的《golang 学习圣经》里有一组实验数据：

• 尼恩通过springcloud gateway 和 golang Bff的对比测试，java 性能弱8倍。
• 尼恩也通过 dubbo rpc 和 dubbo-go RPC 的对比测试， java 性能弱8倍。

也就是说，要提供golang 一样的能力，简单的测算，Java要提供 8倍的服务器资源。

3高场景Java应用如何降本增效？很简单，就是取长补短，借助其他语言提升性能。

• 没有go之前，在京东的架构中，大量的使用了Nginx lua， 也就是说，京东是 Java + Nginx lua 相结合的架构。
• 有了go之后，如果京东的重来，一定是大量的使用了go， 也就是说如果重来，京东一是 Java + go 相结合的架构。

为啥这么说？

现在很多的互联网公司，已经是 java +go 结合的架构：

• 3高+简单业务场景，用go提升性能
• 低并发场景或者负责业务场景， 仍然使用java

所以，结论是：

说一千道一万，目前的技术选择还是死守Java 8 。利用 golang 补齐Java的性能短板。

毕竟java 8 是那么的稳定，那么的稳若磐石。

未来，Java +Go 架构将会越来越普遍，主要的原因有两个：

• go的学习成本低：具体可以参考尼恩的《go 学习圣经》，java高手一周可以掌握
• 结合起来，才是最大的降本增效：使用go是节省服务器成本，使用java 是节省造轮子成本

站在Java +Go 架构这个大的架构下，已经不依赖java的版本升带来大的性能飞越。

咱们之前的架构师 Java + Lua， 未来的架构 是 Java+ GO。Java的版本就是 8。

所以，不用担心Java版本怎么升级。Oracle 爱怎么升级，就让他升级去吧。

附录：从jdk9到jdk20（2023年3月）的升级过程

jdk9（2017年9月）

java 9 提供了超过 150 项新功能特性，包括备受期待的模块化系统、可交互的 REPL 工具：JShell，JDK 编译工具，Java 公共 API 和私有代码，以及安全增强、扩展提升、性能管理改善等。

可以说 Java 9 是一个庞大的系统工程，完全做了一个整体改变。

新特性主要有以下几个：

• jdk 和jre的改变
• Java平台模块系统
• Jshell集合、Stream 和 Optional
• 进程 API
• 平台日志 API 和 服务
• 反应式流 （ Reactive Streams ）
• 变量句柄
• 改进方法句柄（Method Handle）
• 并发
• Nashorn
• I/O 流新特性
• 改进应用安全性能
• 用户界面
• 统一 JVM 日志

重要特性：主要是API的优化，如支持HTTP2的Client API、JVM采用G1为默认垃圾收集器。

jdk 和jre的改变

在jdk SE 9 之前，jdk构建系统用于生成两种类型的运行时映射-JRE(java运行时环境)和JDK(java开发工具包)。

JRE 是java SE 平台的完整实现，JDK包含了JRE 和开发工具和类库。

java SE 9 之前的JDK文件目录

jdk9之前的目录

目录说明：

• bin目录用于包含命令行开发和调试工具，如javac，jar和javadoc。它还用于包含Java命令来启动Java应用程序。
• include目录包含在编译本地代码时使用的C/C++头文件。
• lib目录包含JDK工具的几个JAR和其他类型的文件。它有一个tools.jar文件，其中包含javac编译器的Java类。
• jre\bin目录包含基本命令，如 Java 命令。在 Windows 平台上，它包含系统的运行时动态链接库（DLL）
• jre\lib目录包含用户可编辑的配置文件，如 .properties 和 .policy 文件。包含几个 JAR。rt.jar文件包含运行时的 Java 类和资源文件。

Java SE 9调整了JDK的目录层次结构如下图所示：

jdk9以后目录

最大的区别：从jdk9开始删除了JDK和JRE之间的区别，在jdk9中，没有名为jre的目录。

目录说明：

• bin目录包含所有命令。在Windows平台上，它继续包含系统的运行时动态链接库。
• conf目录包含用户可编辑的配置文件，例如以前位于jre\lib目录中的.properties和.policy文件。
• include目录包含要在以前编译本地代码时使用的C/C++头文件。它只存在于JDK中。
• jmods目录包含JMOD格式的平台模块。创建自定义运行时映像时需要它。它只存在于JDK中。
• legal 目录包含法律声明。
• lib目录包含非Windows平台上的动态链接本地库。其子目录和文件不应由开发人员直接编辑或使用。

访问资源的优化

在jdk9之前，可以从类路径上的任何JAR访问资源。在java代码中，资源由资源名称标识，资源名称是由斜线（/）分隔的一串字符串。对于存储在JAR中的资源，资源名称仅仅是存储在JAR中的文件的路径。

例如，存储在rt.jar中的java.lang包中的Object.class文件,它也是一个资源，其资源名称是java/lang/Object.class。

可以使用以下两个类中的方法来访问资源：

• java.lang.Class
• java.lang.ClassLoader

资源由ClassLoader定位。一个Class代理中的资源寻找方法到它的ClassLoader。

在两个类中有两种不同的命名实例方法：

（1）URL getResource(String name)

（2）InputStream getResourceAsStream(String name)

两种方法都会以相同的方式找到资源。它们的差异仅在于返回类型。第一个方法返回一个URL，而第二个方法返回一个InputStream。第二种方法相当于调用第一种方法，然后在返回的URL对象上调用openStream()。

ClassLoader类包含三个额外的查找资源的静态方法：

//(1)返回找到的第一个资源的URL
static URL getSystemResource(String name); 
//(2)返回找到的第一个资源的InputStream
static InputStream getSystemResourceAsStream(String name)
//(3)返回使用指定的资源名称找到的所有资源的URL枚举
static Enumeration<URL> getSystemResources(String name)

在考虑使用哪一种方式获取资源之前，先要弄清楚获取的资源是哪一种资源。

资源可以分为两种类型，如下：

• 系统资源：系统资源是在bootstrap类路径，扩展目录中的JAR和应用程序类路径中找到的资源。
• 非系统资源：可以存储在除路径之外的位置，例如在特定目录，网络上或数据库中。

getSystemResource()方法使用应用程序类加载程序找到一个资源，委托给它的父类，它是扩展类加载器，扩展类加载器又委托给它的父类（引导类加载器）。

如果你的应用程序是独立的应用程序，并且它只使用三个内置的JDK类加载器，getSystemResource*() 的静态方法是最佳选择。它将在类路径中找到所有资源，包括运行时映像中的资源，如rt.jar文件。

如果你的应用程序是在浏览器中运行的小程序，或在应用程序服务器和Web服务器中运行的企业应用程序，则应使用getResource()，它可以使用特定的类加载器来查找资源。

从jdk9开始，类和资源封装在模块中。

在第一次尝试中，JDK 9设计人员强制执行模块封装规则，模块中的资源必须对该模块是私有的，因此它们只能在该模块内的代码中访问。虽然这个规则在理论上看起来很好，但是对于跨模块共享资源的框架和加载的类文件作为来自其他模块的资源，就会带来问题。为了有限地访问模块中的资源，做了一些妥协，但是仍然强制执行模块的封装。

JDK 9包含三类资源查找方法：

java.lang.Class
java.lang.ClassLoader
java.lang.Module

Class和ClassLoader类没新增任何新的方法。

Module类包含一个getResourceAsStream(String name)方法，如果找到该资源，返回一个InputStream；否则返回null。

模块化

java从1995年发布，到现在java已经发展了快30年，但是java与相关生态在不断丰富的同时也暴露除了很多问题：

• java运行环境的膨胀与臃肿。在JVM启动的时候，至少会有30～60MB的内存加载，主要原因是JVM需要加载rt.jar，不管其中的类是否被classloader加载，第一步整个jar都会被JVM加载到内存中。
• 代码库越来越大，创建复杂。盘根错节的意大利面条式代码的几率呈指数级的增长。不同版本的 类库交叉依赖导致让人头疼的问题，这些都阻碍了 Java 开发和运行效率的提升。
• 每一个公共类都可以被类路径之下任何其它的公共类所访问到，这样就会导致无意中使用了并不想被公开访问的 API。
• 类路径本身也存在问题：无法知晓所需要的JAR是否是全都存在还是部分存在。

受兼容性、代码库庞大等问题的掣肘，想要对java进行大刀阔斧的革新是越来越困难，

Jigsaw 从 Java 7 阶段就开始筹备，Java 8 阶段进行了大量工作，最终在 Java 9 里落地，有一种千呼万唤始出来的意味。

提示：

Jigsaw 的中文直译为：

拼图; 线锯; 拼板玩具; 钢丝锯; 谜团; 镂花锯; 神秘莫测的事物(或状况);

Jigsaw是OpenJDK项目下的一个子项目，旨在为Java SE平台设计、实现一个标准的模块系统，并应用到该平台和JDK中。该项目由Java编程语言编译器小组赞助。

提及 Java 9，最大的功能莫过于 Jigsaw 项目下的核心 Java 平台模块化系统（JPMS，Java Platform Module System) 。Jigsaw 本身是一项很有野心的项目，它的目标是改进 Java SE 平台，使其可以适应不同大小的计算设备；改进其安全性，可维护性，提高性能；简化各种类库和大型应用的开发和维护，包括 JDK 本身的模块化。

JPMS（Java Platform Module System）是Java 9发行版的核心亮点。JPMS似于OSGI框架的功能，模块之间存在相互的依赖关系，可以导出一个公共的API，并且隐藏实现的细节。

JPMS包括为编写模块化应用程序提供支持，以及将JDK源代码模块化。JDK 9 附带了大约 92 个模块（在 GA 版本中可以进行更改）。其中JSR 376 Java 平台模块化系统（JPMS，Java Platform Module System）作为 Jigsaw 项目的核心，其主体部分被分解成 6 个 JEP（JDK Enhancement Proposals）。

Java 9 Module System有一个"java.base"模块，它被称为基本模块。它是一个独立的模块，不依赖于任何其他模块。默认情况下，所有其他模块都依赖于"java.base"。

在java模块化编程中，一个模块通常只是一个 jar 文件，在根目录下有一个文件module-info.class。

如果需要使用模块，请将 jar 文件包含到modulepath而不是classpath. 添加到类路径的模块化 jar 文件是普通的 jar 文件，module-info.class文件将被忽略。

典型的module-info.java 类如下：

module jdk9.client {
    requires jdk9.test;
}

其项目结构如下：

本质上将，模块其实就是package外再裹一层，用模块来管理各个package，通过声明某个 package 暴露，不声明默认就是隐藏。

因此，模块化使得代码组织上 更安全，因为它可以指定哪些部分可以暴露，哪些部分隐藏。

模块化（以 Java 平台模块系统的形式）将 JDK 分成一组模块，可以在编译时，运行时或者构建时进行组合。其实现目标如下：

• 主要目的在于减少内存的开销
• 只须必要模块，而非全部 JDK 模块，可 简化各种类库和大型应用的开发和维护
• 改进 Java SE 平台，使其可以 适应不同大小的计算设备
• 改进其安全性，可维护性，提高性能

Java发展到9之后，整个JDK的产品形态发生了一个很大的变化，从一个大的单体应用，作了一定的解耦，

模块化解耦之后，JMC、OpenJFX等以软件包的形式独立于JDK之外，Oracle也将其商业特性都开源了出来，所以Oracle JDK 9和OpenJDK 9仅存在License的不同。

JShell

Python 和 Scala 之类的语言早就有交互式编程环境 REPL（read - evaluate - print - loop），以交互式的方式对语句和表达式进行求值。

开发者只需要输入一些代码，就可以在编译前获得对程序的反馈。而 之前的 Java 版本要想执行代码，必须创建文件、声明类、提供测试方法方可实现。

Java 9 中终于拥有了 REPL 工具：JShell。利用 JShell 在没有创建类的情况下直接声明变量，计算表达式，执行语句。即开发时可以在命令行里直接运行 Java 的代码，而无需创建 Java 文件，无需跟人解释 public static void main(String[] args) 这句废话。

JShell 也可以从 文件中加载语句 或者将语句保存到文件中。

JShell 也可以是 Tab 键进行自动补全 和 自动添加分号。

语法糖

接口的私有方法

在jdk8中规定了接口中的方法除了抽象方法之外，还可以定义静态方法和默认的方法。在一定程度上，扩展了接口的功能，这个时候的接口更像一个抽象类。

在jdk9中，接口就更加的灵活和强大，连方法的访问权限修饰符都可以声明为 private 的了，此时方法将不会成为你对外暴露的 API 的一部分。

public interface Animal {
    //jdk 7 : 只能声明全局常量(public static final)和抽象方法(public abstract)
    void setAnimalName(String name);

    // jdk 8 : 声明静态方法 和 默认方法
    static void  setAge(int age){
        System.out.println("age =" + age);

    }
    default  void setColor(String color){
           getWeight();
        System.out.println("color =" + color);
    }

    //jdk9
   private  void  getWeight(){
       System.out.println("获取animal的体重");
   }
}

public class Dog implements  Animal{
    @Override
    public void setAnimalName(String name) {
        System.out.println("name = " + name);
    }
}

//测试单元
@Test
public  void DogNameTest(){
    Dog dog = new Dog();
    dog.setAnimalName("黑妞");
    dog.setColor("red");
}

执行结果如下：

<> 操作符使用升级

在jdk9之前，匿名实现类使用<>操作符会报错，如下：

在jdk9中使用可以正常编译通过：

try语句

在jdk8之前，我们习惯使用如下方式关闭资源：

public void readFile() throws FileNotFoundException {
    FileReader fr = null;
    BufferedReader br = null;
    try{
        fr = new FileReader("d:/input.txt");
        br = new BufferedReader(fr);
        String s = "";
        while((s = br.readLine()) != null){
            System.out.println(s);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }finally {
        try {
            br.close();
            fr.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

Java 8 中，可以实现资源的自动关闭，但是要求执行后必须关闭的所有资源必须在 try 子句中初始化，否则编译不通过。如下例所示：

public void readFile() throws FileNotFoundException {

    try(FileReader fr = new FileReader("d:/input.txt");BufferedReader br = new BufferedReader(fr);){
        String s = "";
        while((s = br.readLine()) != null){
            System.out.println(s);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

Java 9 中，用资源语句编写 try 将更容易，我们可以在 try 子句中使用已经初始化过的资源，此时的资源是 final 的：

public void readFile() throws FileNotFoundException {
    FileReader fr = new FileReader("d:/input.txt");
    BufferedReader br = new BufferedReader(fr);
    try( fr ;br){
        String s = "";
        while((s = br.readLine()) != null){
            System.out.println(s);
        }
    } catch (IOException e) {
        e.printStackTrace();
    }
}

下划线_使用限制

在jdk8中，标识符可以独立使用_命名，如下：

 String _ ="hello";
 System.out.println(_);

在 Java 9 中规定 _ 不再可以单独命名标识符了，如果使用， 会报错,如下

As of Java 9, '_' is a keyword, and may not be used as an identifier

String 存储结构变更

String 类的当前实现将字符存储在字符数组，每个字符使用两个字节（16 位）。

数据从许多不同的应用程序收集的数据表明字符串是堆使用的主要组成部分，而且最重要的是对象仅包含拉丁字母 1。这样的角色只需要一个字节的存储空间，因此占内部字符数组空间的一半许多这样的字符串对象将被闲置。

jdk9之前，String使用char[]来存储，如下：

从jdk9开始，使用byte[]加上编码标记，节约了一些空间：

与字符串相关的类，如 AbstractStringBuilder、StringBuilder、StringBuffer 底层也更新为使用byte[]存储，

快速创建只读集合

在jdk9之前，要创建一个只读、不可改变的计划，必须构造和分配它，然后添加元素，最后包装成一个不可修改的集合。

例如使用 Collections 提供的 unmodifiableList 方法可以创建只读、不可改变 的 List 集合：代码如下：

public void test() {
    List<String> namesList = new ArrayList <>();
    //添加元素
    namesList.add("Joe");
    namesList.add("Bob");
    namesList.add("Bill");
    //包装成一个不可修改的集合
    namesList = Collections.unmodifiableList(namesList);
    System.out.println(namesList);
}

jdk9给各个集合引入了of()静态方法，该方法代替 Collections.unmodifiableXXX 创建出 只读、不可改变 的集合。

List firsnamesList = List.of("Joe", "Bob", "Bill");

调用集合中静态方法 of()，可以将不同数量的参数传输到此工厂方法中。此功能可用于 Set 和 List，也可用于 Map 的类似形式。此时得到的集合，是不可变的：在创建后，继续添加元素到这些集合会导致 UnsupportedOperationException。

增强的Stream API

Java 的 Steam API 是 Java 标准库最好的改进之一，让开发者能够快速运算，从而能够有效的利用数据并行计算。

Java 8 提供的 Steam 能够利用多核架构实现声明式的数据处理。

在 Java 9 中，Stream API 变得更好，Stream 接口中添加了 4 个新的方法：dropWhile、takeWhile、ofNullable，还有个 iterate 方法的新重载方法，可以让你提供一个 Predicate（判断条件）来指定什么时候结束迭代。

除了对 Stream 本身的扩展，Optional 和 Stream 之间的结合也得到了改进。现在可以通过 Optional 的新方法 stream() 将一个 Optional 对象转换为一个（可能是空的）Stream 对象。

takeWhile() 的使用

用于从 Stream 中获取一部分数据，接收一个 Predicate 来进行选择。在有序的 Stream 中，takeWhile 碰到不符合元素时，把前面符合的元素返回。

@Test
public void takeWhileTest(){
    List<Integer>  list = Arrays.asList(32,65,36,96,35,14,78,98,52,41,69,64,99);
    Stream<Integer> stream = list.stream();
    stream.takeWhile(x->x<70).forEach(System.out::println);
    System.out.println();
}

执行结果：

32,65,36

找到不符合条件的元素后，停止寻找，虽然后面还有一些元素符合条件，也不会获取。

dropWhile() 的使用

dropWhile 的行为与 takeWhile 相反，碰到第一个不符合的元素后，把剩余的元素返回。

@Test
public  void dropWhileTest(){
    List<Integer>  list = Arrays.asList(32,65,36,96,35,14,78,98,52,41,69,64,99);
    Stream<Integer> stream = list.stream();
    stream.dropWhile(x->x<50).forEach(System.out::println);
    System.out.println();
}

执行结果：

96,35,14,78,98,52,41,69,64,99

ofNullable() 的使用

Java 8 中 Stream 不能完全为 null，否则会报空指针异常。而 Java 9 中的 ofNullable 方法允许我们创建一个单元素 Stream，可以包含一个非空元素，也可以创建一个空 Stream。

@Test
public void ofNullableTest() {
    Stream<Integer> stream1 = Stream.of(1, 2, 3, null);
    stream1.forEach(System.out::println); //1, 2, 3, null

    System.out.println();

    // 如果只有单个元素，此元素不能为 null.否则报 NullPointerException
   //  Stream