关于java:JDK8到JDK17有哪些吸引人的新特性

作者：京东批发 刘一达

前言

2006年之后SUN公司决定将JDK进行开源，从此成立了OpenJDK组织进行JDK代码治理。任何人都能够获取该源码，并通过源码构建一个发行版公布到网络上。然而须要一个组织审核来确保构建的发行版是无效的, 这个组织就是JCP(Java Community Process)。2009年，SUN公司被Oracle公司"白嫖"（参考2018年Google赔款），此时大家应用的JDK通常都是Oracle公司的OpenJDK构建版本-OracleJDK。然而，Oracle公司是一个显著只讲商业而不论情怀的公司，接手Java商标之后，显著放慢了JDK的公布版本。2018年9月25日，JDK11胜利公布，这是一个LTS版本，蕴含了17个JEP的更新。与此同时，Oracle把JDK11起以往的商业个性全副开源给OpenJDK（例如：ZGC和Flight Recorder）。依据Oracle的官网说法（Oracle JDK Releases for Java 11 and Later），从JDK11之后，OracleJDK与OpenJDK的性能基本一致。而后，Oracle发表当前将会同时发行两款JDK：1. 一个是以GPLv2+CE协定下，由Oracle发行OpenJDK（简称为Oracle OpenJDK）；2. 另一个是在OTN协定下的传统OracleJDK。这两个JDK共享绝大多数源码，外围差别在于前者能够收费在开发、测试和生产环境下应用，然而只有半年工夫的更新反对。后者各个人能够收费应用，然而生产环境中商用就必须付费，能够有三年工夫的更新反对。
2021年9月14日，Oracle JDK17公布，目前也是最新的Java LTS版本。有意思的是，Oracle居然"朝令夕改"，OracleJDK17居然是收费的开源协定，并撑持长达8年的保护打算。目前公司外部应用的OracleJDK8最高版本为1.8.0.192，而Oracle在JDK8上开源协定反对的最高收费版本为jdk1.8.0_202。2022年Spring6和SpringBoot3相继推出，而反对的最低版本为JDK17。综上所述，JDK8为目前绝大多数以稳定性为主的零碎第一抉择，然而降级到高版本JDK也只是工夫问题。上面图表展现了JDk8到JDK17的每个版本升级的JEP个数。

通过以上图表，咱们能够得出结论，JDK8到JDK17蕴含大量新个性，为Oracle在Java近5年来的智慧结晶。目前市面上的公司还是只有多数零碎会抉择JDK11或者JDK17作为线上技术选型，如果抉择从JDK8降级到JDK17必然会有十分大的挑战和较多须要填的坑。本文次要介绍JDK8到JDk17近200个JEP中比拟有价值的新个性（依照价值从高到低排序)，这里有一部分个性作者也在线上环境应用过，也会将其中的应用心得分享给大家。

外围JEP性能及原理介绍

一、Java平台模块化零碎（Jigsaw我的项目)

JDK9最夺目的新个性就是Java平台模块化零碎（JPMS，Java Platform Module System)，通过Jigsaw我的项目施行。Jigsaw我的项目是Java倒退过程的一个微小里程碑，Java模块系统对Java零碎产生十分深远的影响。与JDK的函数式编程和 Lamda表达式存在实质不同 ，Java模块零碎是对整个Java生态系统做出的扭转。

同时也是JDK7到JDK9的第一跳票王我的项目。Jigsaw我的项目本打算于在2010年随同着JDK7公布，随着Sun公司的败落及Oracle公司的接手，Jigsaw我的项目从JDK7始终跳票到JDK9才公布。前后经验了前后将近10年的工夫。即便在2017JDK9公布前夕，Jigsaw我的项目还是差点胎死腹中。起因是以IBM和Redhat为首的13家企业在JCP委员会上一手否决了Jigsaw我的项目作为Java模块化标准进入JDK9公布范畴的布局。起因无非就是IBM心愿为本人的OSGI技术在Java模块化标准中争取一席之地。然而Oracle公司没有任何的让步，不惜向JCP发去公开信，宣称如果Jigsaw提案无奈通过，那么Oracle将间接本人开发带有Jigsaw我的项目的java新版本。经验了前后6次投票，最终JDK9还是带着Jigsaw我的项目最终公布了。然而，令人悲观的是，Java模块化标准中还是给Maven、Gradle和OSGI等我的项目保留了一席之地。对于用户来说，想要实现残缺模块化我的项目，必须应用多个技术相互合作，还是减少了复杂性。如果大家想要对模块化技术有更多深刻理解，举荐浏览书籍《Java9模块化开发：外围准则与实际》

1、什么是Java模块化？

简略了解，Java模块化就是将目前多个包（package）组成一个封装体，这个封装体有它的逻辑含意 ，同时也存在具体实例。同时模块遵循以下三个外围准则：

