jvm性能调优

⽤于调⽤对象的实例⽅法，根据对象的实际类型进⾏分派(虚⽅法分派)，这也是 Java 语⾔中最常⻅的⽅法分派⽅式。

⽤于调⽤接⼝⽅法，它会在运⾏时搜索⼀个实现了这个接⼝⽅法的对象，找出适合的⽅法进⾏调⽤。

⽤于调⽤⼀些需要特殊处理的实例⽅法，包括实例初始化⽅法私有⽅法和⽗类⽅法。

⽤于调⽤类静态⽅法(static ⽅法)。

⽤于在运⾏时动态解析出调⽤点限定符所引⽤的⽅法。并执⾏该⽅法。前⾯四条调⽤指令的分派逻辑都固定在 Java 虚拟机内部，⽤户⽆法改变，⽽invokedynamic指令的分派逻辑是由⽤户所设定的引导⽅法决定的。 Java 从诞⽣到现在，只增加过⼀条指令，就是invokedynamic。⾃ JDK7 ⽀持并开始进<br>⾏改进，这也是为 JDK8 实现Lambda表达式⽽做的技术储备。

appClassLoader

extClassLoader

Bootstrap

<br>

preDefineClass

<br>

先进后出结构

对象的创建与内存分配

依据对象年龄分代思想将堆内存分为

对象<br>

引用类型

如何判断一个类是无用的类<br>

未加载到元空间前叫静态常量池

最小堆内存

最大堆内存

设置年轻代内存大小

设置栈大小

设置元空间初始化大小默认21M

设置最大元空间大小

jdk1.8默认收集器

(-XX:ParallelGCThreads)指定收集线程数一般与cpu核数相同即可<br>

Parallel Scavenge收集器<font color="#e74f4c">关注点是吞吐量</font>（高效率的利用CPU）。CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。<font color="#e74f4c">所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值</font>。

一款针对老年代的垃圾收集器，新生代默认用parNewGC

早期低延迟收集探索后续在这基础上诞生了G1和shenandoah<br>

初始标记

并发标记

重新标记

并发清理

并发重置

<br>

并发收集、低停顿

对CPU资源敏感（会和服务抢资源）

无法处理浮动垃圾(在<font color="#e74f4c">并发标记和并发清理</font>阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)

它使用的回收算法-“标记-清除”算法会导致收集结束时会有<font color="#e74f4c">大量空间碎片产生</font>，当然通过参数-<br>XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理

执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，<font color="#e74f4c">特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop theworld，用serial old垃圾收集器来回收</font>

1. -XX:+UseConcMarkSweepGC：启用cms

2. -XX:ConcGCThreads：并发的GC线程数

3. -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）

4. -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次<br>

5. -XX:<font color="#e74f4c">CMSInitiatingOccupancyFraction</font>: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）

6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整<br>

7. -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，降低CMS GC标记阶段(也会对年轻代一起做标记，如果在minor gc就干掉了很多对垃圾对象，标记阶段就会减少一些标记时间)时的开销，一般CMS的GC耗时 80%都在标记阶段<br>

8. -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW

9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快

并发标记（Concurrent Marking）：同CMS的并发标记

最终标记（Remark，STW）：同CMS的重新标记

筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数<font color="#e74f4c"> -XX:MaxGCPauseMillis</font>指定)来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(Collection Set，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region

YoungGC<br>

MixedGC<br>

Full GC<br>

并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短StopThe-World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念

空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的

可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集<br>

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)

-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)

-XX:G1MaxNewSizePercent:新生代内存最大空间

-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个<br>年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代

-XX:MaxTenuringThreshold:最大年龄阈值(默认15)<br>

-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了

-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。

-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一<br>会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。

-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

支持TB量级的堆

最大GC停顿时间不超10ms

奠定未来GC特性的基础

最糟糕的情况下吞吐量会降低15%

小型Region（Small Region） ： 容量固定为2MB， 用于放置小于256KB的小对象。

中型Region（Medium Region） ： 容量固定为32MB， 用于放置大于等于256KB但小于4MB的对象。<br>

大型Region（Large Region） ： 容量不固定， 可以动态变化， 但必须为2MB的整数倍， 用于放置4MB或以上的大对象

核心原理

Finalizable： 表示此对象只能通过 finalizer 访问，而不是强引用

Remapped： 表示该指针已被重映射（即，对象被移动后，其新地址的指针会设置此位）。如果一个指针的 Remapped 位是 1，说明它指向的是对象的新地址，是“正确”的指针。

Marked1： 用于标记阶段

Marked0： 同样用于标记阶段。

