collector种类
GC在 HotSpot VM 5.0里有四种:
incremental (sometimes called train) low pause collector已被废弃,不在介绍.
类别
|
serial collector |
parallel collector (throughput collector) |
concurrent collector
(concurrent low pause collector)
|
介绍
|
单线程收集器
使用单线程去完成所有的gc工作,没有线程间的通信,这种方式会相对高效
|
并行收集器
使用多线程的方式,利用多CUP来提高GC的效率
主要以到达一定的吞吐量为目标
|
并发收集器
使用多线程的方式,利用多CUP来提高GC的效率
并发完成大部分工作,使得gc pause短
|
试用场景
|
单处理器机器且没有pause time的要求 |
适用于科学技术和后台处理
有中规模/大规模数据集大小的应用且运行在多处理器上,关注吞吐量(throughput)
|
适合中规模/大规模数据集大小的应用,应用服务器,电信领域
关注response time,而不是throughput
|
使用
|
Client模式下默认
可使用
可用-XX:+UseSerialGC强制使用
优点:对server应用没什么优点
缺点:慢,不能充分发挥硬件资源 |
Server模式下默认
--YGC:PS FGC:Parallel MSC
可用-XX:+UseParallelGC或-XX:+UseParallelOldGC强制指定
--ParallelGC代表FGC为Parallel MSC
--ParallelOldGC代表FGC为Parallel Compacting
优点:高效
缺点:当heap变大后,造成的暂停时间会变得比较长
|
可用-XX:+UseConcMarkSweepGC强制指定 优点:
对old进行回收时,对应用造成的暂停时间非常端,适合对latency要求比较高的应用 缺点:
1.内存碎片和浮动垃圾
2.old去的内存分配效率低
3.回收的整个耗时比较长
4.和应用争抢CPU
|
内存回收触发
|
YGC eden空间不足 FGC old空间不足
perm空间不足
显示调用System.gc() ,包括RMI等的定时触发 YGC时的悲观策略
dump live的内存信息时(jmap –dump:live)
|
YGC eden空间不足 FGC old空间不足
perm空间不足
显示调用System.gc() ,包括RMI等的定时触发 YGC时的悲观策略--YGC前&YGC后
dump live的内存信息时(jmap –dump:live)
|
YGC eden空间不足 CMS GC 1.old Gen的使用率大的一定的比率 默认为92%
2.配置了CMSClassUnloadingEnabled,且Perm Gen的使用达到一定的比率 默认为92%
3.Hotspot自己根据估计决定是否要触法
4.在配置了ExplictGCInvokesConcurrent的情况下显示调用了System.gc. Full GC(Serial MSC) promotion failed 或 concurrent Mode Failure时; |
内存回收触发时发生了什么
|
YGC 清空eden+from中所有no ref的对象占用的内存
将eden+from中的所有存活的对象copy到to中
在这个过程中一些对象将晋升到old中:
--to放不下的
--存活次数超过tenuring threshold的
重新计算Tenuring Threshold;
单线程做以上动作
全程暂停应用 FGC 如果配置了CollectGen0First,则先触发YGC
清空heap中no ref的对象,permgen中已经被卸载的classloader中加载的class的信息
单线程做以上动作
全程暂停应用 |
YGC 同serial动作基本相同,不同点:
1.多线程处理
2.YGC的最后不仅重新计算Tenuring Threshold,还会重新调整Eden和From的大小 FGC
1.如配置了ScavengeBeforeFullGC(默认),则先触发YGC(??)
2.MSC:清空heap中的no ref对象,permgen中已经被卸载的classloader中加载的class信息,并进行压缩
3.Compacting:清空heap中部分no ref的对象,permgen中已经被卸载的classloader中加载的class信息,并进行部分压缩
多线程做以上动作.
|
YGC
同serial动作基本相同,不同点:
1.多线程处理 CMSGC: 1.old gen到达比率时只清除old gen中no ref的对象所占用的空间
2.perm gen到达比率时只清除已被清除的classloader加载的class信息 FGC 同serial |
细节参数
|
可用-XX:+UseSerialGC强制使用
-XX:SurvivorRatio=x,控制eden/s0/s1的大小
-XX:MaxTenuringThreshold,用于控制对象在新生代存活的最大次数
-XX:PretenureSizeThreshold=x,控制超过多大的字节的对象就在old分配. |
-XX:SurvivorRatio=x,控制eden/s0/s1的大小
-XX:MaxTenuringThreshold,用于控制对象在新生代存活的最大次数
-XX:UseAdaptiveSizePolicy 去掉YGC后动态调整eden from已经tenuringthreshold的动作
-XX:ParallelGCThreads 设置并行的线程数
|
-XX:CMSInitiatingOccupancyFraction 设置old gen使用到达多少比率时触发
-XX:CMSInitiatingPermOccupancyFraction,设置Perm Gen使用到达多少比率时触发
-XX:+UseCMSInitiatingOccupancyOnly禁止hostspot自行触发CMS GC |
注:
-
throughput collector与concurrent low pause collector的区别是throughput collector只在young area使用使用多线程,而concurrent low pause collector则在tenured generation也使用多线程。
-
根据官方文档,他们俩个需要在多CPU的情况下,才能发挥作用。在一个CPU的情况下,会不如默认的serial collector,因为线程管理需要耗费CPU资源。而在两个CPU的情况下,也提高不大。只是在更多CPU的情况下,才会有所提高。当然 concurrent low pause collector有一种模式可以在CPU较少的机器上,提供尽可能少的停顿的模式,见CMS GC Incremental mode。
-
当要使用throughput collector时,在java opt里加上-XX:+UseParallelGC,启动throughput collector收集。也可加上-XX:ParallelGCThreads=<desired number>来改变线程数。还有两个参数 -XX:MaxGCPauseMillis=<nnn>和 -XX:GCTimeRatio=<nnn>,MaxGCPauseMillis=<nnn>用来控制最大暂停时间,而-XX: GCTimeRatio可以提高GC说占CPU的比,以最大话的减小heap。
附注SUN的官方说明:
1. The throughput collector: this collector uses a parallel version of the young generation collector. It is used if the -XX:+UseParallelGC option is passed on the command line. The tenured generation
collector is the same as the serial collector.
2. The concurrent low pause collector: this collector is used if the -Xincgc™ or -XX:+UseConcMarkSweepGC is passed on the command line. The concurrent collector is used to collect the tenured
generation and does most of the collection concurrently with the execution of the application. The application is paused for short periods during the collection. A parallel version of the young generation copying collector is used with the concurrent collector.
The concurrent low pause collector is used if the option -XX:+UseConcMarkSweepGC is passed on the command line.
3. The incremental (sometimes called train) low pause collector: this collector is used only if -XX:+UseTrainGC is passed on the command line. This collector has not changed since the J2SE Platform
version 1.4.2 and is currently not under active development. It will not be supported in future releases. Please see the 1.4.2 GC Tuning Document for information on this collector.
CMS GC Incremental mode
当要使用 concurrent low pause collector时,在java的opt里加上 -XX:+UseConcMarkSweepGC。concurrent low pause collector还有一种为CPU少的机器准备的模式,叫Incremental mode。这种模式使用一个CPU来在程序运行的过程中GC,只用很少的时间暂停程序,检查对象存活。
在Incremental mode里,每个收集过程中,会暂停两次,第二次略长。第一次用来,简单从root查询存活对象。第二次用来,详细检查存活对象。整个过程如下:
* stop all application threads; do the initial mark; resume all application threads(第一次暂停,初始话标记)
* do the concurrent mark (uses one procesor for the concurrent work)(运行是标记)
* do the concurrent pre-clean (uses one processor for the concurrent work)(准备清理)
* stop all application threads; do the remark; resume all application threads(第二次暂停,标记,检查)
* do the concurrent sweep (uses one processor for the concurrent work)(运行过程中清理)
* do the concurrent reset (uses one processor for the concurrent work)(复原)
当要使用Incremental mode时,需要使用以下几个变量:
-XX:+CMSIncrementalMode default: disabled 启动i-CMS模式(must with -XX:+UseConcMarkSweepGC)
-XX:+CMSIncrementalPacing default: disabled 提供自动校正功能
-XX:CMSIncrementalDutyCycle=<N> default: 50 启动CMS的上线
-XX:CMSIncrementalDutyCycleMin=<N> default: 10 启动CMS的下线
-XX:CMSIncrementalSafetyFactor=<N> default: 10 用来计算循环次数
-XX:CMSIncrementalOffset=<N> default: 0 最小循环次数(This is the percentage (0-100) by which the incremental mode duty cycle is shifted to the right within the period between minor collections.)
-XX:CMSExpAvgFactor=<N> default: 25 提供一个指导收集数
SUN推荐的使用参数是:
-XX:+UseConcMarkSweepGC \
-XX:+CMSIncrementalMode \
-XX:+CMSIncrementalPacing \
-XX:CMSIncrementalDutyCycleMin=0 \
-XX:CMSIncrementalDutyCycle=10 \
-XX:+PrintGC Details \
-XX:+PrintGCTimeStamps \
-XX:-TraceClassUnloading
注:如果使用throughput collector和concurrent low pause collector,这两种垃圾收集器,需要适当的挺高内存大小,以为多线程做准备。
如何选择collector:
-
app运行在单处理器机器上且没有pause time的要求,让vm选择或者
UseSerialGC
.
-
重点考虑peak application performance(高性能),没有pause time太严格要求,让vm选择或者UseParallelGC+
UseParallelOldGC
(optionally).
-
重点考虑response time,pause time要小,UseConcMarkSweepGC
.
Garbage Collctor – Future
-
Garbage First(G1)
jdk1.6 update 14 or jdk7
-
few flags need to set
-XX:MaxGCPauseMillis=100
-XX:GCPauseIntervalMillis=6000
还没尝试过使用…
Summary
import java.util.ArrayList;
import java.util.List;
public class SummaryCase {
public static void main(String[] args) throws InterruptedException {
List<Object> caches = new ArrayList<Object>();
for (int i = 0; i < 7; i++) {
caches.add(new byte[1024 * 1024 * 3]);
Thread.sleep(1000);
}
caches.clear();
for (int i = 0; i < 2; i++) {
caches.add(new byte[1024 * 1024 * 3]);
Thread.sleep(1000);
}
}
}
用以下两种参数执行,会执行几次YGC几次FGC?
-
-Xms30M -Xmx30M -Xmn10M -Xloggc:gc.log -XX:+PrintTenuringDistribution -XX:+UseParallelGC
2.062: [GC
Desired survivor size 1310720 bytes, new threshold 7 (max 15)
6467K->6312K(29440K), 0.0038214 secs]
4.066: [GC
Desired survivor size 1310720 bytes, new threshold 7 (max 15)
12536K->12440K(29440K), 0.0036804 secs]
6.070: [GC
Desired survivor size 1310720 bytes, new threshold 7 (max 15)
18637K->18584K(29440K), 0.0040175 secs]
6.074: [Full GC 18584K->18570K(29440K), 0.0031329 secs]
8.078: [Full GC 24749K->3210K(29440K), 0.0045590 secs]
(具体分析见
http://rdc.taobao.com/team/jm/archives/440)
-
-Xms30M -Xmx30M -Xmn10M -Xloggc:gc.log -XX:+PrintTenuringDistribution -XX:+UseSerialGC
2.047: [GC
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 1: 142024 bytes, 142024 total
6472K->6282K(29696K), 0.0048686 secs]
4.053: [GC
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 2: 141880 bytes, 141880 total
12512K->12426K(29696K), 0.0047334 secs]
6.058: [GC
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 3: 141880 bytes, 141880 total
18627K->18570K(29696K), 0.0049135 secs]
8.063: [Full GC 24752K->3210K(29696K), 0.0077895 secs]
(具体分析见http://rdc.taobao.com/team/jm/archives/458)
参考:
- http://jiangyongyuan.iteye.com/blog/356502
- http://www.helloying.com/blog/archives/164
- http://hi.baidu.com/sdausea/blog/item/c599ef13fcd3a7dbf6039e12.html
- Tuning Garbage Collection with the 1.4.2 JavaTM Virtual
Machine .
- http://blog.bluedavy.com/?p=200
- http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
redcreen
分享到:
相关推荐
Java虚拟机(JVM)是Java...阅读“java hotspot vm options.pdf”、“java se 6 hotspot[tm] virtual machine garbage collection tuning.pdf”和“java工具选项文档.pdf”等资料,将有助于深入学习和实践这些知识。
6. **JVM优化**:JVM提供了多种工具和选项来查看和调整其行为,如`javap`用于反汇编字节码,`-verbose:gc`用于输出GC日志,`-XX:`系列参数可以调整JVM的内存设置、垃圾收集策略等。 了解JVM的底层原理对于Java...
### JVM技术精华——架构师必备知识点详解 #### 一、HotSpot VM介绍及发展历程 **HotSpot VM**作为Sun JDK和OpenJDK的核心组件之一,是当前应用最为广泛的Java虚拟机。HotSpot VM最初并不是由Sun公司开发,而是...
2. **HotSpot VM**:1997年,Sun公司收购了HotSpot VM,这是一个具有动态编译能力的JVM,能够根据程序运行情况优化代码,显著提升了性能。HotSpot后来成为了Java SE的标准JVM。 3. **Java 2 Platform, Standard ...
JVM的种类繁多,包括Sun Classic VM、Exact VM、HotSpot VM、JRockit(由BEA公司开发,后被Oracle收购)、J9(IBM公司的产品)以及阿里巴巴的TaobaoJVM。其中,HotSpot VM是Sun JDK和OpenJDK的标准虚拟机,以其热点...
**HotSpot VM**是目前最流行的JVM实现之一,由Sun Microsystems开发,现归Oracle所有。HotSpot VM采用了分代收集的概念,将堆空间分为年轻代和老年代。 - **年轻代**:主要用于存放新创建的对象,通常包括Eden区和...
JVM的发展历程中,Sun Classic VM是首个版本,仅支持解释器,而Exact VM引入了编译器,但最终被HotSpot VM所替代,HotSpot VM目前是最广泛使用的JVM,与其他如JRocket VM和IBM J9共同构成高性能虚拟机的代表。...
例如,通过分析HotSpot VM源码可以了解到更多关于内存分配、垃圾收集的细节。 总之,"JVM培训ppt"涵盖了Java开发中的重要概念,对理解JVM的工作原理、提升代码运行效率、优化内存管理等方面都有极大的帮助。通过...
Hotspot源码是Java开发中的重要参考资料,它揭示了Java虚拟机(JVM)的工作原理。Oracle JDK中的Hotspot JVM是Java程序运行的核心,负责字节码解释、编译优化以及垃圾回收等关键任务。Hotspot源码的分析有助于开发者...
《Java平台标准版HotSpot虚拟机垃圾收集调优指南》是针对Java HotSpot虚拟机(Java HotSpot VM)内建的垃圾收集算法的一份详细指南,旨在帮助开发者和系统管理员选择最适合他们应用需求的垃圾收集策略。这份文档适用...
此外,`-XX:+UseCMSInitiatingOccupancyOnly`确保CMS始终使用指定的占用率阈值,而不是依赖HotSpot VM的自适应计算。`-XX:+UseParNewGC`和`-XX:ParallelGCThreads=2`则用于控制新生代的并行回收和线程数。`-XX:+...
- **2000年**:Hotspot虚拟机作为默认的JVM被集成到了JDK 1.3中,标志着JVM性能的一个重要转折点。 - **2002年**:Classic VM退出历史舞台,此时的Java生态系统已经非常成熟,各种工具和框架逐渐完善。 - **2004年**...
其他实现:BEA公司 JRocket、IBM j9、zing 号称世界最快JVM、taobao.vm。从广义上讲Java,Kotlin、Clojure、JRuby、Groovy等运行于Java虚拟机上的编程语言及其相关的程序都属于Java技术体系中的一员。
4. **HotSpot JVM**:2000年,Sun Microsystems收购了HotSpot VM,这是一个具有动态编译功能的JVM,能够将频繁执行的代码转化为机器码,显著提升性能。 5. **Java SE 5/6**:这两个版本引入了泛型、枚举、可变参数...
- HotSpot VM的编译优化技术:内联缓存、逃逸分析等。 2. **JNI技术解析** - JNI(Java Native Interface)接口的功能。 - 使用JNI调用本地方法的过程。 - JNI开发中需要注意的问题及最佳实践。 3. **Java模块...
15. **-XX+UseCMSInitiatingOccupancyOnly**:指定HotSpot VM总是使用XX:CMSInitiatingOccupancyFraction的值。 16. **-XX:MaxTenuringThreshold**:晋升老年代的对象年龄阈值。 17. **-XX:+PrintClassHistogram**:...
- Sun Classic/Exact VM:世界上第一款商用Java虚拟机,随JDK 1.0发布,后来被HotSpot VM取代。 - HotSpot VM:成为JDK 1.3默认虚拟机,并且是目前使用最广泛的虚拟机之一。 - Mobile/Embedded VM:适用于移动或...