转载

JVM深入理解-内存调优与GC日志

CPU飚高分析

一般可以使用

  • ps -Lfp pid
  • ps -mp pid -o THREAD, tid, time
  • top -Hp pid
[root@redis webapps]# top -Hp 22272
top - 10:09:30 up 9 days, 22:10,  1 user,  load average: 0.00, 0.00, 0.00  
Tasks:  30 total,   0 running,  30 sleeping,   0 stopped,   0 zombie  
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st  
Mem:   3923196k total,  3795588k used,   127608k free,   153056k buffers  
Swap:  6160376k total,        0k used,  6160376k free,  3079244k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                
22272 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java  
22278 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java  
22279 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java  
22282 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java  
22283 root      20   0 2286m 122m  11m S  0.0  3.2   3:01.48 java  
22287 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java  
22288 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java  
22289 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java  
22290 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.03 java  
22291 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.34 java  
22292 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.06 java  
22299 root      20   0 2286m 122m  11m S  0.0  3.2   0:06.37 java  
22301 root      20   0 2286m 122m  11m S  0.0  3.2   1:09.73 java  
17034 root      20   0 2286m 122m  11m S  0.0  3.2   0:00.00 java

TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为22283 的线程。

用 printf “%x/n” 22283 

[root@redis webapps]# printf ‘%x/n’ 22283
570b得到22283 的十六进制值为570b。

下一步轮到jstack上场了，它用来输出进程22272 的堆栈信息，然后根据线程ID的十六进制值grep，如下：

[root@redis webapps]# jstack 22272 | grep 570b
“SchedulerThread” prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait()

可以看到CPU消耗在SchedulerThread这个类的Object.wait()，定位到下面的代码：

// Idle wait
synchronized(sigLock) {  
  try {
    if(!halted.get()) {
      sigLock.wait(timeUntilContinue);
    }
  } 
  catch (InterruptedException ignore) {
  }
}

它是轮询任务的空闲等待代码，上面的sigLock.wait(timeUntilContinue)就对应了前面的Object.wait()。

总结：可以通过PID找到对应的的线程，然后通过JVM的jstack找到栈里对应的线程信息。通过找到对应的代码一般就能分析出CPU占用高的原因。

利用JVM命令分析

jstat -gcutil

[root@xxxx-nccz8-b57dd64fc-nt9dj logs]# jstat -gcutil 1 2000 20
S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT  
  0.00   8.64   2.62  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   2.81  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   2.81  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   2.81  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   3.06  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   3.10  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   3.10  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   3.21  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   3.22  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   3.61  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   6.47  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   6.76  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   6.81  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   7.07  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   7.08  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   7.38  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   7.38  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   7.62  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   7.62  27.32  80.59  73.86   1350   22.705     5    1.449   24.154
  0.00   8.64   7.76  27.32  80.59  73.86   1350   22.705     5    1.449   24.154

S0：Heap上的 Survivor space 0 区已使用空间的百分比

S1：Heap上的 Survivor space 1 区已使用空间的百分比

E：Heap上的 Eden space 区已使用空间的百分比

O：Heap上的 Old space 区已使用空间的百分比

M：Metaspace 区已使用空间的百分比

YGC：从应用程序启动到采样时发生 Young GC 的次数

YGCT：从应用程序启动到采样时 Young GC 所用的时间(单位秒)

FGC：从应用程序启动到采样时发生 Full GC 的次数

FGCT：从应用程序启动到采样时 Full GC 所用的时间(单位秒)

GCT：从应用程序启动到采样时用于垃圾回收的总时间(单位秒)

jmap -heap

[root@xxxx-nccz8-b57dd64fc-nt9dj startup]# jmap -heap 1
Attaching to process ID 1, please wait...  
Debugger attached successfully.  
Server compiler detected.  
JVM version is 25.191-b12

using parallel threads in the new generation.  
using thread-local object allocation.  
Concurrent Mark-Sweep GC

