java垃圾回收GC

Posted 2021-02-15 HermioneCancer

垃圾回收时，暂停虚拟机运行

基础假设：大部分对象只存在很短的时间

对于新生代，Minor GC经常会发生
Major/Full GC会对老生代做GC
老生代GC采用Compact算法，移动形成完整的空余区

垃圾回收在什么时候发生？
如果内存满了，内存分配失败时运行；调用system.gc()时运行。

对什么对象进行回收？
从根节点出发，对不可达对象进行回收。

• 垃圾回收根节点
  • 局部变量
  • 静态变量
  • Native方法引用的对象
  • 活动线程，等待中的Monitor（wait、notify、synchronized）

点击查看GC原理

新生代：使用复制算法
老年代：使用标记 - 清理 或者 标记 - 整理 算法

JVM调优

* 三大性能调优参数 * xms，最小堆内存 * xmx，最大堆内存，一般设置为与xms一样，避免出现内存抖动 * xss，是对每个线程栈的调优参数，影响堆栈调用的深度

避免Eden过大（From/To，频繁GC）或过小（频繁YoungGC），建议Eden:From:To=8:1:1，即默认值。-XX:SurvivorRatio

合理设置新生代存活周期，-XX:MaxTenuringThreshold，默认值15。

避免新生代设置过小（频繁YoungGC；大对象，From/To不足->FullGC），过大（新生代变大，YoungGC更耗时；旧生代变小，频繁FullGC），建议新生代:Heap=33%，即Young:Old=1:2。

编写GC友好代码

1. 当使用Array-based的数据结构（ArrayList，HashMap等）时，尽量减少resize。比如new ArrayList时，尽量估算size，在创建时指定size，减少size可以避免没必要的array copying、gc碎片等问题
2. 如果一个List只需要顺序访问，不需要随机访问，用LinkedList代替ArrayList，其本质是链表，不需要resize，但只适用于顺序访问。

Full GC及应对策略
线上FullGC频繁的排查

从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC，对老年代GC称为Major GC,而Full GC是对整个堆来说的，在最近几个版本的JDK里默认包括了对永生代即方法区的回收（JDK8中无永生代了），出现Full GC的时候经常伴随至少一次的Minor GC,但非绝对的。Major GC的速度一般会比Minor GC慢10倍以上。

利用visualvm去查看内存使用量曲线图，如果内存使用量一直维持在较高水平，那就是堆内存不够，需要调大一点。如果频繁发生抖动，那就是程序频繁生成对象并且进行回收，优化代码，保存可重用的对象不要频繁生成。如果内存使用量一直增长，那就是发生内存泄漏或者内存碎片，需要排查代码或者把cms收集器调成gc几次就执行一次标记整理算法来搞定内存碎片（-XX:+UseCMSCompactAtFullCollection、-XX:CMSFullGCsBeforeCompaction）。

Perm Space中保存什么数据？会引起OutOfMemory吗？
加载class文件。

会引起，出现异常可以设置 -XX:PermSize 的大小。JDK 1.8后，字符串常量不存放在永久代，而是在堆内存中，JDK8以后没有永久代概念，而是用元空间替代，元空间不存在虚拟机中，而是使用本地内存。
java8将永久代改为元空间