大前端2022版全面升级完结

download：大前端2022版全面升级完结

Java 17 晋级指南
分为几个局部：

编译相关
参数迁移相关
运转相关

编译相关
JEP 320
在 Java11 中引入了一个提案 JEP 320: Remove the Java EE and CORBA Modules
移除了 Java EE and CORBA 的模块，假如项目中用到需求手动引入。比方代码中用到了 javax.annotation.* 下的包：
import javax.annotation.PreDestroy;
public abstract class FridayAgent

@PreDestroy
public void destroy() {
    agentClient.close();
}

}

在编译时会找不到相关的类。这是由于 Java EE 曾经在 Java 9 中被标志为 deprecated，Java 11 中被正式移除，能够手动引入 javax 的包：

javax.annotation
javax.annotation-api
1.3.2

运用了 sun.misc.* 下的包
比方 sun.misc.BASE64Encoder，这个简单，交换一下工具类即可。
[ERROR] symbol: class BASE64Encoder
[ERROR] location: package sun.misc

netty 低版本运用了 sun.misc.*，编译错误信息如下
Caused by: java.lang.NoClassDefFoundError: Could not initialize class io.netty.util.internal.PlatformDependent0

    at io.netty.util.internal.PlatformDependent.getSystemClassLoader(PlatformDependent.java:694) ~[netty-all-4.0.42.Final.jar!/:4.0.42.Final]

对应的源码如下：
/**

• The {@link PlatformDependent} operations which requires access to {@code sun.misc.*}.
  */

final class PlatformDependent0 {
}

https://github.com/netty/nett...

lombok 运用了 com.sun.tools.javac.* 下的包
错误信息如下：

Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on project encloud-common: Fatal error compiling: java.lang.ExceptionInInitializerError: Unable to make field private com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors com.sun.tools.javac.processing.JavacProcessingEnvironment.discoveredProcs accessible: module jdk.compiler does not "opens com.sun.tools.javac.processing" to unnamed module

假如你的项目中运用 lombok，而且是低版本的话，就会呈现，lombok 的原理是在编译期做一些手脚，用到了 com.sun.tools.javac 下的文件，晋级到最新版能够处理。ps，个人很不喜欢 lombok， 调试的时分代码和 class 对不上真的很恶心。

org.projectlombok
lombok

1.18.24

kotlin 版本限制
我们后端在很多年前就 all-in Kotlin，Kotlin 的晋级也是我们的重中之重。

[ERROR] Failed to execute goal org.jetbrains.kotlin:kotlin-maven-plugin:1.2.71:compile (compile) on project encloud-core: Compilation failure

[ERROR] Unknown JVM target version: 17
[ERROR] Supported versions: 1.6, 1.8
Kotlin 在 1.6.0 版本开端支持 Java17 的字节码，低于 1.6.0 的编译会直接报错
废弃依赖剖析
能够用 jdeps --jdk-internals --multi-release 17 --class-path . encloud-api.jar 来做项目的依赖剖析

这样你就能够晓得哪些库需求做晋级了。
参数迁移
什么是 Unified Logging
在 Java 范畴，有广为人知的日志框架，slf4j、log4j 等，这些框架提供了统一的编程接口，让用户能够经过简单的配置完成日志输出的个性化配置，比方日志 tag、级别（info、debug 等）、上下文（线程 id、行号、时间等），在 JVM 内部之前不断缺乏这样的标准，于是出来了 Unified Logging，完成了日志格式的大一统，这就是我们接下来要引见的重点 Unified Logging。
我们接触最多的是 gc 的日志，在 java8 中，我们配置 gc 日志的参数是 -Xloggc:/tmp/gc.log。在 JVM 中除了 GC，还有大量的其它相关的日志，比方线程、os 等，在新的 Unified Logging 日志中，日志输出的方式变卦为了 java -Xlog:xxx，GC 不再特殊只是做为日志的一种存在方式。
java -Xlog -version

输出结果如下：

能够看到日志输出里，不只有 GC 相关的日志，还有 os 线程相关的信息。事实上 java 的日志的消费者有十分多局部，比方 thread、class load、unload、safepoint、cds 等。

归根到底，日志打印，需求答复分明三个问题：

what：要输出什么信息（tag），以什么日志级别输出（level）
where：输出到哪里（console 还是 file）
decorators：日志如何