Heap Configuration:  
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 2147483648 (2048.0MB)
   NewSize                  = 805306368 (768.0MB)
   MaxNewSize               = 805306368 (768.0MB)
   OldSize                  = 1342177280 (1280.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 268435456 (256.0MB)
   CompressedClassSpaceSize = 260046848 (248.0MB)
   MaxMetaspaceSize         = 268435456 (256.0MB)
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:  
New Generation (Eden + 1 Survivor Space):  
   capacity = 724828160 (691.25MB)
   used     = 284988360 (271.7860794067383MB)
   free     = 439839800 (419.4639205932617MB)
   39.318058503687276% used
Eden Space:  
   capacity = 644349952 (614.5MB)
   used     = 275398000 (262.63999938964844MB)
   free     = 368951952 (351.86000061035156MB)
   42.74043928228616% used
From Space:  
   capacity = 80478208 (76.75MB)
   used     = 9590360 (9.146080017089844MB)
   free     = 70887848 (67.60391998291016MB)
   11.916716634644748% used
To Space:  
   capacity = 80478208 (76.75MB)
   used     = 0 (0.0MB)
   free     = 80478208 (76.75MB)
   0.0% used
concurrent mark-sweep generation:  
   capacity = 1342177280 (1280.0MB)

通过heap命令能看出当前整个堆的一个使用情况，used与free的一个实际占用比。

jmap -dump

jmap -dump:live,format=b,file=xxxxxx.20200707.hprof 1

我们一般会在Dockerfile里面配置好如果出现OOM的情况，保留一下现场。 -XX:HeapDumpPath=/alidata1/admin/xxxxx/logs

利用JProfiler分析

发现大对象，这里是因为我们用了Jeager链路跟踪，但是用过多线程导致ThreadLocal没有释放掉。

JVM深入理解-内存调优与GC日志

发现char[]占用比较多，并且找出是从哪儿产生的？

JVM深入理解-内存调优与GC日志

通过Outgoing references找到具体的实例情况。

JVM深入理解-内存调优与GC日志

什么是outgoing references与incoming references？让我们通过示例来了解有关 Incoming references 和 Outgoing references 的更多知识。例如，一个应用程序的源代码如下所示：

public class A {  
  private C c1 = C.getInstance();
}

public class B {  
    private C c2 = C.getInstance();
}

public class C {  
    private static C myC = new C();     

    public static C getInstance() {             
    return myC;     
    }   

    private D d1 = new D();     
    private E e1 = new E();
}

public class D {  
}

public class E {  
}

public class SimpleExample {  
    public static void main (String argsp[]) throws Exception {
           A a = new A();
           B b = new B();     
    }
}
  • 对象 A 和对象 B 持有对象 C 的引用
  • 对象 C 持有对象 D 和对象 E 的引用

在这个示例项目中，让我们具体分析下对象 C 的 Incoming references 和 Outgoing references 。

对象 C 的 Incoming References

拥有对象 C 的引用的所有对象都称为 Incoming references。在此示例中，对象 C 的“Incoming references”是对象 A、对象 B 和 C 的类对象 。

对象 C 的 Outgoing References

对象 C 引用的所有对象都称为 Outgoing References。在此示例中，对象 C 的“outgoing references”是对象 D、对象 E 和 C 的类对象。

然后通过 Show in graph 的菜单，一层一层的点击。直到你看到你最熟悉的类。

JVM深入理解-内存调优与GC日志

JVM深入理解-内存调优与GC日志

如何看GC日志

设置gc日志配置

-XX:+PrintGC 输出简要GC日志 
-XX:+PrintGCDetails 输出详细GC日志 
-Xloggc:gc.log  输出GC日志到文件
-XX:+PrintGCTimeStamps 输出GC的时间戳（以JVM启动到当期的总时长的时间戳形式） 
-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800） 
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-verbose:gc
-XX:+PrintReferenceGC 打印年轻代各个引用的数量以及时长

-XX:+PrintGC

如果只设置 -XX:+PrintGC 那么打印的日志如下所示： 

[GC (Allocation Failure)  61805K->9849K(256000K), 0.0041139 secs]

1、GC 表示是一次YGC（Young GC）  
2、Allocation Failure 表示是失败的类型  
3、61805K->9849K 表示年轻代从61805K降为9849K  
4、256000K表示整个堆的大小  
5、0.0041139 secs表示这次GC总计所用的时间  
在JDK 8中，-verbose:gc是-XX:+PrintGC一个别称，日志格式等价与：-XX:+PrintGC，。

-XX:+PrintGCDetails

[GC (Allocation Failure) [PSYoungGen: 53248K->2176K(59392K)] 58161K->7161K(256000K), 0.0039189 secs] [Times: user=0.02 sys=0.01, real=0.00 secs]
1、GC 表示是一次YGC（Young GC）  
2、Allocation Failure 表示是失败的类型  
3、PSYoungGen 表示年轻代大小  
4、53248K->2176K 表示年轻代占用从53248K降为2176K  
5、59392K表示年轻带的大小  
6、58161K->7161K 表示整个堆占用从53248K降为2176K  
7、256000K表示整个堆的大小  
8、 0.0039189 secs 表示这次GC总计所用的时间  
9、[Times: user=0.02 sys=0.01, real=0.00 secs]  分别表示，用户态占用时长，内核用时，真实用时。  
时间保留两位小数，四舍五入。

-XX:+PrintGCTimeStamps

1.963: [GC (Allocation Failure)  61805K->9849K(256000K), 0.0041139 secs]

如果加上 -XX:+PrintGCTimeStamps 那么日志仅仅比1.1介绍的最前面多了一个时间戳： 1.963 ， 表示从JVM启动到打印GC时刻用了1.963秒。

-XX:+PrintGCDateStamps

2019-03-05T16:56:15.108+0800: [GC (Allocation Failure)  61805K->9849K(256000K), 0.0041139 secs]

如果加上 -XX:+PrintGCDateStamps 那么日志仅仅比1.1介绍的最前面多了一个日期时间： 2019-03-05T16:56:15.108+0800 ， 表示打印GC的时刻的时间是 2019-03-05T16:56:15.108+0800 。+0800表示是东8区。

CMS GC日志详细分析

[GC (CMS Initial Mark) [1 CMS-initial-mark: 19498K(32768K)] 36184K(62272K), 0.0018083 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.011/0.011 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time [CMS-concurrent-abortable-preclean: 0.558/5.093 secs] [Times: user=0.57 sys=0.00, real=5.09 secs] 
[GC (CMS Final Remark) [YG occupancy: 16817 K (29504 K)][Rescan (parallel) , 0.0021918 secs][weak refs processing, 0.0000245 secs][class unloading, 0.0044098 secs][scrub symbol table, 0.0029752 secs][scrub string table, 0.0006820 secs][1 CMS-remark: 19498K(32768K)] 36316K(62272K), 0.0104997 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.007/0.007 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

CMS日志分为两个STW(stop the world)

分别是 init remark （1） 与 remark （7）两个阶段。一般耗时比YGC长约10倍（个人经验）。

（1）、 [GC (CMS Initial Mark) [1 CMS-initial-mark: 19498K(32768K)] 36184K(62272K), 0.0018083 secs][Times: user=0.01 sys=0.00, real=0.01 secs]

会STW(Stop The World)，这时候的老年代容量为 32768K， 在使用到 19498K 时开始初始化标记。耗时短。

（2）、 [CMS-concurrent-mark-start]

并发标记阶段开始

（3）、 [CMS-concurrent-mark: 0.011/0.011 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]

并发标记阶段花费时间。

（4）、 [CMS-concurrent-preclean-start]

并发预清理阶段，也是与用户线程并发执行。虚拟机查找在执行并发标记阶段新进入老年代的对象(可能会有一些对象从 新生代 晋升到老年代， 或者有一些对象被分配到老年代)。通过重新扫描，减少下一个阶段”重新标记”的工作，因为下一个阶段会Stop The World。

（5）、 [CMS-concurrent-preclean: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

并发预清理阶段花费时间。

（6）、 [CMS-concurrent-abortable-preclean-start] CMS: abort preclean due to time [CMS-concurrent-abortable-preclean: 0.558/5.093 secs][Times: user=0.57 sys=0.00, real=5.09 secs]

并发可中止预清理阶段，运行在并行预清理和重新标记之间，直到获得所期望的eden空间占用率。增加这个阶段是为了避免在重新标记阶段后紧跟着发生一次垃圾清除

（7）、 [GC (CMS Final Remark) [YG occupancy: 16817 K (29504 K)][Rescan (parallel) , 0.0021918 secs][weak refs processing, 0.0000245 secs][class unloading, 0.0044098 secs][scrub symbol table, 0.0029752 secs][scrub string table, 0.0006820 secs][1 CMS-remark: 19498K(32768K)] 36316K(62272K), 0.0104997 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

会STW(Stop The World)，收集阶段，这个阶段会标记老年代全部的存活对象，包括那些在并发标记阶段更改的或者新创建的引用对象

（8）、 [CMS-concurrent-sweep-start]

并发清理阶段开始，与用户线程并发执行。

（9）、 [CMS-concurrent-sweep: 0.007/0.007 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

并发清理阶段结束，所用的时间。

（10）、 [CMS-concurrent-reset-start]

开始并发重置。在这个阶段，与CMS相关数据结构被重新初始化，这样下一个周期可以正常进行。

（11）、 [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

并发重置所用结束，所用的时间。

参考地址

  • https://mp.weixin.qq.com/s/bSv2YDqOJsWYj6ZjAnf1ew
  • https://blog.csdn.net/preterhuman_peak/article/details/43674037
  • https://juejin.im/post/5c80b0f451882532cd57b541

如果大家喜欢我的文章，可以关注个人订阅号。欢迎随时留言、交流。如果想加入微信群的话一起讨论的话，请加管理员简栈文化-小助手（lastpass4u），他会拉你们进群。

JVM深入理解-内存调优与GC日志

原文  http://www.cyblogs.com/jvmshen-ru-li-jie-nei-cun-diao-you-yu-gcri-zhi/
正文到此结束
所属分类： Java 编程技术

热门推荐

相关文章

阿里云首购8折
说给你听

本文目录
随机标签
书籍教程
springboot-demo Java入门教程 bootstrap3 CSS Apache基础教程 php ionic 教程 Python mysql教程 eclipse Ubuntu VPS系统配置 AngularJS 教程 MongoDB教程 Struts2教程 Redis教程 Spring教程 Git教程 Jenkins进阶系列 openfire参考指南 Java设计模式 HBase教程 java-demo Maven教程 springcloud-demo hibernate教程 Docker 教程 memcached教程 Quartz指南 Hive教程 ANTLR教程 SpringCloud Ant教程 java实例教程 Hazelcast教程 XStream教程 Elastic-Job-Lite 深入浅出MyBatis ibaties教程 SVN教程 rabittmq教程 Hadoop教程 solr教程 WebService CXF学习 JPA教程 ActiveMQ中文指南 Java内存模型 dubbo教程 python3-demo Linux入门视频教程
近期评论
  1. 1 使用 Docker 打包和运行 Vue 应用
  2. 2 Dependency Check命令行方式扫描jar包的安全漏洞
  3. 3 maven使用Dependency-Check来扫描安全漏洞
  4. 4 使用sonarqube分析代码质量
  5. 5 使用screw来对比数据库表和字段差异
  6. 6 Spring Boot 实现防盗链功能
  7. 7 在Spring Boot中的实现国际化（i18n）
  8. 8 一个用于 SMB/CIFS 网络的 Java 库-JCIFS
  9. 9 Spring Boot 3.x嵌入MongoDB 进行测试
  10. 10 java如何解析和生成yaml文件？
网站信息
  • 文章总数：82,737 篇
  • 文件总数：284,312 个
  • 标签总数：2,416 个
  • 分类总数：85 个
  • 留言数量：2,559 条
  • 在线人数：668 人
  • 运行天数：4,439天
  • 最后更新：2024年12月22日11点
Loading...

其他链接

关于本站

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。

问题交流

[HBLOG]公众号 HBLOG HBLOG