JVM GC机制收集器与GC调优Word文档格式.docx
- 文档编号:22669361
- 上传时间:2023-02-05
- 格式:DOCX
- 页数:20
- 大小:87.45KB
JVM GC机制收集器与GC调优Word文档格式.docx
《JVM GC机制收集器与GC调优Word文档格式.docx》由会员分享,可在线阅读,更多相关《JVM GC机制收集器与GC调优Word文档格式.docx(20页珍藏版)》请在冰豆网上搜索。
1.JVM会试图为相关Java对象在Eden中初始化一块内存区域;
2.当Eden空间足够时,内存申请结束。
否则到下一步;
3.JVM试图释放在Eden中所有不活跃的对象(minorcollection),释放后若Eden空间仍然不足以放入新对象,则试图将部分Eden中活跃对象放入Survivor区;
4.Survivor区被用来作为Eden及old的中间交换区域,当OLD区空间足够时,Survivor区的对象会被移到Old区,否则会被保留在Survivor区;
5.当old区空间不够时,JVM会在old区进行majorcollection;
6.完全垃圾收集后,若Survivor及old区仍然无法存放从Eden复制过来的部分对象,导致JVM无法在Eden区为新对象创建内存区域,则出现"
Outofmemory错误"
;
2.3.2、对象衰老过程
1.新创建的对象的内存都分配自eden。
Minorcollection的过程就是将eden和在用survivorspace中的活对象copy到空闲survivorspace中。
对象在younggeneration里经历了一定次数(可以通过参数配置)的minorcollection后,就会被移到oldgeneration中,称为tenuring。
GC触发条件
GC类型
触发条件
触发时发生了什么
注意
查看方式
YGC
eden空间不足
清空Eden+fromsurvivor中所有noref的对象占用的内存
将eden+fromsur中所有存活的对象copy到tosur中
一些对象将晋升到old中:
tosur放不下的
存活次数超过turningthreshold中的
重新计算tenuringthreshold(serialparallelGC会触发此项)
重新调整Eden和from的大小(parallelGC会触发此项)
全过程暂停应用
是否为多线程处理由具体的GC决定
jstat–gcutil
gclog
FGC
old空间不足
perm空间不足
显示调用System.GC,RMI等的定时触发
YGC时的悲观策略
dumplive的内存信息时(jmap–dump:
live)
清空heap中noref的对象
permgen中已经被卸载的classloader中加载的class信息
如配置了CollectGenOFirst,则先触发YGC(针对serialGC)
如配置了ScavengeBeforeFullGC,则先触发YGC(针对serialGC)
是否压缩需要看配置的具体GC
permanentgeneration空间不足会引发FullGC,仍然不够会引发PermGenSpace错误。
三、GC监视、收集器与GC调优
3.1、监视JVMGC
首先说一下如何监视JVMGC,可以用JDK中的jstat工具,也可以在java程序启动的opt里加上如下几个参数(注:
这两个参数只针对SUN的HotSpotVM):
1.-XX:
-PrintGCPrintmessagesatgarbagecollection.Manageable.
2.-XX:
-PrintGCDetailsPrintmoredetailsatgarbagecollection.Manageable.(Introducedin1.4.0.)
3.-XX:
-PrintGCTimeStampsPrinttimestampsatgarbagecollection.Manageable(Introducedin1.4.0.)
当把-XX:
-PrintGCDetails加入到javaopt里以后可以看见如下输出:
[GC[DefNew:
34538K->
2311K(36352K),0.0232439secs]45898K->
15874K(520320K),0.0233874secs]
[FullGC[Tenured:
13563K->
15402K(483968K),0.2368177secs]21163K->
15402K(520320K),[Perm:
28671K->
28635K(28672K)],0.2371537secs]
他们分别显示了JVMGC的过程,清理出了多少空间。
第一行GC使用的是‘普通GC’(MinorCollections),第二行使用的是‘全GC’(MajorCollections)。
他们的区别很大,在第一行最后我们可以看见他的时间是0.0233874秒,而第二行的FullGC的时间是0.2371537秒。
第二行的时间是第一行的接近10倍,也就是我们这次调优的重点,减少FullGC的次数,以为FullGC会暂停程序比较长的时间,如果FullGC的次数比较多。
程序就会经常性的假死。
注:
GC信息的格式
[GC[<
collector>
:
<
startingoccupancy1>
->
endingoccupancy1>
<
pausetime1>
secs]<
startingoccupancy3>
endingoccupancy3>
pausetime3>
secs]
<
collector>
GC为minor收集过程中使用的垃圾收集器起的内部名称.
startingoccupancy1>
younggeneration在进行垃圾收集前被对象使用的存储空间.
endingoccupancy1>
younggeneration在进行垃圾收集后被对象使用的存储空间
minor收集使应用暂停的时间长短(秒)
startingoccupancy3>
整个堆(HeapSize)在进行垃圾收集前被对象使用的存储空间
整个堆(HeapSize)在进行垃圾收集后被对象使用的存储空间
整个垃圾收集使应用暂停的时间长短(秒),包括major收集使应用暂停的时间(如果发生了major收集).
GC信息的选项
-XX:
+PrintGCDetails显示GC的详细信息
+PrintGCApplicationConcurrentTime打印应用执行的时间
+PrintGCApplicationStoppedTime打印应用被暂停的时间
3.2、collector收集器的种类
GC在HotSpotVM5.0里有四种:
incremental(sometimescalledtrain)lowpausecollector已被废弃,不在介绍.
类别
serialcollector
parallelcollector
(
throughputcollector
)
concurrentcollector
(concurrentlowpausecollector)
介绍
单线程收集器
使用单线程去完成所有的gc工作,没有线程间的通信,这种方式会相对高效
并行收集器
使用多线程的方式,利用多CUP来提高GC的效率
主要以到达一定的吞吐量为目标
并发收集器
使用多线程的方式,利用多CUP来提高GC的效率
并发完成大部分工作,使得gcpause短
试用场景
单处理器机器且没有pausetime的要求
适用于科学技术和后台处理
有中规模/大规模数据集大小的应用且运行在多处理器上,关注吞吐量(throughput)
适合中规模/大规模数据集大小的应用,应用服务器,电信领域
关注responsetime,而不是throughput
使用
Client模式下默认
可使用
可用-XX:
+UseSerialGC强制使用
优点:
对server应用没什么优点
缺点:
慢,不能充分发挥硬件资源
Server模式下默认
--YGC:
PSFGC:
ParallelMSC
+UseParallelGC或-XX:
+UseParallelOldGC强制指定
--ParallelGC代表FGC为ParallelMSC
--ParallelOldGC代表FGC为ParallelCompacting
高效
当heap变大后,造成的暂停时间会变得比较长
+UseConcMarkSweepGC强制指定
对old进行回收时,对应用造成的暂停时间非常端,适合对latency要求比较高的应用
1.内存碎片和浮动垃圾
2.old去的内存分配效率低
3.回收的整个耗时比较长
4.和应用争抢CPU
内存回收触发
显示调用System.gc(),包括RMI等的定时触发
YGC时的悲观策略--YGC前&
YGC后
CMSGC
1.oldGen的使用率大的一定的比率默认为92%
2.配置了CMSClassUnloadingEnabled,且PermGen的使用达到一定的比率默认为92%
3.Hotspot自己根据估计决定是否要触法
4.在配置了ExplictGCInvokesConcurrent的情况下显示调用了System.gc.
FullGC(SerialMSC)
promotionfailed或concurrentModeFailure时;
内存回收触发时发生了什么
同serial动作基本相同,不同点:
1.多线程处理
2.YGC的最后不仅重新计算TenuringThreshold,还会重新调整Eden和From的大小
1.如配置了ScavengeBeforeFullGC(默认),则先触发YGC(?
?
2.MSC:
清空heap中的noref对象,permgen中已经被卸载的classloader中加载的class信息,并进行压缩
3.Compacting:
清空heap中部分noref的对象,permgen中已经被卸载的classloader中加载的class信息,并进行部分压缩
多线程做以上动作.
CMSGC:
1.oldgen到达比率时只清除oldgen中noref的对象所占用的空间
2.permgen到达比率时只清除已被清除的classloader加载的class信息
同serial
细节参数
SurvivorRatio=x,控制eden/s0/s1的大小
MaxTenuringThreshold,用于控制对象在新生代存活的最大次数
PretenureSizeThreshold=x,控制超过多大的字节的对象就在old分配.
UseAdaptiveSizePolicy去掉YGC后动态调整edenfrom已经tenuringthreshold的动作
ParallelGCThreads设置并行的线程数
CMSInitiatingOccupancyFraction设置oldgen使用到达多少比率时触发
CMSInitiatingPermOccupancyFraction,设置PermGen使用到达多少比率时触发
+UseCMSInitiatingOccupancyOnly禁止hostspot自行触发CMSGC
∙throughputcollector与concurrentlowpausecollector的区别是throughputcollector只在youngarea使用使用多线程,而concurrentlowpausecollector则在tenuredgeneration也使用多线程。
∙根据官方文档,他们俩个需要在多CPU的情况下,才能发挥作用。
在一个CPU的情况下,会不如默认的serialcollector,因为线程管理需要耗费CPU资源。
而在两个CPU的情况下,也提高不大。
只是在更多CPU的情况下,才会有所提高。
当然concurrentlowpausecollector有一种模式可以在CPU较少的机器上,提供尽可能少的停顿的模式,见CMSGCIncrementalmode。
∙当要使用throughputcollector时,在javaopt里加上-XX:
+UseParallelGC,启动throughputcollector收集。
也可加上-XX:
ParallelGCThreads=<
desirednumber>
来改变线程数。
还有两个参数-XX:
MaxGCPauseMillis=<
nnn>
和-XX:
GCTimeRatio=<
,MaxGCPauseMillis=<
用来控制最大暂停时间,而-XX:
GCTimeRatio可以提高GC说占CPU的比,以最大话的减小heap。
附注SUN的官方说明:
1.Thethroughputcollector:
thiscollectorusesaparallelversionoftheyounggenerationcollector.Itisusedifthe-XX:
+UseParallelGCoptionispassedonthecommandline.Thetenuredgenerationcollectoristhesameastheserialcollector.
2.Theconcurrentlowpausecollector:
thiscollectorisusedifthe-Xincgc™or-XX:
+UseConcMarkSweepGCispassedonthecommandline.Theconcurrentcollectorisusedtocollectthetenuredgenerationanddoesmostofthecollectionconcurrentlywiththeexecutionoftheapplication.Theapplicationispausedforshortperiodsduringthecollection.Aparallelversionoftheyounggenerationcopyingcollectorisusedwiththeconcurrentcollector.Theconcurrentlowpausecollectorisusediftheoption-XX:
+UseConcMarkSweepGCispassedonthecommandline.
3.Theincremental(sometimescalledtrain)lowpausecollector:
thiscollectorisusedonlyif-XX:
+UseTrainGCispassedonthecommandline.ThiscollectorhasnotchangedsincetheJ2SEPlatformversion1.4.2andiscurrentlynotunderactivedevelopment.Itwillnotbesupportedinfuturereleases.Pleaseseethe1.4.2GCTuningDocumentforinformationonthiscollector.
CMSGCIncrementalmode
当要使用concurrentlowpausecollector时,在java的opt里加上-XX:
+UseConcMarkSweepGC。
concurrentlowpausecollector还有一种为CPU少的机器准备的模式,叫Incrementalmode。
这种模式使用一个CPU来在程序运行的过程中GC,只用很少的时间暂停程序,检查对象存活。
在Incrementalmode里,每个收集过程中,会暂停两次,第二次略长。
第一次用来,简单从root查询存活对象。
第二次用来,详细检查存活对象。
整个过程如下:
*stopallapplicationthreads;
dotheinitialmark;
resumeallapplicationthreads(第一次暂停,初始话标记)
*dotheconcurrentmark(usesoneprocesorfortheconcurrentwork)(运行是标记)
*dotheconcurrentpre-clean(usesoneprocessorfortheconcurrentwork)(准备清理)
dotheremark;
resumeallapplicationthreads(第二次暂停,标记,检查)
*dotheconcurrentsweep(usesoneprocessorfortheconcurrentwork)(运行过程中清理)
*dotheconcurrentreset(usesoneprocessorfortheconcurrentwork)(复原)
当要使用Incrementalmode时,需要使用以下几个变量:
+CMSIncrementalModedefault:
disabled启动i-CMS模式(mustwith-XX:
+UseConcMarkSweepGC)
+CMSIncrementalPacingdefault:
disabled提供自动校正功能
CMSIncrementalDutyCycle=<
N>
default:
50启动CMS的上线
CMSIncrementalDutyCycleMin=<
10启动CMS的下线
CMSIncrementalSafetyFactor=<
10用来计算循环次数
CMSIncrementalOffset=<
0最小循环次数(Thisisthepercentage(0-100)bywhichtheincrementalmodedutycycleisshiftedtotherightwithintheperiodbetweenminorcollections.)
CMSExpAvgFactor=<
25提供一个指导收集数
SUN推荐的使用参数是:
+UseConcMarkSweepGC\
+CMSIncrementalMode\
+CMSIncrementalPacing\
CMSIncrementalDutyCycleMin=0\
CMSIncrementalDutyCycle=10\
+PrintGCDetails\
+PrintGCTimeStamps\
-TraceClassUnloading
如果使用throughputcollector和concurrentlowpausecollector,这两种垃圾收集器,需要适当的挺高内存大小,以为多线程做准备。
3.3、如何选择collector
∙app运行在单处理器机器上且没有pausetime的要求,让vm选择UseSerialGC.
∙重点考虑peakapplicationperformance(高性能),没有pausetime太严格要求,让vm选择或者UseParallelGC+UseParallelOldGC(optionally).
∙重
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- JVM GC机制收集器与GC调优 GC 机制 收集 调优
![提示](https://static.bdocx.com/images/bang_tan.gif)