输出什么信息（selectors）
首先来看 what 的局部，如何指定要输出哪些信息，这个在 JVM 内部被称之为 selectors。
JVM 采用的是 =的方式来表示 selectors，默许状况下，tag 为all，表示一切的 tag，level 为 INFO，java -Xlog -version 等价于下面的方式
java -Xlog:all=info -version

假如我们想输出tag 为 gc，日志级别为 debug 的日志，能够用 java -Xlog:gc=debug 的方式：
$ java -Xlog:gc=debug -version
0.023s[gc] Using G1
0.023s[gc] ConcGCThreads: 3 offset 22
0.023s[gc] ParallelGCThreads: 10
0.024s[gc] Initialize mark stack with 4096 chunks, maximum 524288

这样就输出了 tag 为 gc，级别为 debug 的日志信息。
不过这里有一个比拟坑的点是，这里的 tag 匹配规则是准确匹配，假如某条日志的 tag 是 gc,metaspace，经过上面的规则是匹配不到的，我们能够手动指定的方式来输出。
$ java -Xlog:gc+metaspace -version

0.022s[gc,metaspace] CDS archive(s) mapped at: ... size 12443648.
0.022s[gc,metaspace] Compressed class space mapped at: reserved size:...
0.022s[gc,metaspace] Narrow klass base:..., Narrow
klass shift: 0, Narrow klass range: 0x100000000

这里的 selector 也是能够停止组合的，不同的 selector 之间用逗号分隔即可。比方同时输出 gc 和 gc+metaspace 这两类 tag 的日志，就能够这么写：
$ java -Xlog:gc=debug,gc+metaspace -version

0.020s[gc] Using G1
0.020s[gc] ConcGCThreads: 3 offset 22
0.020s[gc] ParallelGCThreads: 10
0.020s[gc] Initialize mark stack with 4096 chunks, maximum 524288
0.022s[gc,metaspace] CDS archive(s) mapped at:
0.022s[gc,metaspace] Compressed class space mapped at:
0.022s[gc,metaspace] Narrow klass base: 0x0000000800000000

当然这么搞是很费事的，JVM 提供了通配符 * 来处理准确匹配的问题，比方我们想要一切 tag 为 gc 的日志，能够这么写：
$ java -Xlog:gc*=debug -version

0.024s[gc,heap] Minimum heap 8388608
0.024s[gc ] Using G1
0.024s[gc,heap,coops] Heap address: 0x0000000707400000
0.024s[gc ] ConcGCThreads: 3 offset 22
0.024s[gc ] ParallelGCThreads: 10
0.024s[gc ] Initialize mark stack with 4096 chunks
0.024s[gc,ergo,heap ] Expand the heap. requested expansion amount:
0.025s[gc,heap,region] Activate regions [0, 125)
0.025s[gc,ihop ] Target occupancy update: old: 0B, new: 262144000B
0.025s[gc,ergo,refine] Initial Refinement Zones: green: 2560
0.026s[gc,task ] G1 Service Thread
0.026s[gc,task ] G1 Service Thread (Periodic GC Task) (register)
0.026s[gc,init ] Version: 17.0.3+7 (release)
...

假如只想要 INFO 级别的日志，则能够省略 level 的设置，运用 java -Xlog:gc* -version 即可。
假如想晓得有哪些个性化的 tag 能够选择，能够用 java -Xlog:help 来找到一切可用的 tag。

阶段性小结

第二局部：输出到哪里（output）
默许状况下，日志会输出到 stdout，jvm 支持以下三种输出方式：

stdout
stderr
file

普通而言我们会把日志输出到文件中，便当后续进一步剖析
-Xlog:all=debug:file=/path_to_logs/app.log

还能够指定日志切割的大小和方式
-Xlog:gc*:file=/path_to_logs/app.log:filesize=104857600,filecount=5

第三局部：日志 decorators
每条日志除了正常的信息以外，还有不少日志相关的上下文信息，在 jvm 中被称为 decorators，有下面这些可选项。