1. 强封装性：一个模块能够选择性的对其余模块暗藏局部实现细节。
2. 定义良好的接口：一个模块只有封装是不够的，还要通过对外裸露接口与其余模块交互。因而，裸露的接口必须有良好的定义。
3. 显示依赖：一个模块通常须要协同其余模块一起工作，该模块必须显示的依赖其余模块 ，这些依赖关系同时也是模块定义的一部分。

2、为什么要做模块化？

模块化是分而治之的一个重要实际机制，微服务、OSGI和DDD都能够看到模块化思维的影子。当初很多大型的Java我的项目都是通过maven或者gradle进行版本治理和我的项目构建，模块的概念在Maven和gradle中早就存在，两者的不同下文也会说到。当初让咱们一起回顾一下目前在应用JDK搭建简单我的项目时遇到的一些问题：

2.1 如何使得Java SE应用程序更加轻量级的部署？

java包的实质只不过是类的限定名。jar包的实质就是将一组类组合到一起。一旦将多个Jar包放入ClassPath，最终失去只不过是一大堆文件而已。如何保护这么宏大的文件构造？目前最无效的形式，也是只能依赖mave或者gradle等我的项目构建工具。那最底层的Java平台的Jar包如何保护？如果我只是想部署一个简答的 helloworld利用，我须要一个JRE和一个用户编译的Jar包，并将这个Jar包放到classpath中去。JDK9以前，JRE的运行依赖咱们的外围java类库-rt.jar。rt.jar是一个开箱即用的全量java类库，要么不应用，要么应用全副。直到JDK8，rt.jar的大小为60M，随着JDK的继续倒退，这个包必然会越来越大。而且全量的java类库，给JRE也带来了额定的性能损耗。Java应用程序如果能选择性的加载rt.jar中的文件该多好？

2.2 在裸露的JAR包中，如何暗藏局部API和类型？

在应用Dubbo等RPC框架中，provider须要提供调用的接口定义Jar包，在该Jar包中蕴含一个共该Jar包外部应用的常量聚合类Constannt，放在constant包内。如何能力裸露JAR包的同时，暗藏常量聚合类Constant？

2.3 始终蒙受NoClassDefFoundError的折磨

通过什么形式，能够晓得一个Jar包依赖了哪些其余的 Jar包？JDK自身目前没有提供，能够通过Maven工具实现。那为什么不让Java平台本身就提供这些性能？

3、JPMS如何解决现有问题？

JPMS具备两个重要的指标：

1. 强封装（Strong encapsulation): 每一个模块都能够申明了哪些包是对外裸露的，java编译和运行时就能够施行这些规定来确保内部模块无奈应用外部类型。
2. 牢靠配置（Reliable configuration）：每一模块都申明了哪些是它所需的，那么在运行时就能够查看它所需的所有模块在利用启动运行前是否都有。

Java平台自身就是必须要进行模块化革新的简单我的项目，通过Jigsaw我的项目落地。

3.1 Project Jigsaw

Modular development starts with a modular platform. —Alan Bateman 2016.9

模块化开始于模块化平台 。Project Jigsaw 有如下几个指标：

1. 可伸缩平台（Scalable platform）：逐步从一个宏大的运行时平台到有有能力放大到更小的计算机设备。
2. 安全性和可维护性（Security and maintainability）：更好的组织了平台代码使得更好保护。暗藏外部API和更明确的接口定义晋升了平台的安全性。
3. 晋升应用程序性能（Improved application performance）：只有必须的运行时runtimes的更小的平台能够带来更快的性能。
4. 更简略的开发体验Easier developer experience：模块零碎与模块平台的联合使得开发者更容易构建利用和库。

对Java平台进行模块化革新是一个巨大工程，JDK9之前，rt.jar是个微小的Java运行时类库，大略有60MB左右。JDK9将其拆分成90个模块左右 ，如下图所示（图片起源《Java 9模块化开发》）：

4 创立第一个Java模块

创立一个Java模块其实十分的简略。在目前Maven构造的我的项目下，只须要在java目录下，新建一个module-info.java文件即可。此时，当前目录就变成了一个Java模块及Maven模块。

--moudule1---src----main-----java------com.company.package1------moudule-info.java---pom.xml

5 模块化对现有利用的影响

5.1 你能够不必然而不能不懂

Java模块化目前并没有展现出其宣传上的影响，同时也鲜有类库正在做模块化的革新。甚至，自己在创立第一个模块的时候，就遇到了Lombook生效、深度反射失败、Spring启动失败以及无奈动静部署的影响。因而，尽量不要尝试在线上环境应用模块化技术！不必，然而不代表你能够不懂！随着Java平台模块化的实现，运行在JDK9环境的Java程序就曾经面临着Jar包和模块的合作问题。防患未然，在发现问题的时候，模块化技术能够帮你疾速的定位问题并解决问题。
例如，在从JDK8降级到JDK11时，咱们常常会收到一下正告：

