java垃圾回收GC
垃圾回收时,暂停虚拟机运行
基础假设:大部分对象只存在很短的时间
对于新生代,Minor GC经常会发生
Major/Full GC会对老生代做GC
老生代GC采用Compact算法,移动形成完整的空余区
垃圾回收在什么时候发生?
如果内存满了,内存分配失败时运行;调用system.gc()时运行。
对什么对象进行回收?
从根节点出发,对不可达对象进行回收。
- 垃圾回收根节点
- 局部变量
- 静态变量
- Native方法引用的对象
- 活动线程,等待中的Monitor(wait、notify、synchronized)
新生代:使用复制算法
老年代:使用标记 - 清理 或者 标记 - 整理 算法
JVM调优 |
避免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友好代码
- 当使用Array-based的数据结构(ArrayList,HashMap等)时,尽量减少resize。比如new ArrayList时,尽量估算size,在创建时指定size,减少size可以避免没必要的array copying、gc碎片等问题
- 如果一个List只需要顺序访问,不需要随机访问,用LinkedList代替ArrayList,其本质是链表,不需要resize,但只适用于顺序访问。
从年轻代空间(包括 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将永久代改为元空间