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
本群提供免费的学习指导 架构资料 以及解答
不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导
网友评论