WARNING: An illegal reflective access operation has occurredWARNING: Illegal reflective access by com.jd.jsf.java.util.GregorianCalendar_$$_Template_1798100948_0 (file:/home/export/App/deliveryorder.jd.com/WEB-INF/lib/jsf-1.7.2.jar) to field java.util.Calendar.fieldsWARNING: Please consider reporting this to the maintainers of com.jd.jsf.java.util.GregorianCalendar_$$_Template_1798100948_0WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operationsWARNING: All illegal access operations will be denied in a future release

通过反射拜访JDK模块内类的公有办法或属性，且以后模块并未凋谢指定类用于反射拜访，就会呈现以上告警。解决形式也必须应用模块化相干常识，能够应用遵循模块化之间的拜访规定，也能够通过设置 –add-opens java.base/java.lang = ALL-UNNNAMED 毁坏模块的封装性形式长期解决；

5.2 Java模块、Maven模块和OSGI模块的之间的关系。

Java模块化技术，实践上能够从Java底层解决模块和模块之间的模块依赖、多版本、动静部署等问题。 前文所述，在2017JDK9公布前夕，以IBM和Redhat为首的13家企业在JCP委员会上一手否决了Jigsaw我的项目作为Java模块化标准进入JDK9公布范畴的布局。通过泛滥衡量，Java模块化标准中还是给Maven、Gradle和OSGI等我的项目保留了一席之地。目前，能够通过Java模块+Maven模块或者Java模块+OSGI模块的形式构建我的项目，惋惜的是，应用多个技术相互合作，还是减少了复杂性。

5.3 模块化对类加载机制的影响

JDK9之后，首先勾销了之前的扩大类加载器，这是清理之中，因为自身JRE扩大目录都曾经不存在，取而代之的是平台类加载器。而后，类加载器的双亲委派模型机制进行了毁坏，在子类将类委派给父类加载之前，会优先将以后类交给以后模块（Moudle）或层（Layer）的类加载器加载。所以会造成如下的类加载模型：

同时，在JDK9之后，引入的层（Layer）的概念，在Java程序启动时，会解析以后模块门路中的依赖关系，并造成一个依赖关系图蕴含在疏导层（Bootstrap Layer）中，这个依赖关系图从此开始不再扭转。因而，当初动静的新增模块要创立新的层，不同的层之间能够蕴含雷同的模块。会造成如下所示的依赖关系（图片起源《Java 9模块化开发》）：

综上所述，模块化革新对于应用自定义类加载器进行性能动态变化的程序还是微小的，一旦应用模块化，必然会导致这类性能受到微小影响。当然模块化技术遍及还须要很长一段时间，会晚然而不会不来，提前把握相干技术还是很必要。

5.4 总结

上面是Java模块化相干技术的一些外围脑图，能够学习参考：

二、垃圾回收器的一系列优化措施

2.1、ZGC-新一代垃圾回收器

JDK11中，最夺目的新个性就是ZGC垃圾回收器。作为试验性功能，ZGC的特点包含：

• GC进展工夫不会超过10ms。
• 进展工夫不会随着堆的大小，或者沉闷对象的大小而减少；
• 绝对于G1垃圾回收器而言，吞吐量升高不超过15%；
• 反对Linux/x64、window和mac平台；
• 反对8MB~16TB级别的堆回收。

同时依据openJDK官网的性能测试数据显示（JEP333），ZGC的体现十分的杰出：

• 在仅关注吞吐量指标下，ZGC超过了G1；
• 在最大提早不超过某个设定值（10到100ms）下关注吞吐量，ZGC较G1性能更加突出。
• 在仅关注低提早指标下，ZGC的性能高出G1将近两个数量级。99.9th仅为G1的百分之一。

也正是因为如此，ZGC几乎是低提早大内存服务的福音。话说如此，作者在尝试应用ZGC过程中还是发现一些问题：

1. 因为整个ZGC周期根本都是并发执行，因而创立新对象的速度与垃圾回收的速度从一开始就在较量。如果创立新对象的速度更胜一筹，垃圾会将堆占满导致局部线程阻塞，直到垃圾回收结束。
2. G1尽管是第一个基于全局的垃圾回收器，然而依然存在新生代和老年代的概念。然而从ZGC开始，齐全摈弃了新生代和老年代。然而新生代对象朝生夕灭的个性会给ZGC带来很大的压力。齐全的并发执行，必然会造成肯定的吞吐量升高。
3. 在JDK11，G1垃圾回收器目前还只是实验性的性能，只反对Linux/x64平台。后续优化接改良，短时间内无奈更新到JDK11中，所以可能会遇到一些不稳固因素。例如: 1. JDK12反对并发类卸载性能。2. JDK13将可回收内存从4TB反对到16TB。3. JDK14晋升稳定性的同时，进步性能。4. JDK15从试验个性转变为可生产个性 。所以如果想要应用稳固的ZGC性能，只能降级到JDK17，横跨一个JDK11LTS版本，同时面临近200个JEP带来的性能更新。
4. 理论线上生产环境，在订单商品等外围零碎尝试应用ZGC。然而压测结果显示，在JDK11还是JDK17都差强人意。当然这并不是代表ZGC自身技术缺点，而是须要依据不同的线上环境做更深度的调优和实际。因为数据窃密等起因，这里没有给大家展现具体的压测数据，读者能够在各自环境进行不同水平的压测验证。

