垃圾收集器相关

注重吞吐量以及cpu敏感场合,jdk1.6之后, 都可以优先考虑 parallel scavenge + parallel old (标记-整理算法)组合.

parallel: 并行方式,此时用户线程在等待状态

concurrent:并发,用户线程和垃圾收集线程同时进行,垃圾收集线程在额外cpu上执行(多cpu情况适用)

parallel Scavenge收集器(关注在吞吐量方面优化的收集器,吞吐量优先收集器):

吞吐量 = 运行用户代码的时间/(运行用户代码时间+垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾回收花费1分钟, 吞吐量=99%

停顿时间越短,越适用需要与用户交互的程序,良好的响应速度提升用户体验.

高吞吐量的可以高效率的运用cpu时间,尽快完成计算任务,主要适合在后台运算不需要太多交互的任务.

jdk1.6之前, 如果使用parallel scavenge收集器, 老年代只能使用serial old收集器, 导致整体吞吐量无法最大化.

jdk1.6之后,出现parallel old收集器, 在注重吞吐量以及cpu敏感场合, 都可以优先考虑 parallel scavenge + parallel old 组合.

CMS 收集器(标记-清除算法)

是一种以获取最短回收停顿时间为目标的收集器,目前很大部分java应用集中在互联网站或者b/s系统的服务端上,

这类应用重视响应速度,希望系统停顿时间短,CMS收集器非常符合这类应用的需求.

存在3个缺点:

1. 对cpu资源敏感, CMS默认启动线程数(cpu数量+3)/4,如果cpu数量少于4个,则导致用户线程cpu资源缺失,

导致用户程序响应慢.

2. CMS收集器无法处理浮动垃圾,可能出现 Concurrent Mode failure, 导致另一次Full Gc发生.

浮动垃圾:由于CMS运行时,用户线程还在运行,伴随着程序运行有新的垃圾产生,这一部分出现在标记之后, 本次gc无法处理

,只好留在下一次gc时在清理掉, 这一部分为浮动垃圾.有浮动垃圾存在, 则需要收集器额外预留空间,如果cms预留内存无法

满足程序需要, 则会出现concurrent mode failure, 这时虚拟机会临时启用serial old进行老年代收集, 这样停顿时间就长

了,-XX:CMSInitialtingOccupancyFraction设置过高会产生此现象.

3. 使用标记清除算法,会产生碎片.-XX:CMSFullGCsBeforeCompaction,这个参数表示执行多少次不压缩的Full

Gc之后, 进行一次压缩FullGc, 默认是0, 即每次都进行压缩FullGC

G1收集器优点(从1.7之后)

1. 并行与并发, G1能充分利用多cpu 多核环境硬件优势,使用多cpu或者多核来锁定stop-the-world停顿时间.

2. 分代收集.G1可以不需要其他收集器配合就能独立管理整个GC堆,但G1可以使用不同的方式去处理新创建的对象

和一级存活一段时间/熬过多次gc的旧对象以获取更改的收集效果.

3.空间整合,g1整体使用标记-整理算法,从局部2个region之间看, 是基于复制算法实现的.2种算法不产生内存碎片.

4.可预测的停顿,g1除了追求低停顿之外,还能建立可预测的停顿时间模型,能让使用者指定一个长度为M毫秒的时间内,

消耗在垃圾收集器上的时间不超过N毫秒.这已经是实时java的垃圾收集器的特征了.

排查内存溢出参数:

如果内存溢出, 可以加上参数-XX:+HeapDumpOnOutMemoryError, (如果为堆外内存溢出, 则不产生异常日志)

本地内存只有在FullGC触发时才能进行回收

一个应用jvm配置:

java -Xms32g -Xmx32g -Xss256k -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75

 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC


解析: 内存Xms-Xmx均为32G,设置相等, 避免内存浮动带来影响.

新生代垃圾收集器:
parallelGC,老生代垃圾收集器:CMS

      DisableExplicitGC: 失效system.gc()