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)。主打特点:低停顿时间
