jdk11新特性

JDK 11主要特性一览

　　jdk11即将在9月25号发布正式版。确定的新特性包括以下17个

• 181 嵌套类可见性控制
• 309 动态文件常量
• 315 改进 Aarch64 Intrinsics
• 318 Epsilon–一个无操作的垃圾收集器
• 320 删除 Java EE 和 CORBA 模块
• 321 HttpClient
• 323 用于 Lambda 参数的局部变量语法
• 324 Curve25519 和 Curve448 算法的密钥协议
• 327 Unicode 10
• 328 Flight Recorder(飞行记录器)
• 329 haCha20 和 Poly1305 加密算法支持
• 330 Launch Single-File Source-Code Programs（启动单一文件的源代码程序）
• 331 低开销的 Heap Profiling
• 332 TLS 1.3支持
• 333 ZGC: A Scalable Low-Latency Garbage Collector（可伸缩低延迟垃圾收集器）
• 335 弃用 Nashorn JavaScript 引擎
• 336 弃用 Pack200 工具和 API

　　这一次的JDK升级对于java这个语言来说是一次新生。这是JDK第一次在一年内进行两次大版本的升级，原本在JDK9宣布JAVA要加速JDK升级每年发布一个版本时，笔者还是存在一些疑虑的，由于Java现在已经是世界上使用范围最广的语言之一，贸然的引入新特性造成的影响太大。但从该版本来看JDK确实成功的完成了既定目标，并且已经宣布JDK12会在19年九月发布正式版。对于Java开发者来说，一方面是新特性带来的便捷而另一方面是要努力学习了～

　　ZGC是这次JDK的最大的亮点，JVM　GC 子在大内存服务中的性能有了一个质的改变，直接将AZul的商用JVM C4优势拉近了一个身位。相较G1，ZGC最大的不同是使用了Load Barrier及颜色指针技术。虽然目前ZGC只是实验版本，但可以预见不远的将来ZGC会覆盖大多数的服务器。

　　James Gosling曾表明，如果可以重新设计java，他希望是scala的样子。
从JDK 11来看，靠近scala确实做到了。从JDK 8的lambda表达式到现在的 “嵌套类可见性支持/用于 Lambda 参数的局部变量语法/Launch Single-File Source-Code Programs”，Java都在向scala 学习。前两天在跟朋友开玩笑，如果java中能够支持“隐式转换”，那spring、guice这类注入框架都得重写了，java也能改名叫jcala了。Java由于历史遗留问题，在函数式计算支持方面还是存在很大的问题，没有办法像scala可以更好的支持函数式计算。例如在scala中，adt类型都已经划分的非常清楚，有mutable、immutable、parallel、concurrent等类型的支持，而java中还需要引入额外的对象来辅助实现函数式计算。从长远来看虽然java可以逐渐向scala靠拢，但在函数式计算方面java的支持还会和scala有比较大的差距。如果对于大数据、函数式计算的同学推荐了解一下scala。

　　以下是对JDK 11的主要特性的介绍和分析。

ZGC

　　从JDK 8开始，JDK使用G1作为默认的垃圾回收器。G1可以说是GC的一个里程碑，G1之前的GC回收，还是基于固定的内存区域，而G1采用了一种“细粒度”的内存管理策略，不在固定的区分内存区域属于surviors、eden、old，而我们不需要再去对于年轻代使用一种回收策略，老年代使用一种回收策略，取而代之的是一种整体的内存回收策略。这种回收策略在我们当下cpu、内存、服务规模都越来越大的情况下提供了更好的表现。
　　而这一代ZGC更是有了突破性的进步，SPECjbb 2015基准测试，在128G的大堆下

　　//数值越高越好
　　ZGC
　　　　max-jOPS: 100%
　　　　critical-jOPS: 76.1%
　　G1
　　　　max-jOPS: 91.2%
　　　　critical-jOPS: 54.7%
　　//数值越低越好
　　ZGC
　　　　avg: 1.091ms (+/-0.215ms)
　　　　95th percentile: 1.380ms
　　　　99th percentile: 1.512ms
　　　　99.9th percentile: 1.663ms
　　　　99.99th percentile: 1.681ms
　　　　max: 1.681ms

　　G1
　　　　avg: 156.806ms (+/-71.126ms)
　　　　95th percentile: 316.672ms
　　　　99th percentile: 428.095ms
　　　　99.9th percentile: 543.846ms
　　　　99.99th percentile: 543.846ms
　　　　max: 543.846ms

从原理上来理解，ZGC可以看做是G1之上更细粒度的内存管理策略。由于内存的不断分配回收会产生大量的内存碎片空间，因此需要整理策略防止内存空间碎片化，在整理期间需要将对于内存引用的线程逻辑暂停，这个过程被称为"Stop the world"。只有当整理完成后，线程逻辑才可以继续运行。
一般而言，主要有如下几种方式优化"Stop the world"

• 使用多个线程同时回收（并行回收）
• 回收过程分为多次停顿（增量回收）
• 在程序运行期间回收，不需要停顿或只停顿很短时间（并发回收）
• 只回收内存而不整理内存

ZGC主要采用的是并发回收的策略，相较于G1 ZGC最主要的提升是使用Load Barrier技术实现，引用R大对于ZGC的评价

与标记对象的传统算法相比，ZGC在指针上做标记，在访问指针时加入Load Barrier（读屏障），比如当对象正被GC移动，指针上的颜色就会不对，这个屏障就会先把指针更新为有效地址再返回，也就是，永远只有单个对象读取时有概率被减速，而不存在为了保持应用与GC一致而粗暴整体的Stop The World。

