Java14新特性
instanceof的模式匹配(预览)
这个特性很有意思,因为它为更为通用的模式匹配打开了大门。模式匹配通过更为简便的语法基于一定的条件来抽取对象的组件,而 instanceof 刚好是这种情况,它先检查对象类型,然后再调用对象的方法或访问对象的字段。
有了该功能,可以减少Java程序中显式强制转换的数量,从而提高生产力,还能实现更精确、简洁的类型安全的代码。
// 14之前的方式,判断之后需要强转类型
if(obj instanceof String) {
String str = (String)obj;
str.contains("a")
}
// 14之后的方式,不需要强转,实际发生了转换
if(!(obj instanceof String str)) {
str.contains("a")
}
NullPointerException(预览)
Java解决NPE的方式
- Java8中提供了Optional,为null进行了一层封装,日常配合Stream还是比较好用的
- Java14中的Helpful NullPointerExceptions
- 该特性可以更好地提示哪个地方出现的空指针,需要通过-XX:+ShowCodeDetailsInExceptionMessages开启
- 在未来的版本中,这个特性可能会默认启用
- 这个增强特性不仅适用于方法调用,只要会导致 NullPointerException 的地方也都适用,包括字段的访问、数组的访问和赋值
Record(预览)
Java代码中开发人员想要创建纯数据载体类(plain data carriers)通常都必须编写大量低价值、 重复的、容易出错的代码。如:构造函数、getter/setter、equals()、hashCode()以及 toString()等,以至于很多人选择使用IDE的功能来自动生成这些代码。还有一些开发会选择使用一些第三方类库,如Lombok等来生成这些方法,从而会导致代码臃肿和糟糕的调试性
Java14也许最令人兴奋,同时也是最令人惊讶的创新就是:Record类型的引入 。
- 使用record来减少类声明语法,效果类似 lombok 的 @Data 注解,Kotlin中的data class。它们的共同点是类的部分或全部状态可以直接在类头中描述,并且这个类中只包含了纯数据而已
- 该预览特性提供了一种更为紧凑的语法来声明类。值得一提的是,该特性可以大幅减少定义类似数据类型时所需的样板代码
switch表达式
- 这是12和13中的预览特性,现在是正式特性了
- 该特性规定,switch可以当作语句使用,也可以当作表达式使用
- 具体情况: 使用->来替代以前的:+break;另外还提供了yield来在block中返回值
文本块(预览)
在Java中,通常需要使用String类型表达HTML,XML,SQL或JSON等格式的字符串, 在进行字符串赋值时需要进行转义和连接操作,然后才能编译该代码,这种表达方式难以阅读并且难以维护。13中引入了文本块,14对其功能进行了增强。引用文本块的目的:
- 简化跨越多行的字符串,避免对换行等特殊字符进行转义,简化编写Java程序
- 增强Java程序中用字符串表示的其他语言的代码的可读性
- 解析新的转义序列
弃用ParallelScavenge和SerialOld GC组合
- JDK官方给出将这个GC组合标记为Deprecate的理由是:这个GC组合需要大量的代码维护工作,并且,这个GC组合很少被使用。因为它的使用场景应该是一个很大的 Young区配合一个很小的Old区,这样的话,Old区用SerialOldGC去收集时停顿时间 我们才能勉强接受。
- 废弃了parallel young generation GC与SerialOld GC的组合( -XX:+UseParallelGC与- XX:-UseParallelOldGC配合开启),现在使用-XX:+UseParallelGC -XX:- UseParallelOldGC或者-XX:-UseParallelOldGC都会出现告警如下:
Java HotSpot(TM) 64-Bit Server VM warning: Option UseParallelOldGC was deprecated in version 14.0 and will likely be removed in a future release.
删除CMS垃圾回收器
- 该来的总会来,自从G1(基于Region分代)横空出世后,CMS在JDK9中就被标记为 Deprecate了(JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector)
- CMS的弊端 :
- 会产生内存碎片,导致并发清除后,用户线程可用的空间不足。
- 既然强调了并发(Concurrent),CMS收集器对CPU资源非常敏感
- CMS 收集器无法处理浮动垃圾
- 上述的这些问题,尤其是碎片化问题,给你的JVM实例就像埋了一颗炸弹。说不定哪次就在你的业务高峰期来一次FGC。当CMS停止工作时,会把Serial Old GC 作为备选方 案,而Serial Old GC 是JVM中性能最差的垃圾回收方式,停顿个几秒钟,上十秒都有可能
- 移除了CMS垃圾收集器,如果在JDK14中使用-XX:+UseConcMarkSweepGC的话, JVM不会报错,只是给出一个warning信息。
- 现在G1回收器已成为默认回收器好几年了。
- 我们还看到了引入了两个新的收集器: ZGC (JDK11出现)和Shenandoah (open jdk12)。主打特点:低停顿时间