ZGC的原理介绍须要极大的篇幅，本文不打算对ZGC的底层技术开展大范畴探讨。如果大家想要深刻学习，作者举荐书籍《新一代垃圾回收器ZGC设计与实现》、Openjdk官网：ZGC介绍以及《深刻了解Java虚拟机第五版》中的一些介绍。

2.2、G1垃圾回收器相干

总的来讲，得益于多个JEP优化，G1垃圾回收器无论是在JDK11还是JDK17都体现出了更弱小的能力。随着CMS垃圾回收器的废除，以及新生代ZGC的老成持重，G1垃圾回收器毫无疑问成了兼顾提早和吞吐的最佳抉择。通过屡次压测后果察看，只是简略的进步JDK版本，就能够做到更低的GC工夫、更短的GC距离以及更少的CPU损耗。

2.2.1、G1的Full GC从串行改为并行（JEP307）

G1垃圾回收器，在 Mix GC回收垃圾的速度小于新对象调配的速度时，会产生Full GC。之前，产生Full GC时采纳的是Serial Old算法，该算法应用单线程标记-革除-压缩算法，垃圾回收吞吐量较高，然而Stop-The-World工夫变长。JDK10，为了缩小G1垃圾回收器在产生Full GC时对利用造成的影响，Full GC采纳并行标记-革除-压缩算法。该算法能够通过多线程合作 ，缩小Stop-The-World工夫。线程的数量能够由-XX:ParallelGCThreads选项来配置 ，然而这也会影响Young GC和Mixed GC线程数量。

2.2.2、可中断的Mixed-GC（JEP344）

G1垃圾回收器，通过一种名为CSet的数据结构辅助实现可预测进展模型算法。CSet中存储了GC过程中可进行垃圾回收的Region汇合。在本个性之前，CSet一旦被确定，就必须全副扫描并执行回收操作，这可能会导致超过预期的垃圾回收暂停工夫。因而，JEP344针对这种问题进行了优化。Java12 中将把 Cset拆分为强制及可选两局部。无限执行强制局部的CSet，执行实现之后如果存在剩余时间，则持续解决可选Cset局部，从而让GC暂停工夫更靠近预期值。

2.2.3 G1反对NUMA技术（JEP345）

非对立内存拜访架构（英语：non-uniform memory access，简称NUMA）是一种为多处理器的电脑设计的内存架构，内存拜访工夫取决于内存绝对于处理器的地位。在NUMA下，处理器拜访它本人的本地内存的速度比非本地内存（内存位于另一个处理器，或者是处理器之间共享的内存）快一些。ParallelGC在前几年曾经开始反对NUMA技术，并且对于垃圾回收器性能有较大晋升。惋惜的是，G1垃圾回收器在JDK14之前始终不反对此项技术，当初能够通过参数+XX:+UseNUMA在应用G1垃圾回收器时应用NUMA技术。

2.3、废除CMS垃圾回收器

CMS垃圾回收器在JDK9彻底被废除，在JDK12间接被删除。目前，G1垃圾回收器是代替CMS的最优抉择之一。

2.4、废除ParallelScavenge + SerialOld 垃圾回收器组合

Java垃圾回收器有多种多样的组合和应用形式。上面这张图，我大略看过不差10遍，可是每次后果也是雷同，记不住！！！！

默认垃圾回收器是哪些？
-XX:+UseParallelGC -XX:-UseParallelOldGC -XX:+UseParallelGC -XX:+UseParNewGC 这几个参数有什么区别？
CMS垃圾回收器有哪些要害参数？浮动垃圾怎么解决？如何防止Full GC产生？
好消息！这些当前都不必记忆了，咱们只须要专一攻克三款垃圾回收器原理：默认大哥G1、新晋新星ZGC、非亲儿子Shanondoah(理解)。这里兴许有人会抬杠，小内存CMS会有更好的体现。ParNew依然是高吞吐服务的首选。大道至简，简略易用才是王道。G1和ZGC必然是当前JVM垃圾回收器的重点倒退方向，与其消耗精力记忆行将淘汰的技术，不如利出一孔，精通一门！