此外还有

• 对于Region的更细粒度控制，不同与G1的固定region，ZGC可以有多个size的Region
• Numa架构的支持

延伸阅读
ZGC wiki
A FIRST LOOK INTO ZGC
Java程序员的荣光，听R大论JDK11的ZGC
AZul 论文

嵌套类可见性支持

　　嵌套类可见性支持，这里主要增加了对于嵌套类private的支持。

　　class A {
　　　　public void f1() {
    　　　　B b = new B();
　　　　　　// System.out.println(b.s)  //jdk 10后不能通过编译
   　　　　 // System.out.println(b.f2())  //jdk 10后不能通过编译
　　　　}
　　　　class B {
    　　　　private String s = "b";
　　　　　　private void f2() {
　　　　　　　　System.out.println("f2");
　　　　　　}
　　　　}
　　}

用于 Lambda 参数的局部变量语法

　　看到这两个特性的时候，感觉到java开始向scala开始靠拢了。

　　用于 Lambda 参数的局部变量语法简单来说就是支持的类型推导

　　var x = new A();

　　for (var x : xs) { ... }

　　try (var x = ...) { ... } catch ...

　　类型推导这几年在python, scala中非常火爆，虽然实现不难，但java迟迟没有对于类型推导的支持。如今java终于支持类型推导了。省去了对于类型的直接声明，并且在函数式计算中，类型推导也能很大程度上省略一些冗余的代码。

Launch Single-File Source-Code Programs

　　Launch Single-File Source-Code Programs
　　这个说起来比较简单，启动单一文件的源代码程序这块对于脚本开发会有一些帮助。目前来看java面向对象的语法导致的问题是代码的冗余，实际上脚本开发上面向过程编程。并且JDK目前没有一个比较好的JConsole的支持，三方库依赖实现复杂，因此这方面来说pyton对于脚本开发更有优势。个人不看好未来JDK对脚本的支持。

HTTP Client

　　对于Http Client 这个功能来说，我认为Jdk对于这个场景支持还是比较迟了。以致于这样一个常用的场景，我们不得不引入三方apache commons　的HTTPClient或者OKHTTP等三方库。从目前来看，jdk10对于这块的功能支持还是不错的，目前版本已经支持HTTP1.1、HTTP2、websocket等常用的基于http的协议，并支持了了同步、异步、响应式等交互方式。当前版本的实现还是比较简单，没有对于常用restful、content-type的封装支持。
个人猜测，很可能这个场景的支持是为了Launch Single-File Source-Code Programs脚本开发支持的，哈哈~~

动态文件常量/低开销的 Heap Profiling

　　动态文件常量主要增加了 CONSTANT_Dynamic　这种常量池形式，主要用于丰富常量池API相关接口，并优化常量生成策略。

　　低开销的 Heap Profiling,提供一种低开销的获取Java 堆对象使用信息的JVM接口。之前的堆都是基于事件进行callback，这个接口的提供可以更好的实现对于jvm内存的分析。
　　接口定义如下

　　jvmtiError  SetHeapSamplingInterval(jvmtiEnv* env, jint sampling_interval)

　　//使用示例
　　jvmti->SetEventNotificationMode(jvmti, JVMTI_ENABLE, JVMTI_EVENT_SAMPLED_OBJECT_ALLOC, NULL)

TLS 1.3支持

　　TLS 主要是对于https的新标准的一些支持，主要包括

• Protocol version negotiation
• TLS 1.3 full handshake
• TLS 1.3 session resumption
• TLS 1.3 key and iv update
• TLS 1.3 updated OCSP stapling
• TLS 1.3 backward compatibility mode
• TLS 1.3 required extensions and algorithms
• RSASSA-PSS signature algorithms (8146293)

　　详细可以参考rfc8446

延伸阅读
https://kinsta.com/blog/tls-1-3/#tls-1.3-vs-tls-1.2

删除 Java EE 和 CORBA 模块

　　由于EJB方案的繁琐和低效率一直以来备受诟病，而当EJB方案在与Spring分道扬镳之后，EJB方案全面衰落。这在如今我们在一些Spring书籍中还有对于一些EJB的描述。
　　EJB在我来看是希望能从标准方面制定一款大而全的产品，但实际上全面的覆盖带来的是，繁琐的规则，冗余的代码，难以遵守的设计规范。因此从厂商来说，支持EJB就需要付出巨大的生产成本，更不要说正式投入生产环境。事实上Spring正式由于理念上与EJB的不同，采用了轻快小的方案，赢得了众多用户的支持。并且从历史来看，复杂的设计意味着高昂的学习成本，生产成本，维护成本，Spring凭借此赢得了与EJB的竞争，但在Spring 3以后迅速的发展让Spring加入了众多的细化组件，此时Spring慢慢变得更为复杂。在后续SpringBoot诞生，极大的简化了Spring的配置以及对于Spring众多组件的管理。这一点来看轻快小又是一次历史的选择了。

　　由于Spring主流化，Java EE逐渐失去市场，从JDK剥离JavaEE虽然不舍但却是一种正确的选择。

　　在我看来，我反而希望JDK开发团队能像scala团队一样，对于一些已经主流甚至接近标准的三方库，能给予官方支持进行标准化，就像scala对于play的支持一样。

参考
Open JDK 11
Oracle Java EE
rfc8446
温故知新：EJB与Spring的比较
Java 11正式发布，新特性解读