如何评价 Java11？

JDK11作为LTS长期支持版本, 在今后几年会逐渐像JDK8一样流行, 由于下一个LTS版本要等待3年后的JDK17了.

从JDK11累积了JDK9,10带来的大量特性(以下特性评论包括了9和10的特性), 不过对很多初级开发者而言, 语法层面改进的并不多, 这也是Java一贯的保守风格(非贬义).

最大的变化是JDK9就加入的板块化, 同时也继续向前兼容非板块化的工程.

语法层面最大的改进是加入了大多语言都有的”var”, 而且还很保守地没加入”val”.

这个版本是Java有史以来最大的一次瘦身, 移除了Demos and Samples,移除了不常用的GC搭配,移除了jhat和javah,移除了JavaEE和JavaFX(体积不小,还自带浏览器内核),移除了VisualVM和MissionControl(都是不小的),移除了Derby数据库. 当然这些都是由于放到现代已经没什么用了,有更好的替代品,或者独立出去了(同时也为了更快的升级迭代).

瘦身后的安装包体积较JDK9/10大幅缩减, 甚至比JDK8还小了.

现在也不再单独发JRE, Server JRE这些小体积版本, 从安装后的文件中可以看到传统分离的JRE和JDK现在已经合并了, Java的编译部分已经可以看成是运行时的一部分了.

现在也不再推出32位版本, 当然是基于32位市场目前已经很小的形势下, 想继续用32位JDK只能用JDK8了. 另外ARM平台的JDK貌似不公开发布了.

以上的版本合并和精简瘦身后, Oracle的JDK和OpenJDK的差别更小, 之间的可替代性也更好.

GC方面, G1已成默认(的确对大部分应用来说均衡性最好,也不用多考虑手动调节), G1较JDK8有少量改进,不是很大,继续用JDK8也不用太在意. 更多人关注的是新出的ZGC, 首先要提醒这目前只是实验品,别轻易在生产用途中使用(想想JDK6时敢不敢用G1).

ZGC的优点主要是停顿极短到几乎可以无视的程度, 而且跟堆的规模关系不大, 因而最适合用在对停顿及其敏感和超大堆的场合.

再说说目前ZGC的缺点, GC性能(吞吐量)偏低, 尤其是堆较小的情况, 我个人评测的结果是CMS是1倍时间的话, G1是1.1倍时间, ZGC是1.6倍左右的时间(根据堆大小和分配速度不同有较大的浮动,大致在1.2到1.8倍之间); 不支持分代(新生代垃圾较多的情况优势不大); 不支持压缩指针(由于需要用到指针的少量位,不过对较大的堆来说不算问题了)

GC这块没有银弹, ZGC有优点就会有相应的缺点, 不停顿的代价就是把停顿需要做的事分担到引用(指针)的读写上了, 尽管每次读写只多了几个指令, 但大量读写就把性能问题凸显了.

我个人建议是ZGC只用在对停顿要求极端苛刻的情况和堆特别大的(>32G). 除此以外, <=512M的堆依然建议用ParrellelGC, 512M~4G用CMS(可惜预计后续版本要移除了), 4G~32G用G1.

AOT方面也有不少支持, 不过对服务器开发来说意义不大, AOT的优化能力理论上不会超越JIT. AOT的好处只是启动快, 对于频繁启动的短生命期程序来说有些用(如shell那些命令); 另外AOT也会明显加大反编译的难度, 这个只对用户端运行闭源应用,或者者交付给只有使用权的用户有用.

最后再说说板块化, 习惯了之前JDK开发的人来说, 现阶段体会不到板块化有多大用, 要说减小体积,JRE本身的大小在现代的应用来说也不算什么.

安装目录多了个jmods目录, 包含了70多M的jmod压缩包, 占了JDK安装包的接近一半的体积了, jmod文件本质上就是把JRE做了裁剪分割(有些板块感觉分的太细了),其中主要是可执行程序和class文件. 最基本的jmod就是java.base.jmod, 包含了JVM的核心.

假如JDK安装包移除了jmods, 也移除了40多M的源码压缩包, 就不到50M了, 用7z可以压到30多M, 包括完整的JRE(含编译功能), 可以说相当瘦身了(java.base.jmod也有十多M).

另外, 细心的人会发现之前的rt.jar和tools.jar已经不存在了, 换成了modules和ct.sym文件, 预计是优化整合的class文件结构, 可以加载得更快吧(同时也利于压缩).

至于licence问题, 绝大部分普通的开发者都没必要担心, 大不了转成OpenJDK也不麻烦. 只需别像Google那样对Java/JVM本身做魔改就行. Oracle提供的安装包还是很方便的.

欢迎Java工程师朋友们加入Java进阶高级架构群：855355016

本群提供免费的学习指导 架构资料 以及解答

不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导