Marked0 和 Marked1 交替使用，每个垃圾回收周期切换一次，用于区分当前周期和上一个周期

读屏障是 JVM 在从堆内存中读取引用字段时插入的一小段代码。可以把它想象成一个“钩子”或者“安全检查点”。

核心原理

作用

阶段 1: 初始标记 (Pause Mark Start)

阶段 2: 并发标记 (Concurrent Mark)

阶段 3: 再标记 (Pause Mark End)

阶段 4: 并发准备和重定位 (Concurrent Prepare/Relocate)<br>

安全点就是指代码中一些特定的位置,当线程运行到这些位置时它的状态是确定的,这样JVM就可以安全的进行一些操作,比<br>如GC等，所以GC不是想什么时候做就立即触发的，是需要等待所有线程运行到安全点后才能触发。

Safe Region 是指在一段代码片段中，引用关系不会发生变化。在这个区域内的任意地方开始 GC 都是安全的。

<br>

<br>

<br>

使用命令top -p &lt;pid&gt; ，显示你的java进程的内存情况，pid是你的java进程号，比如19663

按H，获取每个线程的内存情况

找到内存和cpu占用最高的线程tid，比如19664

将pid转为十六进制得到 0x4cd0，此为线程id的十六进制表示

执行 jstack 19663|grep -A 10 4cd0，得到线程堆栈信息中 4cd0 这个线程所在行的后面10行，从堆栈中可以发现导致cpu飙高的调用方法

jinfo -flags&nbsp;pid<br>

jinfo&nbsp; - sysprops&nbsp;pid<br>

jstat [-命令选项] [vmid] [间隔时间(毫秒)] [查询次数]

S0C：第一个幸存区的大小，单位KB<br>S1C：第二个幸存区的大小<br>S0U：第一个幸存区的使用大小<br>S1U：第二个幸存区的使用大小<br>EC：伊甸园区的大小<br>EU：伊甸园区的使用大小<br>OC：老年代大小<br>OU：老年代使用大小<br>MC：方法区大小(元空间)<br>MU：方法区使用大小<br>CCSC:压缩类空间大小<br>CCSU:压缩类空间使用大小<br>YGC：年轻代垃圾回收次数<br>YGCT：年轻代垃圾回收消耗时间，单位s<br>FGC：老年代垃圾回收次数<br>FGCT：老年代垃圾回收消耗时间，单位s<br>GCT：垃圾回收消耗总时间，单位s

堆内存统计

新生代垃圾回收统计<br>

新生代内存统计<br>

老年代垃圾回收统计

老年代内存统计<br>

元空间不够导致的多余full gc<br>

显示调用System.gc()造成多余的full gc，这种一般线上尽量通过­XX:+DisableExplicitGC参数禁用，如果加上了这个JVM启动参数，那么代码中调用System.gc()没有任何效果

老年代空间分配担保机制

对于一些老旧数据没有及时清理导致一直占用着宝贵的内存<br>资源

<br>

thread加上线程ID 可以查看线程堆栈

thread -b 可以查看线程死锁

<br>

可以将多个匹配写到⼀起

每个分⽀直接返回⼀个值。

if (o instanceof Integer i &amp;&amp; i &gt; 0) {<br>System.out.println(i.intValue());<br>} else if (o instanceof String s &amp;&amp; s.startsWith("t")) {<br>System.out.println(s.charAt(0));<br>}

var nums = new int[] {1, 2, 3, 4, 5};<br>var sum = Arrays.stream(nums).sum();<br>System.out.println("数组之和为：" + sum);

public record Point(int x, int y) {<br>}

public sealed abstract class Shape permits Circle, Rectangle, Square {<br>public abstract int lines();<br>}

引⼊模块化机制后，应⽤需要在每个模块的根⽬录下创建⼀个module-info.java⽂件，⽤来声明⼀个模块。然后<br>在这个⽂件中，⽤module关键字，声明⼀个模块

这样，当前⽬录下的所有package下的代码，都将属于同⼀个module。module名字必须全局唯⼀。⾄于具体的格式，没有强制要求，不过通常的惯例是类似于包结构，全部⽤⼩写，⽤.连接。

在module-info.java中⾸先要声明当前module需要依赖哪些外部模块。⽐如，如果你要使⽤junit，那么除了要<br>在pom.xml中引⼊junit对应的依赖外，还需要在module-info.java中添加配置，否则项⽬编译就会报错。

exports关键字开放的成员在编译和运⾏时都可以访问，但是不能⽤反射的⽅式访问。如果想要通过反射的⽅式访问⼀个模块内的成员，需要改为使⽤opens关键字声明。声明⽅式和exports⼀样。