Inside Java Newscast #1 解读（下）

注意使用处于孵化的 Java 特性需要加上额外的启动参数将模块暴露，这里是--add-modules jdk.incubator.vector，需要在 javac 编译和 java 运行都加上这些参数，使用 IDEA 即：

测试结果：

Benchmark               Mode  Cnt         Score         Error  Units
VectorTest.testScalar  thrpt   10   7380697.998 ± 1018277.914  ops/s
VectorTest.testVector  thrpt   10  37151609.182 ± 1011336.900  ops/s

其他使用，请参考：fizzbuzz-simd-style，这是一篇比较有意思的文章（虽然这个性能优化感觉不只由于 SIMD，还有算法优化的功劳，哈哈）

Foreign Linker API

相关 JEP：

• JEP 389: Foreign Linker API (Incubator)
• JEP 412: Foreign Function & Memory API (Incubator)：在 Java 17 中，和 Foreign Linker API 整合到了一起
• JEP 419: Foreign Function & Memory API (Second Incubator)：位于 Java 18 中

通过这个 API，我们可以使用纯 Java 代码来调用系统的库，例如使用 Java 代码弹出一个 Windows 提示框：

以上例子来自于 https://headcrashing.wordpress.com/2021/02/06/spare-keystrokes-with-the-record-keyword-modern-java-jdk-16-head-crashing-informatics-26-2/ ，感兴趣的可以查看下

Foreign-Memory Access API

• JEP 370: Foreign-Memory Access API (Incubator)
• JEP 383: Foreign-Memory Access API (Second Incubator)
• JEP 393: Foreign-Memory Access API (Third Incubator)
• JEP 412: Foreign Function & Memory API (Incubator)：在 Java 17 中，和 Foreign Linker API 整合到了一起
• JEP 419: Foreign Function & Memory API (Second Incubator)：位于 Java 18 中

很多流行的高性能 Java 框架和中间件使用了堆外内存，但是目前 Java 中操作堆外内存的 API 不够完善：

• ByteBuffer API 可以提供直接内存的访问 (DirectBuffer 还有 MMAP Buffer)，但是大小受限（2 GB，原因因为 Buffer classes limited by 32-bit addressing），并且有很多问题遗留了很多年未能解决，例如：MappedByteBuffer.release()/close() to release system resources，Please make DirectByteBuffer performance enhancements, Add absolute bulk put and get methods
• Unsafe API：性能很高，可以被 JIT 优化，但是没有限制内存访问，哪一块内存都能访问，如果访问到一块已经释放的内存，就会导致 JVM 崩溃。
• JNI 调用：性能较差，因为无法被 JIT 优化（例如方法内联）

如果这些 API 开发完成，使用 Java 操作内存将更加容易理解和高效

Java 16 – JDK Flight Recorder

JFR 是我最喜欢的 Java 特性功能，我针对 JFR 写了很多篇文章，使用 JFR 定位过很多性能瓶颈以及线上问题，请参考以下系列或者文章：

• JFR 全解系列
• JFR导致的雪崩问题定位与解决
• JFR 定位因为 SSL 导致 CPU Load 飚高的问题
• 一次鞭辟入里的 Log4j2 日志输出阻塞问题的定位
• spring-data-redis 上百万的 QPS 压力太大连接失败，我 TM 人傻了

Java 16 中，针对 JFR， 在 Java 14 引入的 JFR Stream 的基础上，增加了通过 JMX 暴露的 JFR Stream。原来我们只能内部消费处理 JFR Event，现在可以通过 JMX 远程消费 JFR Event：JDK-8253898: JFR: Remote Recording Stream

Java 16 – jpackage

相关 JEP：

• 已废弃 JEP 311: Java Packager API & CLI
• JEP 343: Packaging Tool (Incubator)
• JEP 392: Packaging Tool

这个是将 Java 程序打包成可安装包的工具，目前支持的操作系统以及格式包括：

