系统卡顿之垃圾回收机制
1.检查gc
[risk@localhost ~]$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2897 risk 20 0 7987112 1.6g 6008 S 100.7 13.7 1335:25 java
12039 risk 20 0 5675740 749656 6476 S 24.9 6.1 27:00.96 java
21039 risk 20 0 8182740 2.6g 6276 S 9.3 22.5 240:32.33 java
7525 risk 20 0 5909196 2.0g 6028 S 3.0 16.9 152:09.23 java
11738 oracle -2 0 5192068 440 328 S 1.7 0.0 2836:25 oracle
6 root 20 0 0 0 0 S 1.0 0.0 2268:27 ksoftirqd/0
19716 oracle 20 0 5194940 26068 23040 S 1.0 0.2 0:05.36 oracle
[risk@localhost ~]$ jstat -gc -h3 2897 1000 10 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 1024.0 1024.0 0.0 736.0 1145856.0 23256.0 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 1024.0 1024.0 0.0 736.0 1145856.0 29958.5 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 1024.0 1024.0 0.0 736.0 1145856.0 29958.5 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 1024.0 1024.0 0.0 736.0 1145856.0 29958.5 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 1024.0 1024.0 0.0 736.0 1145856.0 36660.9 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 1024.0 1024.0 0.0 736.0 1145856.0 36660.9 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 1024.0 1024.0 0.0 736.0 1145856.0 36978.9 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 1024.0 1024.0 0.0 736.0 1145856.0 43683.4 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 1024.0 1024.0 0.0 736.0 1145856.0 43683.4 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 1024.0 1024.0 0.0 736.0 1145856.0 43683.4 2541568.0 38710.4 68864.0 65402.7 8192.0 7422.6 173 8.629 3 2.167 10.796
这段内容是通过
jstat -gc -h3 2897 1000 10 命令输出的Java虚拟机（JVM）垃圾回收（GC）统计信息。下面是对这些信息的详细分析：命令解释
-
jstat -gc：输出垃圾回收统计信息，-gc选项表示输出GC相关的统计信息。 -
-h3：每3行输出一个标题行，方便阅读。 -
2897：目标Java进程的进程ID。 -
1000：采样间隔，单位为毫秒，这里表示每1000毫秒（1秒）采样一次。 -
10：采样次数，总共采样10次。
输出列解释
-
S0C：Survivor 0区的容量（以KB为单位）。
-
S1C：Survivor 1区的容量（以KB为单位）。
-
S0U：Survivor 0区已使用的空间（以KB为单位）。
-
S1U：Survivor 1区已使用的空间（以KB为单位）。
-
EC：Eden区的容量（以KB为单位）。
-
EU：Eden区已使用的空间（以KB为单位）。
-
OC：Old区的容量（以KB为单位）。
-
OU：Old区已使用的空间（以KB为单位）。
-
MC：Metaspace区的容量（以KB为单位）。
-
MU：Metaspace区已使用的空间（以KB为单位）。
-
CCSC：Compressed Class Space区的容量（以KB为单位）。
-
CCSU：Compressed Class Space区已使用的空间（以KB为单位）。
-
YGC：Young Generation GC（年轻代GC）的次数。
-
YGCT：Young Generation GC的总耗时（以秒为单位）。
-
FGC：Full GC（全GC）的次数。
-
FGCT：Full GC的总耗时（以秒为单位）。
-
GCT：GC的总耗时（以秒为单位）。
数据分析
从输出数据中，我们可以看到以下信息：
-
Survivor区：
-
S0C 和 S1C：Survivor 0区和Survivor 1区的容量都是1024KB。
-
S0U 和 S1U：Survivor 0区始终为空（0.0KB），Survivor 1区的使用量在736.0KB左右，没有变化。
-
-
Eden区：
-
EC：Eden区的容量为1145856KB。
-
EU：Eden区的使用量在23256.0KB到43683.4KB之间逐渐增加。
-
-
Old区：
-
OC：Old区的容量为2541568KB。
-
OU：Old区的使用量始终为38710.4KB，没有变化。
-
-
Metaspace区：
-
MC：Metaspace区的容量为68864KB。
-
MU：Metaspace区的使用量为65402.7KB，没有变化。
-
-
Compressed Class Space区：
-
CCSC：Compressed Class Space区的容量为8192KB。
-
CCSU：Compressed Class Space区的使用量为7422.6KB，没有变化。
-
-
GC统计：
-
YGC：年轻代GC的次数为173次。
-
YGCT：年轻代GC的总耗时为8.629秒。
-
FGC：全GC的次数为3次。
-
FGCT：全GC的总耗时为2.167秒。
-
GCT：GC的总耗时为10.796秒。
-
结论
-
Eden区：Eden区的使用量在逐渐增加，这表明应用正在不断创建新的对象。如果Eden区的使用量持续增加，可能会触发更多的年轻代GC。
-
Survivor区：Survivor 1区的使用量相对稳定，表明对象在年轻代中的存活时间较短，大部分对象在几次GC后就被回收了。
-
Old区：Old区的使用量相对稳定，表明应用中长期存活的对象数量变化不大。
-
Metaspace区：Metaspace区的使用量相对稳定，表明类的加载和卸载相对平衡。
-
GC性能：年轻代GC的次数较多，但总耗时相对较少，表明年轻代GC的效率较高。全GC的次数较少，但每次耗时较长，这可能会影响应用的响应时间。
建议
-
监控：持续监控JVM的GC情况，特别是Eden区的使用量，如果Eden区的使用量持续增加，可能需要调整堆大小或优化代码。
-
调优：如果应用的响应时间受到全GC的影响，可以考虑调整GC策略或增加堆大小，以减少全GC的频率和耗时。
-
分析：如果Eden区的使用量持续增加，可以使用工具（如
jmap）生成堆转储文件，分析内存泄漏或内存溢出的原因。
2.定位具体代码
定位进程
[risk@46100v8t100 ~]$ top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23147 risk 20 0 9817.2m 1.124g 13232 S 392.7 7.2 6105:19 java 18915 risk 20 0 9.862g 3.300g 14940 S 11.6 21.3 244:07.43 java 22809 risk 20 0 9183200 996568 13108 S 4.3 6.1 123:32.59 java 11206 risk 20 0 3238776 596348 248 S 1.3 3.7 2548:43 InterfaceDtpf 519 risk 20 0 488948 2748 216 S 1.0 0.0 1270:44 InterfaceCtpRis 5504 oracle -2 0 5178264 1320 888 S 1.0 0.0 3083:08 ora_vktm_ksfix 11675 risk 20 0 152872 3028 1320 S 1.0 0.0 0:00.22 sshd
可以使用以下大概知道那个服务的问提
[risk@46100v8t100 ~]$ jps -l
18915 ./../lib/riskv10-riskquery.jar
25573 sun.tools.jps.Jps
22809 ./../lib/risk10-warn.jar
23147 ./../lib/riskv10-msg.jar
3774 /home/risk/risk_gateway/bin/../lib/riskv10-gateway.jar
32207 /home/risk/risk_market/bin/../lib/risk10-market.jar
定位线程
[risk@46100v8t100 ~]$ top -H -p 23147 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23585 risk 20 0 9817.2m 1.125g 13232 R 97.3 7.2 1523:02 java 23589 risk 20 0 9817.2m 1.125g 13232 R 96.0 7.2 1522:45 java 23590 risk 20 0 9817.2m 1.125g 13232 R 96.0 7.2 1522:36 java 23587 risk 20 0 9817.2m 1.125g 13232 R 95.0 7.2 1522:42 java 23588 risk 20 0 9817.2m 1.125g 13232 S 0.7 7.2 4:05.15 java 23586 risk 20 0 9817.2m 1.125g 13232 S 0.3 7.2 3:51.96 java
转换16进制
[risk@46100v8t100 ~]$ printf "%x\n" 23585 5c21
定位具体代码如下
[risk@46100v8t100 ~]$ jstack 23147 | grep '5c21' -C5 --color
at risk10.msg.com.ks.future.riskv10.producer.KafkaProducer.run(KafkaProducer.java:73)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
"pool-3-thread-1" #27 prio=5 os_prio=0 tid=0x00007f5a04037800 nid=0x5c21 runnable [0x00007f5a6a98e000]
java.lang.Thread.State: RUNNABLE
at java.lang.Thread.yield(Native Method)
at com.lmax.disruptor.YieldingWaitStrategy.applyWaitMethod(YieldingWaitStrategy.java:57)
at com.lmax.disruptor.YieldingWaitStrategy.waitFor(YieldingWaitStrategy.java:39)
at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)
[risk@46100v8t100 ~]$
本文来自博客园，作者：皮军旗，转载请注明原文链接：https://www.cnblogs.com/pijunqi/p/18675034
浙公网安备 33010602011771号