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
删除 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正式发布，新特性解读