OptionDescriptiontimeCurrent time and date in ISO-8601 format.uptimeTime since the start of the JVM in seconds and milliseconds (e.g., 6.567s).timemillisThe same value as generated by System.currentTimeMillis().uptimemillisMilliseconds since the JVM started.timenanosThe same value as generated by System.nanoTime().uptimenanosNanoseconds since the JVM started.pidThe process identifier.tidThe thread identifier.levelThe level associated with the log message.tagsThe tag-set associated with the log message.
比方能够用 java -Xlog:all=debug:stdout:level,tags,time,uptime,pid -version 选项来打印日志。
2022-06-15T19:54:01.529+08005235[os,thread] Thread attached
2022-06-15T19:54:01.529+08005235[os,thread] Thread 5237 stack...
2022-06-15T19:54:01.529+08005235[perf,datacreation]

Unified Logging 小结
输出格式如下：
-Xlog:[selectors]:[output]:decorators

selectors 是多个 tag 和 level 的组合，起到了 what（过滤器）的作用，格式为 tag1+tag2...=level
decorators 是日志相关的描绘信息，也能够了解为上下文
output 是输出相关的选项，普通我们会配置为输出到文件，按文件大小切割

这里补充一个学问点，就是默许值：

tag：all
level：info
output：stdout
decorators: uptime, level, tags

GC 参数迁移
能够看到 GC 相关的参数都曾经收拢到 Xlog 下，以前的很多 Java8 下的参数曾经被移除或者标志为过时。
比方 PrintGCDetails 曾经被 -Xlog:gc* 取代：
java -XX:+PrintGCDetails -version

0.001s[gc] -XX:+PrintGCDetails is deprecated. Will use -Xlog:gc* instead.

常见的标志为废弃的参数还有 -XX:+PrintGC 和 -Xloggc:，迁移前后的参数如下：

旧参数新参数-XX:+PrintGCDetails-Xlog:gc*-XX:+PrintGC-Xlog:gc-Xloggc:-Xlog:gc:file=
除此之外，大量的 GC 的参数被移除，比方常用的参数 -XX:+PrintTenuringDistribution，Java17 会回绝启动
java -XX:+PrintTenuringDistribution -version
Unrecognized VM option 'PrintTenuringDistribution'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

更细致的移除的参数如下
CMSDumpAtPromotionFailure,
CMSPrintEdenSurvivorChunks,
GlLogLevel,
G1PrintHeapRegions,
G1PrintRegionLivenessInfo,
G1SummarizeConcMark,
G1SummarizeRSetStats,
G1TraceConcRefinement,
G1TraceEagerReclaimHumongousObjects,
G1TraceStringSymbolTableScrubbing,
GCLogFileSize, NumberofGCLogFiles,
PrintAdaptiveSizePolicy,
PrintclassHistogramAfterFullGC,
PrintClassHistogramBeforeFullGC,
PrintCMSInitiationStatistics
PrintCMSStatistics,
PrintFLSCensus,
PrintFLSStatistics,
PrintGCApplicationConcurrentTime
PrintGCApplicationStoppedTime,
PrintGCCause,
PrintGCDateStamps,
PrintGCID,
PrintGCTaskTimeStamps,
PrintGCTimeStamps,
PrintHeapAtGC,
PrintHeapAtGCExtended,
PrintJNIGCStalls,
PrintOldPLAB
PrintParallel0ldGCPhaseTimes,
PrintPLAB,
PrintPromotionFailure,
PrintReferenceGC,
PrintStringDeduplicationStatistics,
PrintTaskqueue,
PrintTenuringDistribution,
PrintTerminationStats,
PrintTLAB,
TraceDynamicGCThreads,
TraceMetadataHumongousAllocation,
UseGCLogFileRotation,
VerifySilently

这些移除的参数大局部都能在新的日志体系下找到对应的参数，比方 PrintHeapAtGC 这个参数能够用 -Xlog:gc+heap=debug 来替代
$ java -Xlog:gc+heap=debug -cp . G1GCDemo01

0.004s[gc,heap] Minimum heap 8388608 Initial heap 268435456 Maximum heap
hello, g1gc!
12.263s[gc,heap] GC(0) Heap before GC invocations=0 (full 0):
12.265s[gc,heap] GC(0) garbage-first heap
12.265s[gc,heap] GC(0) region size 2048K, 1 young (2048K)
12.265s[gc,heap] GC(0) Metaspace used 3678K
12.265s[gc,heap] GC(0) class space used 300K
12.280s[gc,heap] GC(0) Uncommittable regions after shrink: 124