前言
jvm垃圾回收机制-GC基础知识、jvm基本组成、查看、排查
文章目录
- 前言
- GC基础知识
- 概述
- JVM
- 基本组成
- 1. 虚拟机的组成
- 2. jvm的内存区域
- 查看jvm
- 排查jvm问题
- 1. 正常运行的系统
- 2. 对于已经发生了OOM的系统
GC基础知识
概述
-
什么是垃圾
- 一个对象没有被引用,没有任何对象去引用它,那么它所占用的内存就是垃圾
- 几个对象相互循环引用,但是没有栈空间/外部对象去引用它们
-
如何定位垃圾
- 引用计数:不能解决循环引用
- 根可达算法、根搜索算法:根对象及其引用的对象是有用的(调用链),其他的都是垃圾
- 根对象:线程栈变量、静态变量、常量池、JNI指针
-
常见的垃圾回收算法
- 标记清除:Mark-Sweep
- 空间不连续,产生碎片
- 拷贝:Copying
- 连续没有碎片
- 浪费空间
- 标记压缩:Mark-Compact
- 没有碎片
- 效率偏低
- 标记清除:Mark-Sweep
-
jvm内存分代模型-用于垃圾回收
- 分区
- 新生代:new、young
- 老年代:old
- 永久代(1.7)、元数据区(1.8)
- 新生代(Young):Eden+2个suvivor区;YGC回收
- 老年代(Old):存储顽固分子;老年代满了触发FGC
- GC Tuning(Generation):尽量减少FGC
- MinorGC=YGC:对新生代堆进行gc
- MajorGC=FGC:全堆范围的gc
- 分区
-
垃圾回收器
-
类别
- Serial:年轻代-串行回收
- Parallel:年轻代-并行回收
- ParNew:年轻代-配合CMS的并行回收
- SerialOld:老年代
- ParallelOld:老年代
- ConcurrentMarkSweep:老年代;并发-垃圾回收和应用程序同时运行,降低STW的时间(200ms)
- G1
- ZGC
- Shenandoah
- Eplison
-
jdk1.8默认PS+ParallelOld
-
-
jvm调优
- 第一步:了解生成环境下的垃圾回收器组合
JVM
基本组成
1. 虚拟机的组成
java能实现跨平台,是因为在不同平台上运行不同的虚拟机决定的,因此java文件的执行不直接在操作系统上执行,而是通过jvm(虚拟机)执行
2. jvm的内存区域
- 运行时数据区
- 堆
- 方法区(1.7):jvm
- 元空间(1.8):内存
- 线程私有
- 虚拟机栈:Java方法
- 本地方法栈:Native方法(非Java,直接与操作系统交互)
- 程序计数器–不会发生内存泄漏
查看jvm
- 可视化工具:控制台->jvisualvm
排查jvm问题
1. 正常运行的系统
- 可以使用jmap来查看/VM中各个区域的使用情况
- 可以通过jstack来查看线程的运行情况,比如哪些线程阻塞,是否出现了死锁
- 可以通过jstat命令来查看垃圾回收的情况,特别是fullgc,如果发现fullgc比较频繁,那么就得进行调优了
- 通过各个命令的结果,或者jivisualvm等工具来进行分析
- 首先,初步猜测顺繁发生fullgc的原因,如果颇繁发生fullgc但是又一直没有出现内存溢出,那么表示fgc实际上是回收了很多对象了,所以这些对象最好能在younggc过程中就直接回收掉,避免这些对象进入到老年代,对于这种情况,就要考虑这些存活时间不长的对象是不是比较大,导致年轻代放不下,直接进入到了老年代,尝试加大年轻代的大小,如果改完之后,fgc减少,则证明修改有效
- 同时,还可以找到占用CPU最多的线程,定位到具体的方法,优化这个方法的执行,看是否能避免某些对象的创建,从而节省内存
2. 对于已经发生了OOM的系统
- 一般生产系统中都会设置当系统发生了OOM时,生成当时的dump文件(-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/usr/local/base
- 利用jvisualvm等工具来分析dump文件
- 根据dump文件找到异常的实例对象,和异常的线程(占用CPU高),定位到具体的代码
- 然后再进行详细的分析和调试
总之,调优不是一蹴而就的,需要分析、推理,实践,总结,再分析,最终定位到具体的问题