点赞再看,养成习惯,微信搜索「小大白日志」关注这个搬砖人。
文章不定期同步公众号,还有各种一线大厂面试原题、我的学习系列笔记。
基础概念
- 一般JVM调优,重点在于调整JVM堆大小、调整垃圾回收器
JVM调优常用参数
- -Xmx1024m:最大堆内存,当物理内存不超过192m时最大堆内存为物理内存的一半,否则为物理内存的四分一
- -Xms1024m:最小堆内存,一般设置为与-Xmx同等值
- jcmd:专用于查看JVM状态,可以查看正在运行的进程,会显示出进程号
- jmap -heap 10864:查看进程号为10864的进程的堆使用情况
具体参数如下:
F:\Iwebapp\demo-test>jmap -heap 10864
Attaching to process ID 10864, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.65-b01
using thread-local object allocation.
Parallel GC with 4 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0 //空余堆内存最小百分比,HeapFreeRatio=空闲堆内存的百分比=现有空闲堆内存/总共对内存*100,当MinHeapFreeRatio<HeapFreeRatio时,在每次垃圾回收之后需要进行对扩容
MaxHeapFreeRatio = 100 //空余堆内存最大百分比
MaxHeapSize = 1044381696 (996.0MB) //996.0MB=最大堆内存无物理内存1/4=4G*1/4约等于1G
NewSize = 22020096 (21.0MB) //年轻代堆内存的初始大小
MaxNewSize = 348127232 (332.0MB) //年轻代堆内存的允许最大值,因为年轻代:老年代=1:2,所以年轻代最大=996*1/3=332
OldSize = 45088768 (43.0MB)
NewRatio = 2 //老年代:年轻代=2:1
SurvivorRatio = 8 //年轻代中Eden区:Survivor区=8:2,Survivor区=SurvivorFrom区+SurvivorTo区=1+1=2
MetaspaceSize = 21807104 (20.796875MB) //jdk1.8之后使用的元空间默认大小
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize = 17592186044415 MB //jdk1.8之后使用的元空间的最大值
G1HeapRegionSize = 0 (0.0MB) //若使用G1垃圾回收器,JVM把堆内存每个多个大小相等的区域,指定每个区域的大小
Heap Usage:
PS Young Generation
Eden Space: //年轻代的使用情况
capacity = 289931264 (276.5MB)
used = 160612016 (153.1715545654297MB)
free = 129319248 (123.32844543457031MB)
55.39658392963099% used
From Space: //SurvivorFrom区的使用情况
capacity = 5767168 (5.5MB)
used = 65536 (0.0625MB)
free = 5701632 (5.4375MB)
1.1363636363636365% used
To Space: //SurvivorTo区的使用情况
capacity = 5242880 (5.0MB)
used = 0 (0.0MB)
free = 5242880 (5.0MB)
0.0% used
PS Old Generation //老年代的使用情况
capacity = 37748736 (36.0MB)
used = 13700064 (13.065399169921875MB)
free = 24048672 (22.934600830078125MB)
36.29277547200521% used
监控JVM
实战源码:以demo-test工程为例,
package com.example.demo;
import com.example.util.ThreadTest;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class DemoTestApplication {
public static void main(String[] args) {
SpringApplication.run(DemoTestApplication.class, args);
ThreadTest.testJVM();
}
}
public class ThreadTest {
public static void main(String[] args) {
testJVM();
}
public static void testJVM(){
//匿名内部类重写Runnable的run方法可以写成箭头函数:()->{run方法的内容}
//1000ms后每50ms执行创建1个线程,每个线程150*512*1024byte=150*512*1024B=150*512k=150*0.5M=75M,1s内最多1000/50=20个线程,则1s内最大占用内存=75*20=150M
Executors.newScheduledThreadPool(1).scheduleAtFixedRate(()->{
new Thread(()->{
for(int i=1;i<=150;i++){
byte[] b=new byte[1024*512];//0.5M
}
System.out.println(Thread.currentThread().getName()+"已分配512k内存...");
}).start();
},1000,50,TimeUnit.MILLISECONDS);
}
在target目录下【java -jar -Xloggc:gc.log -Xmx35m -Xms35m demo-test.jar】启动jar包或者直接在idea中添加【-Xloggc:gc.log -Xmx35m -Xms35m】启动springboot启动类,以下用gcviewner监控JVM :
- gcviwner:gcviwner是一款可以监控GC日志的工具,前提是要拿到gc日志,【java -jar gcviewer-1.37-SNAPSHOT.jar】启动gcviwner,并导入gc.log日志,如下,
gcviwner用法可参考【https://github.com/chewiebug/GCViewer】
红线是堆的实时总内存,蓝线是堆的实时已使用内存,灰色为young gc,黑色为full gc,可知灰色的线太密集=young gc频繁,黑色的线还不算太密集=full gc还不算太频繁;同时累计gc时间为88.15s=full gc时间为2.91s+young gc为85.24s,说明大部分对象还是在young gc时间段被回收了;
程序运行一段时间后,gc.log分析如下:
可知,young gc还是频繁,full gc后面越来越频繁;同时full gc的时间9.6%,也说明full gc确实过于频繁了,解决办法:增大堆内存,对应修改 【-Xmx100m,-Xms100m】后启动jar包:
可知full gc只发生了1次,花费0.05s;young gc发生了4703次,但时间降到了10.43s,可以继续增大堆内存...
- jstat命令
//每1000ms统计一次demo-test-0.0.1.jar的gc信息
jstat -gc $(jcmd | grep "demo-test-0.0.1.jar" | awk '{print $1}') 1000
S0C、S1C、S0U、S1U:C是总量,U是使用量,代表S0(survivorFrom区)和S1(survivorTo区)的总量与使用量
EC、EU:Eden区总量与使用量
OC、OU:Old区总量与使用量
MC、MU: Metaspace区(元空间)总量与使用量
YGC、YGCT:young gc的次数与时间
FGC、FGCT:full gc的次数与时间<
GCT:总的GC时间
CMS收集器和G1收集器的调优
各种垃圾收集器
参数 | 说明 |
---|---|
-XX:+UseParallelGC | 新生代使用并行回收收集器 |
-XX:+Use ParalleloldGC | 老年代使用并行回收收集器 |
-XX:ParallelGCThreads | 设置用于垃圾回收的线程数 |
-XX:+UseAdaptiveSizePolicy | 打开自适应GC策略 |
CMS和G1的调优
- cms是分代收集算法中老年代的算法(用标记整理算法),G1却适用于年轻代和老年代,故G1可以采用复制算法不会导致内存碎片,而cms不能采用年轻代的复制算法而导致有内存碎片
- G1是由一个个区域块组成的,即使有碎片也只会影响某个区域块,不会影响整个堆
- cms采用老年代标记整理算法,需要扫描整个表来标记整理,故存在停顿(即使它是并发);G1的停顿取决于需要收集的'区域块'个数,而不用等整个堆空间,所以g1的停顿时间比cms少
OK,如果文章哪里有错误或不足,欢迎各位留言。
创作不易,各位的「三连」是二少创作的最大动力!我们下期见!