2.4、Epsilon：低开销垃圾回收器

Epsilon 垃圾回收器的指标是开发一个管制内存调配，然而不执行任何理论的垃圾回收工作。上面是该垃圾回收器的几个应用场景：性能测试、内存压力测试、极度短暂 job 工作、提早改良、吞吐改良。

三、诊断和监控相干优化

3.1 Java Flight Recorder[JEP328]

Java Flight Recorder (JFR) 从正在运行的 Java 应用程序收集诊断和剖析数据。 依据SPECjbb2015基准压测结果显示，JFR 对正在运行的 Java 应用程序的性能影响低于1%。 对于JFR的统计数据，能够应用 Java Mission Control (JMC) 和其余工具剖析。 JFR 和 JMC 在 JDK 8 中是商业付费性能，而在 JDK11 中都是收费开源的。

3.2 Java Mission Control [JMS]

Java Mission Control (JMC) 能够剖析并展现 Java Flight Recorder (JFR) 收集的数据，并且在 JDK 11 中是开源的。除了无关正在运行的应用程序的个别信息外，JMC 还容许用户深刻理解数据。 JFR 和 JMC 可用于诊断运行时问题，例如内存透露、GC 开销、热点办法、线程瓶颈和阻塞 I/O。JMC能够作为现有JVM监控工具的一个补充，做到维度更多，监控更加实时（秒级），能从多个视角监控以后JVM过程的性能，更加更疾速的定位并解决问题。

3.3 对立 JVM 日志（JEP158）

在以往的低版本中很难晓得导致JVM性能问题和导致JVM解体的根本原因。不同的JVM对日志的应用是不同的机制和规定，这就使得JVM难以进行调试。
解决这个问题最佳的办法：对所有的JVM组件引入一个对立的日志框架，这些JVM组件反对细粒度的和易配置的JVM日志。 JDK8以前罕用的打印GC日志形式：

-Xloggc:/export/Logs/gc.log //输入GC日志到指定文件-XX:+PrintGCDetails-XX:+PrintGCTimeStamps

3.3.1 指标：

1. 所有日志记录的通用命令行选项。
2. 通过tag对日志进行分类，例如：compiler, gc, classload, metaspace, svc, jfr等。一条日志可能会含有多个 tag
3. 日志蕴含多个日志级别：error, warning, info, debug, trace, develop。
4. 能够将日志重定向到控制台或者文件。
5. error, warning级别的日志重定向到规范谬误stderr.
6. 能够依据日志大小或者文件数对日志文件进行滚动。
7. 一次只打印一行日志，日志之间无穿插。
8. 日志蕴含装璜器，默认的装璜器包含：uptime, level, tags，且装璜可配置。

3.3.2 如何应用

-Xlog[:option]    option         :=  [][:[][:[][:]]]                       'help'                       'disable'    what           :=  [,...]    selector       :=  [*][=]    tag-set        :=  [+...]                       'all'    tag            :=  name of tag    level          :=  trace                       debug                       info                       warning                       error    output         :=  'stderr'                       'stdout'                       [file=]    decorators     :=  [,...]                       'none'    decorator      :=  time                       uptime                       timemillis                       uptimemillis                       timenanos                       uptimenanos                       pid                       tid                       level                       tags    output-options :=  [,...]    output-option  :=  filecount=                       filesize=                       parameter=value

1. 能够通过配置-Xlog:help参数，获取罕用的JVM日志配置形式。
2. 能够通过-Xlog:disable参数敞开JVM日志。

3. 默认的JVM日志配置如下：

   -Xlog:all=warning:stderr:uptime,level,tags    - 默认配置    - 'all' 即是蕴含所有tag    - 默认日志输入级别warning，地位stderr    - 蕴含uptime,level,tags三个装璜

4. 能够参考应用如下配置：

   JDK9之前参数-XX:+PrintGCDetails可参考：

   -Xlog:safepoint,classhisto*=trace,age*,gc*=info:file=/export/Logs/gc-%t.log:time,tid,level,tags:filecount=5,filesize=50MB   - safepoint示意打印用户线程并发及暂停执行工夫   - classhisto示意full gc时打印堆快照信息   - age*,gc* 示意打印包含gc及其细分过程日志，日志级别info，文件：/export/Logs/gc.log。    - 日志格局蕴含装璜符：time,tids,level,tags    - default output of all messages at level 'warning' to 'stderr'    will still be in effect    - 保留日志个数5个，每个日志50M大小

   查看GC前后堆、办法区可用容量变动，在JDK9之前，能够应用-XX::+PrintGeapAtGC,当初可参考：

   -Xlog:gc+heap=debug:file=/export/Logs/gc.log:time,tids,level,tags:filecount=5,filesize=1M    - 打印包含gc及其细分过程日志，日志级别info，文件：/export/Logs/gc.log。    - 日志格局蕴含装璜符：time,tids,level,tags    - default output of all messages at level 'warning' to 'stderr'    will still be in effect    - 保留日志个数5个，每个日志1M大小

