为什么选择 Java11
●容器环境支持，GC 等领域的增强，仅通过切换到 Java 11 就有 16％ 的改进
●进行了瘦身，更轻量级，安装包体积小
●JDK11 是一个长期支持版
Java11 相对于 Java8 的一些新特性
变量类型推断
Var 关键字:新版 Java 引入全新的类型关键字 var,用 var 来定义的变量像 python 一样不用写具体类型，编译器能根据实际赋值来自动推断变量的类型
普通局部变量
For 循环中使用
Var 结合泛型
注意：var 不能在类成员变量类型和方法返回值类型使用
增强 api
String 增强
新版本增加了一些更方便的字符串处理的 API
集合增强
增加了一些更加方便的创建和复制集合类型的 API
●of() @since 9
●copyOf() @since 10
Stream 增强
Java 8 中的流已经很强大了，而且只要涉及到 IO，只要涉及到对一系列数据进行操作，都会用到流。
当然了，Java 9 对其操作继续增强，这次的改进主要是如何设置停止流的条件上。为此在流的实例上提供了四个方法 takeWhile(Predicate Interface) 、iterate 、ofNullable 和 dropWhile(Predicate Interface)
HTTP Client API
新版 jdk 官方自带 httpClient,支持发送同步、异步的 http 请求
完全支持 Linux 容器(包括 docker)
许多运行在 Java 虚拟机中的应用程序(包括 Apache Spark 和 Kafka 等数据服务以及传统的企业应用程序)都可以在 Docker 容器中运行。但是在 Docker 容器中运行 Java 应用程序一直存在一个问题，那就是在容器中运行 JVM 程序在设置内存大小和 CPU 使用率后，会导致应用程序的性能下降。这是因为 Java 应用程序没有意识到它正在容器中运行。随着 Java 10 的发布，这个问题总算得以解决，JVM 现在可以识别由容器控制组(cgroups)设置的约束。可以在容器中使用内存和 CPU 约束来直接管理 Java 应用程序，其中包括：
●遵守容器中设置的内存限制
●在容器中设置可用的 CPU
●在容器中设置 CPU 约束
升级过程中遇到的一些问题
javax.xml.bind 不存在
Java11 删除了 Java EE modules，其中就包括 java.xml.bind (JAXB)。
启动时警告：
解决方案：手动添加相关依赖。
javax.xml.bind
jaxb-api
2.3.0
com.sun.xml.bind
jaxb-core
2.3.0
com.sun.xml.bind
jaxb-impl
2.3.0
编译报错
由于 JDK11 中删除了 sum.misc 包，编译时会报错：sun.misc.BASE64Encoder、sun.misc.BASE64Decoder 找不到类
解决方式：使用
java.util.Base64.Encoderjava.util.Base64.Decoder 替换
服务启动报错
1.JDK11 下使用最新的 Greenwich 版本的 eureka 默认情况下必定无法启动，日志提示内嵌的 Tomcat 没法启动
解决方式：加入 JAXB 依赖
org.glassfish.jaxb
jaxb-runtime
2.3.2
2.JDK9 以后的版本，模块化的概念去除了 JAXB(默认没有加载)，需做接入声明
解决方式：加入 JAXB 依赖
javax.xml.bind
jaxb-api
com.sun.xml.bind
jaxb-impl
2.3.0
org.glassfish.jaxb
jaxb-runtime
2.3.0
javax.activation
activation
1.1.1
趋势
从 Java 11 开始，OpenJDK major version 的发布间隔差不多是半年，不用全部都要去关注，都是追赶，但是 LTS 版本，需要去追赶，去升级，Java11 就是最新的 LTS 版本，下一个或者再一下 major version，很可能又是一个 LTS 版本；虽然目前使用 Java 8 都挺好的，现实是 Java 8 的一些特性会被往后移植，但是后续版本的特性和优化不会再被集成到 Java 8 中了。
————————————————
版权声明：本文为知乎博主「邓先生」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
***