分析 GC 日志

GC 分类

1、HotSpot VM 的 GC,按照回收区域分为

(1)部分收集(Partial GC)

(2)整堆收集(Full GC)

2、部分收集(Partial GC):不完全收集整个 Java 堆的垃圾,其中分为

(1)新生代收集(Minor GC / Young GC):只收集新生代(Eden / S0,S1)的垃圾

(2)老年代收集(Major GC / Old GC):只收集老年代的垃圾,目前,只有 CMS GC 有单独收集老年代的行为;注意 Major GC 会和 Full GC 混淆使用,需要具体分辨:老年代回收 / 整堆回收

3、混合收集(Mixed GC):收集整个新生代、部分老年代的垃圾,目前,只有 G1 GC 有该行为

4、整堆收集(Full GC):收集整个 Java 堆、方法区的垃圾

 

GC 日志分类

1、Minor GC / Young GC

(1)例

[GC (Allocation Failure) [PSYoungGen: 31744K->2192K (36864K) ] 31744K->2200K (121856K), 0.0139308 secs] [Times: user=0.05 sys=0.01, real=0.01 secs]

(2)结构:[GC (Allocation Failure) [新生代: Young GC 前新生代内存占用->Young GC 后新生代内存占用 (新生代总大小) ] Young GC 前 JVM 堆内存占用->Young GC 后 JVM 堆内存使用 (JVM 堆总大小), Young GC 耗时] [Times: user=Young GC 用户耗时 sys=Young GC 系统耗时, real=Young GC 实际耗时]

2、Full GC

(1)例

[Full GC (Metadata GC Threshold) [PSYoungGen: 5104K->0K (132096K) ] [Par01dGen: 416K->5453K (50176K) ]5520K->5453K (182272K), [Metaspace: 20637K->20637K (1067008K) ], 0.0245883 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]

(2)结构:[Full GC (Metadata GC Threshold) [新生代: GC 前新生代内存占用->GC 后新生代内存占用 (新生代总大小) ] [老年代: GC 前老年代内存占用->GC 后老年代内存占用 (老年代总大小) ]GC 前堆内存占用->GC 后堆内存占用 (JVM 堆总大小), [元空间:  GC 前元空间内存占用->GC 后元空间内存占用 (元空间总大小) ], GC 耗时] [Times: user=GC 用户耗时 sys=GC 系统耗时 , real=GC 实际耗时]

3、垃圾收集器

(1)Serial 收集器:新生代显示 [DefNew,即 Default New Generation

(2)ParNew 收集器:新生代显示 [ParNew,即 Parallel New Generation

(3)Parallel Scavenge 收集器:新生代显示 [PSYoungGen,即 PSYoungGen,JDK 1.7 使用

(4)Parallel Old 收集器:老年代显示 [ParoldGen

(5)G1 收集器:显示 garbage-first heap

4、GC 原因

(1)Allocation Failure:新生代中没有足够的区域,存放需要分配的数据

(2)Metadata GCThreshold:Metaspace 区空间不足

(3)FErgonomics:JVM 自适应调整,导致 GC

(4)System:调用 System.gc() 方法

5、结构规律

(1)中括号内:区名称: GC 前内存占用->GC 后内存占用 (该区内存总大小)]

(2)中括号外:GC 回收前堆内存占用->GC 后堆内存占用 (堆总大小)

(3)Minor GC 堆内存总容量 = 9 / 10 年轻代 + 老年代,原因:Survivor 区只计算 from 区,而 JVM 默认年轻代中 Eden 区、Survivor 区的比例关系:Eden : Survivor0 : Survivor1 = 8 : 1 : 1

6、时间

(1)user:进程执行用户态代码(核心之外)所使用时间,即执行此进程所使用的实际 CPU 时间,不包括其他进程、此进程阻塞时间;在垃圾收集的情况下,表示 GC 线程执行所使用 CPU 总时间

(2)sys:进程在内核态所消耗 CPU 时间,即在内核执行系统调用 / 等待系统事件所使用 CPU 时间

(3)real:程序从开始到结束所用的时钟时间,包括其他进程使用时间片、进程阻塞的时间(比如等待 I/O 完成),对于并行 GC,该值 ≈(用户时间+系统时间)/ 垃圾收集器使用的线程数

(4)因为存在多核,一般是多线程并发 GC,所以一般 GC 事件中,real time < sys time + user time;如果 real > sys + user,则应用可能存在下列问题:I/O 负载过重、CPU 不够用

 

GC 日志分析工具

1、GCEasy

(1)在线 GC 日志分析器

(2)通过 GC 日志分析进行内存泄露检测、GC 暂停原因分析、JVM 配置建议优化等功能

(3)多数功能免费

2、GCViewer

(1)离线 GC 日志分析器

(2)可视化 Java VM 选项 -verbose:gc 和 .NET 生成的数据 -Xloggc:<file>

(3)计算与垃圾回收相关的性能指标:吞吐量、累积的暂停、最长的暂停等

3、HPjmeter

(1)只能打开由 -verbose:gc、-Xloggc:gc.log 参数生成的 GC log

(2)添加其他参数生成的 GC.log 无法打开

(3)集成 HPjtune 功能,可以分析在 HP 机器上产生的垃圾回收日志文件

posted @   半条咸鱼  阅读(156)  评论(0编辑  收藏  举报
(评论功能已被禁用)
相关博文:
阅读排行:
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
点击右上角即可分享
微信分享提示