JDK9之前的GC日志：

2014-12-10T11:13:09.597+0800: 66955.317: [GC concurrent-root-region-scan-start]2014-12-10T11:13:09.597+0800: 66955.318: Total time for which application threads were stopped: 0.0655753 seconds2014-12-10T11:13:09.610+0800: 66955.330: Application time: 0.0127071 seconds2014-12-10T11:13:09.614+0800: 66955.335: Total time for which application threads were stopped: 0.0043882 seconds2014-12-10T11:13:09.625+0800: 66955.346: [GC concurrent-root-region-scan-end, 0.0281351 secs]2014-12-10T11:13:09.625+0800: 66955.346: [GC concurrent-mark-start]2014-12-10T11:13:09.645+0800: 66955.365: Application time: 0.0306801 seconds2014-12-10T11:13:09.651+0800: 66955.371: Total time for which application threads were stopped: 0.0061326 seconds2014-12-10T11:13:10.212+0800: 66955.933: [GC concurrent-mark-end, 0.5871129 secs]2014-12-10T11:13:10.212+0800: 66955.933: Application time: 0.5613792 seconds2014-12-10T11:13:10.215+0800: 66955.935: [GC remark 66955.936: [GC ref-proc, 0.0235275 secs], 0.0320865 secs]

JDK9对立日志框架输入的日志格局 ：

[2021-02-09T21:12:50.870+0800][258][info][gc] Using G1[2021-02-09T21:12:51.751+0800][365][info][gc] GC(0) Pause Young (Concurrent Start) (Metadata GC Threshold) 60M->5M(4096M) 7.689ms[2021-02-09T21:12:51.751+0800][283][info][gc] GC(1) Concurrent Cycle[2021-02-09T21:12:51.755+0800][365][info][gc] GC(1) Pause Remark 13M->13M(4096M) 0.959ms[2021-02-09T21:12:51.756+0800][365][info][gc] GC(1) Pause Cleanup 13M->13M(4096M) 0.127ms[2021-02-09T21:12:51.758+0800][283][info][gc] GC(1) Concurrent Cycle 7.208ms[2021-02-09T21:12:53.232+0800][365][info][gc] GC(2) Pause Young (Normal) (G1 Evacuation Pause) 197M->15M(4096M) 17.975ms[2021-02-09T21:12:53.952+0800][365][info][gc] GC(3) Pause Young (Concurrent Start) (GCLocker Initiated GC) 114M->17M(4096M) 15.383ms[2021-02-09T21:12:53.952+0800][283][info][gc] GC(4) Concurrent Cycle

四、更加优雅的语法或者办法

4.1、汇合工厂办法

List，Set 和 Map 接口中，新的动态工厂办法能够创立不可变汇合。

// 创立只有一个值的可读list，底层不应用数组static <E> List<E> of(E e1) {   return new ImmutableCollections.List12<>(e1);}// 创立有多个值的可读list，底层应用数组static <E> List<E> of(E e1, E e2, E e3) {   return new ImmutableCollections.List12<>(e1, e2,e3);}// 创立单例长度为0的Set联合static <E> Set<E> of() {   return ImmutableCollections.emptySet();}static <E> Set<E> of(E e1) {   return new ImmutableCollections.Set12<>(e1);}

4.2、接口公有办法

Java 8, 接口能够有默认办法。Java9之后，能够在接口内实现公有办法实现。