• Linux: deb and rpm
• macOS: pkg and dmg
• Windows: msi and exe

可以参考这个文章试用下：Building Self-Contained, Installable Java Applications with JEP 343: Packaging Tool

Java 16 - Performance

性能相关的更新有很多

Hotspot 实现 Elastic Metaspace

相关 JEP： Elastic Metaspace

原来的元空间实现中，每个类加载器占用一个单独的元空间抽象，当类加载器被回收后，这块内存被释放但是不会退还给系统而是继续给其他类加载器复用，元空间的系统内存占用只会一直增大不会缩小，也就是不会将内存退还给系统。现在优化了这一点，可以动态伸缩元空间。这块的详细源码分析，我会在之后出一期类似于 全网最硬核 TLAB 解析 的文章解析这块。

G1 和 Parallel GC 优化

如果想详细了解这块的优化，可以参考这篇文章：JDK 16 G1/Parallel GC changes

ZGC 优化

相关 JEP：

• JEP 376: ZGC: Concurrent Thread-Stack Processing

ZGC 本来已经基本将 GC 每个阶段都做成并发的了，GC 根扫描还是需要 STW。这个 JEP 优化了 GC 根扫描中的线程栈扫描，让这个扫描也可以 “半并行化” 了。这块我也会在日后进行详细的分析。

Shenandoah GC 优化

• Shenandoah: should not block pacing reporters
• Shenandoah: reconsider free budget slice for marking
• Shenandoah: pacer should wait on lock instead of exponential backoff
• Shenandoah: support manageable SoftMaxHeapSize option
• Shenandoah: Concurrent weak reference processing
• Shenandoah: "adaptive" heuristic is prone to missing load spikes

Java 16 – Security

关于安全性相关的优化，请参考：JDK 16 Security Enhancements

Java 16 – Deprecations/Limitations

Primitive Wrapper Warnings

相关 JEP：

• JEP 390: Warnings for Value-Based Classes

这是一个令人激动的更新，是为了我期待已久的 Project Valhala 做铺垫的（对，就是我之前把 Record 误会了的那个）。

目前，原始类型的封装类型类（例如 Integer ）的构造器标记为了过期，并且会在将来的版本被移除，用他们里面的静态方法 valueOf() 代替。

我单独写了一篇文章来分析这个，参考：JEP解读与尝鲜系列4 - Java 16 中对于 Project Valhalla 的铺垫

Strong Encapsulation By Default

相关 JEP：

• JEP 396: Strongly Encapsulate JDK Internals by Default
• JEP 403: Strongly Encapsulate JDK Internals：Java 17 发布的，已经完全去掉了 --illegal-access，如果使用，会有 OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=warn; support was removed in 17.0 的提示。

为了推进 Java 模块化，针对 --illegal-access 的特性进行了修改。Java 16 之前默认是 permit，遇到访问没有开放的包会在第一次有提示，但是还是可以正常运行：

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by j9ms.internal.Nimbus
  (file:...) to constructor NimbusLookAndFeel()
WARNING: Please consider reporting this
  to the maintainers of j9ms.internal.Nimbus
WARNING: Use --illegal-access=warn to enable warnings
  of further illegal reflective access operations
WARNING: All illegal access operations will be denied
  in a future release

Java 16 则是 deny。即默认禁止非法包访问，用户可以通过启动参数 --illegal-access=permit 修改。Java 17 则是移除了这个参数，加上这个启动参数也无效了，会有提示并且反射访问内部未暴露的包会报错，例如：

var dc = ClassLoader.class.getDeclaredMethod("defineClass",
    String.class,
    byte[].class,
    int.class,
    int.class);
dc.setAccessible(true);

使用启动参数--illegal-access=warn 运行：

OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=warn; support was removed in 17.0
Exception in thread "main" java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed module @378bf509
  at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
  at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
  at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
  at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)

但是，通过启动参数 --add-opens java.base/java.lang=ALL-UNNAMED 还是可以打破封包控制.