不可思议,竟然还有人不会查看 GC 垃圾回收日志?
关注“Java后端技术全栈”
回复“面试”获取全套面试资料
日志的重要性,不需要过多强调了。通过日志,我们可以发现程序可能有内存(泄露)问题。本文从案例出发,具体介绍这些日志信息,以期帮助大家更好地了解垃圾回收的运行情况。
还是先上图,看看本文的主要内容:
我们先来看个案例,代码如下:
启动参数设置:
XX:+PrintGCDetails
运行main方法,输出
关于GC日志的参数
参数案例
参数解释:
-XX:+PrintGCDetails
启用日志
-XX:-UseAdaptiveSizePolicy
禁用动态调整,使SurvivorRatio
可以起作用
-XX:SurvivorRatio=8
设置Eden:Survivior
=8:1
-XX:NewSize=10M -XX:MaxNewSize=10M
设置整个新生代的大小为10M
写了一个Spring Boot项目,非常简单的项目,里面写了一个controller
这段代码其实是想后面演示OOM
用的,都行吧,这里先用他来看看GC
垃圾回收日志。
在IDEA中设置
输出结果
抓出一段来聊聊
GC (minor )日志
(Allocation Failure):表明本次引起
GC
的原因是因为在年轻代中没有足够的空间能够存储新的数据了。
PSYoungGen
:表示是GC
类型
8525K
:YoungGC
前新生代内存占用
352K
:YoungGC
新生代内存占用9216K:新生代总共大小
98695K:YoungGC前JVM内存占用
98486K:YoungGC后JVM内存使用
130048K:JVM堆总大小
0.0092873 secs
:YoungGC
耗时
user=0.00
:YoungGC
用户耗时
sys=0.00
:YoungGC
系统耗时real=
0.01:YoungGC
实际耗时(这里居然四舍五入了)
Full GC 日志
PSYoungGen: 8051K->7817K(9216K)
:新生代区GC
前后和总大小
ParOldGen: 244969K->244969K(245760K)
:老年代GC
前后和大小。
253020K->252786K(254976K)
:堆GC
前后内存占用情况。
Metaspace: 29386K->29386K(1077248K)
:元空间GC
前后和总大小后面那几项和上面一样
GC垃圾回收日志就是这么简单么~蓝(nan)不蓝(nan)?
推荐阅读:
《Spring Cloud与Docker微服务架构实战》.pdf
版权声明: 本文为 InfoQ 作者【田维常】的原创文章。
原文链接:【http://xie.infoq.cn/article/844455d8a887c3cdfa3f2a324】。文章转载请联系作者。
评论