public interface HelloService {    public void sayHello();    // 默认办法    default void saySomething(){        syaEngHello();        sayHello();    };    // 公有办法    private void syaEngHello(){        System.out.println("Hello!");    }}

4.3、改良的 Stream API

Java 9 为 Stream 新增了几个办法：dropWhile、takeWhile、ofNullable，为 iterate 办法新增了一个重载办法。

// 循环直到第一个满足条件后进行default Stream takeWhile(Predicate predicate);// 循环直到第一个满足条件后开始default Stream dropWhile(Predicate predicate);// 依据表达式生成迭代器static  Stream iterate(T seed, Predicate hasNext, UnaryOperator next);// 应用空值创立空的Stream,防止空指针static  Stream ofNullable(T t);

4.4、JShell

JShell 是 Java 9 新增的一个交互式的编程环境工具。它容许你无需应用类或者办法包装来执行 Java 语句。它与 Python 的解释器相似，能够间接 输出表达式并查看其执行后果。

4.5、部分类型推断（JEP286）

JDK10推出了部分类型推断性能，能够应用var作为局部变量类型推断标识符，缩小模板代码的生成 ，实质还是一颗语法糖。同时var关键字的用于与lombok提供的部分类型推断性能也基本相同。

public static void main(String[] args) throws Exception {    var lists = List.of("a", "b", "c");    for (var word : lists) {        System.out.println(word);    }}

var关键字只能用于可推断类型的代码地位，不能应用于办法形式参数，构造函数形式参数，办法返回类型等。标识符var不是关键字，它是一个保留的类型名称。这意味着var用作变量，办法名或则包名称的代码不会受到影响。但var不能作为类或则接口的名字。

var关键字的应用的确能够缩小很多没必要的代码生成。然而，也存在本人的毛病：1. 当初很多IDE都存在主动代码生成的快捷方式，所以使不应用var关键字区别不大。2. 部分类型推断，不光是编译器在编译期间要推断，前面保护代码的人也要推断，会在肯定水平上减少了解老本。

4.6、规范Java HTTP Client

应用过Python或者其余语言的HTTP拜访工具的人，都晓得JDK提供的HttpURLConnection或者Apache提供的HttpClient有如许的臃肿。简略比照一下。

python 自带的urllib工具：

response=urllib.request.urlopen('https://www.python.org')  #申请站点取得一个HTTPResponse对象print(response.read().decode('utf-8'))   #返回网页内容

JDK:

HttpURLConnection connection = (HttpURLConnection) new URL("http://localhost:8080/demo/list?name=HTTP").openConnection();connection.setRequestMethod("GET");connection.connect();int responseCode = connection.getResponseCode();log.info("response code : {}", responseCode);// read responsetry (BufferedReader reader = new BufferedReader(new InputStreamReader(connection.getInputStream()))) {    String line;    while ((line = reader.readLine()) != null) {        System.out.println(line);    }} finally {    connection.disconnect();}

Apache HttpClient:

CloseableHttpClient httpClient = HttpClientBuilder.create().build();// 创立Get申请HttpGet httpGet = new HttpGet("http://localhost:12345/doGetControllerOne");// 响应模型CloseableHttpResponse response = null;// 由客户端执行(发送)Get申请response = httpClient.execute(httpGet);// 从响应模型中获取响应实体HttpEntity responseEntity = response.getEntity();System.out.println("响应状态为:" + response.getStatusLine());

Java 9 中引入了规范Http Client API 。并在 Java 10 中进行了更新的。 到了Java11，在前两个版本中进行孵化的同时，Http Client 简直被齐全重写，并且当初齐全反对异步非阻塞。与此同时它是 Java 在 Reactive-Stream 方面的第一个生产实践，其中宽泛应用了 Java Flow API。

HttpClient client = HttpClient.newHttpClient();HttpRequest request = HttpRequest.newBuilder()      .uri(URI.create("http://openjdk.java.net/"))      .build();client.sendAsync(request, BodyHandlers.ofString())      .thenApply(HttpResponse::body)      .thenAccept(System.out::println)      .join();

4.7、Helpful NullPointerExceptions（JEP358）

随着流式编程格调的风行，空指针异样成为了一种比拟难定位的BUG。例如：

a.b.c.i = 99;a[i][j][k] = 99;

在之前，咱们只能收到以下异样堆栈信息，而后必须借助DEBUG工具考察问题：

Exception in thread "main" java.lang.NullPointerException    at Prog.main(Prog.java:5)

优化后，咱们能够失去更加优雅的空指针异样提示信息：

Exception in thread "main" java.lang.NullPointerException:         Cannot read field "c" because "a.b" is null    at Prog.main(Prog.java:5)    Exception in thread "main" java.lang.NullPointerException:        Cannot load from object array because "a[i][j]" is null    at Prog.main(Prog.java:5)

4.8、更加优雅的instance of 语法（JEP394）

以下代码是每个Java开发工程师的一块心病：

if (obj instanceof String) {    String s = (String) obj;    // grr...    ...}

下面的instanc of语法一共做了三件事：

1. 判断是否为String类型；
2. 如果是，转成String类型；
3. 创立一个名为s的长期变量；
   在JDK16中，应用模式匹配思维改良了instance of 用法，能够做到以下优化成果：

if (obj instanceof String s) {// obj是否为String类型，如果是创立长期变量s    // Let pattern matching do the work!    ...}

咱们能够看到，整体代码格调的确优雅了很多。变量s的作用域为满足条件的判断条件范畴之内。因而，以下应用也是非法的：

if (obj instanceof String s && s.length() > 5) {// 因为&&具备短路性能    flag = s.contains("jdk");}

然而以下用法，则会报错：

if (obj instanceof String s || s.length() > 5) {    // Error!    ...}

正当应用，则能够达到以下成果：

// 优化应用前public final boolean equals(Object o) {    if (!(o instanceof Point))        return false;    Point other = (Point) o;    return x == other.x        && y == other.y;}// 优化应用后：public final boolean equals(Object o) {    return (o instanceof Point other)        && x == other.x        && y == other.y;}

4.9、更加优雅的Switch用法

Java里有一句名言：能够用switch构造实现的程序都能够应用if语句来实现。而且Swtich语法在某些工程师眼里，基本没有if语句简洁。JDK14中提供了更加优雅的swtich语法，例如：

// 之前switch (day) {    case MONDAY:    case FRIDAY:    case SUNDAY:        System.out.println(6);        break;    case TUESDAY:        System.out.println(7);        break;    case THURSDAY:    case SATURDAY:        System.out.println(8);        break;    case WEDNESDAY:        System.out.println(9);        break;}// 之后switch (day) {    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);    case TUESDAY                -> System.out.println(7);    case THURSDAY, SATURDAY     -> System.out.println(8);    case WEDNESDAY              -> System.out.println(9);}

还能够把switch语句当成一个表达式来解决：

T result = switch (arg) {    case L1 -> e1;    case L2 -> e2;    default -> e3;};static void howMany(int k) {    System.out.println(        switch (k) {            case  1 -> "one";            case  2 -> "two";            default -> "many";        }    );}

还能够配合关键字yield，在简单解决场景里，返回指定值：

int j = switch (day) {    case MONDAY  -> 0;    case TUESDAY -> 1;    default      -> {        int k = day.toString().length();        int result = f(k);        yield result;    }};

还有吗？其实在JDK17中，还提出了Swtich 模式匹配的预览性能，能够做到更优雅的条件判断：

// 优化前static String formatter(Object o) {    String formatted = "unknown";    if (o instanceof Integer i) {        formatted = String.format("int %d", i);    } else if (o instanceof Long l) {        formatted = String.format("long %d", l);    } else if (o instanceof Double d) {        formatted = String.format("double %f", d);    } else if (o instanceof String s) {        formatted = String.format("String %s", s);    }    return formatted;}// 优化后static String formatterPatternSwitch(Object o) {    return switch (o) {        case Integer i -> String.format("int %d", i);        case Long l    -> String.format("long %d", l);        case Double d  -> String.format("double %f", d);        case String s  -> String.format("String %s", s);        default        -> o.toString();    };}

五、字符串压缩-Compact Strings（JEP254）

字符串是咱们日常编程中应用最频繁的根本数据类型之一。目前，字符串类底层都应用了一个字符数组来实现，每个字符应用2个字节（16位）空间。实际上，大量的字符都属于Latin-1字符范畴内，咱们只须要一个字节就能存储这些数据，因而这里有微小的可压缩空间；SPECjbb2005压测结果显示对于GC工夫及GC工夫距离都有肯定水平的晋升。具体原理文档也能够参考【Oracle对CompackStrings分享】

六、 Java Flow API

Reactive Streams是一套非阻塞背压的异步数据流解决标准。从Java9开始，Java原生反对Reactive Streams编程标准。Java Flow API是对Reactive Streams编程标准的1比1复刻，同时意味着从Java9开始，JDK自身开始在Reactive Streams方向上进行逐渐革新。

七、新一代JIT编译器 Graal

即时编译器在进步JVM性能上扮演着十分重要的角色。目前存在两JIT编译器：编译速度较快但对编译后的代码优化较低的C1编译器；编译速度较慢但编译后的代码优化较高的C2编译器。两个编译器在服务端程序及分层编译算法中扮演着十分重要的角色。然而，C2编译器曾经存在将近20年了，其中凌乱的代码以及局部蹩脚的架构使其难以保护。JDK10推出了新一代JIT编译器Graal（JEP317）。Graal作为C2的继任者呈现，齐全基于Java实现。Graal编译器借鉴了C2编译器优良的思维同时，应用了新的架构。这让Graal在性能上很快追平了C2，并且在某些非凡的场景下还有更优良的体现。遗憾的是，Graal编译器在JDK10中被引入，然而在JDK17（JEP410）中被破除了，理由是开发者对其应用较少切保护老本太高。开发者也能够通过应用GraalVM来应用Graal编译器；

总结

本文介绍了JDK9-JDK17降级过的近200个JEP中作者狭窄角度认为价值较高的性能做了一个综述类介绍。次要目标有两个：

1. 通过本文，大家能够对行将应用的JDK11及JDK17新个性有一个抽象的理解，心愿能够看到一些Java预发最近几年的倒退方向。
2. 通过本文也能够看出，从JDK9到JDK17，Java生态还是生机勃勃。大量性能的更新意味着更优良的性能及更高效的开发效率，积极主动的尝试高版本JDK；
   当然，JDK8到JDK17还有需要优良的新个性，例如：shanondoah垃圾回收器、Sealed Classes、Records；
   鉴于自己能力无限，文中会呈现一些破绽，心愿大家找出并斧正，让本文成长为后续JDK17降级的扫盲手册；