JVM调优的ampampquot标准参数ampampquot

　　【易错问题】MajorGC和FullGC的区别是什么？触发条件呢？
　　相信大多数人的理解是MajorGC只针对老年代，FullGC会先触发一次MinorGC，不知对否？我参考了R大的分析和介绍，总结了一下相关的说明和分析结论。在基于HotSpotVM的基础角度
　　针对HotSpotVM的实现，它里面的GC其实准确分类只有两大种：PartialGC（部分回收模式）
　　PartialGC代表着并不收集整个GC堆的模式YoungGenerationGC（新生代回收模式）：它主要是进行回收新生代范围内的内存对象的GC回收器。OldTenuredGenerationGC（老年代回收模式）：它主要是针对于回收老年代OldTenuredGeneration范围内的GC垃圾回收器（CMS的ConcurrentCollection是这个模式）。MixedGenerationGC（混合代回收模式）：收集整个younggen以及部分oldgen的GC。只有G1有这个模式FullGC（全体回收模式）
　　FullGC代表着收集整个JVM的运行时堆方法区直接堆外内存的总体范围内。（甚至可以理解为JVM进程范围内的绝大部分范围的数据区域）。
　　它会涵盖了所有的模式和区域包含：YoungGen（新生代）、TenuredGen（老生代）、PermMetaGen（元空间）（JDK8前后的版本）等全局范围的GC垃圾回收模式。
　　在一般情况下MajorGC通常是跟FullGC是等价的，收集整个GC堆。但如果从HotSpotVM底层的细节出发，如果再有人说MajorGC的时候一定要问清楚他想要指的是上面的FullGC还是OldTenuredGC。基于最简单的分代式GC策略触发条件是：YoungGC
　　按HotSpotVM的SerialGC的实现来看，当Younggen中的Eden区分达到阈值（属于一定的百分比进行控制）的时候触发。
　　注意：YoungGC中有部分存活对象会晋升到OldTenuredGen，所以YoungGC后OldGen的占用量通常会有所升高。触发条件是：FullGC当准备要触发一次YoungGC时，如果发现统计数据说之前YoungOldTenuredGen剩余的空间大，则不会触发YoungGC，而是转为触发FullGC（因为HotSpotVM的GC里，除了CMS的Concurrentcollection之外，其它能收集OldTenuredGen的GC都会同时收集整个GC堆，包括Younggen，所以不需要事先触发一次单独的YoungGC）；如果有PermMetagen的话，要在PermMetagen分配空间但已经没有足够空间时，也要触发一次fullGC。System。gc（）方法或者HeapDump自带的GC，默认也是触发FullGC。HotSpotVM里其它非并发GC的触发条件复杂一些，不过大致的原理与上面说的其实一样。
　　注意：ParallelScavenge（XX：UseParallelGC）框架下，默认是在要触发FullGC前先执行一次YoungGC，并且两次GC之间能让应用程序稍微运行一小下，以期降低FullGC的暂停时间（因为youngGC会尽量清理了YoungGen的垃圾对象，减少了FullGC的扫描工作量）。控制这个行为的VM参数是XX：ScavengeBeforeFullGC。触发条件是：ConcurrentGC
　　ConcurrentGC的触发条件就不太一样。以CMSGC为例，它主要是定时去检查OldGen的使用量，当使用量超过了触发比例就会启动一次CMSGC，对Oldgen做并发收集。GC回收器对应的GC模式列举
　　在HotspotJVM实现的SerialGC，ParallelGC，CMS，G1GC中大致可以对应到某个YoungGC和OldGC算法组合；SerialGC算法：SerialYoungGCSerialOldGC（实际上它是全局范围的FullGC）；ParallelGC算法：ParallelYoungGC非并行的PSMarkSweepGC并行的ParallelOldGC（这俩实际上也是全局范围的FullGC），选PSMarkSweepGC还是ParallelOldGC由参数UseParallelOldGC来控制；CMS算法：ParNew（Young）GCCMS（Old）GC（piggybackonParNew的结果老生代存活下来的object只做记录，不做compaction）FullGCforCMS算法（应对核心的CMSGC某些时候的不赶趟，开销很大）；G1GC：YoungGCmixedGC（新生代，再加上部分老生代）FullGCforG1GC算法（应对G1GC算法某些时候的不赶趟，开销很大）；GC回收模式的触发总结搞清楚了上面这些组合，我们再来看看各类GC算法的触发条件。简单说，触发条件就是某GC算法对应区域满了，或是预测快满了。比如，各种YoungGC的触发原因都是eden区满了；SerialOldGCPSMarkSweepGCParallelOldGC的触发则是在要执行YoungGC时候预测其promote的object的总size超过老生代剩余size；CMSGC的initialmarking的触发条件是老生代使用比率超过某值；G1GC的initialmarking的触发条件是Heap使用比率超过某值；FullGCforCMS算法和FullGCforG1GC算法的触发原因很明显，就是4。3和4。4的fancy算法不赶趟了，只能全局范围大搞一次GC了（相信我，这很慢！这很慢！这很慢！）；【坑点与坑点】XX：DisableExplicitGC与NIO的directmemory的关系
　　很多人都见过JVM调优建议里使用这个参数，对吧？但是为什么要用它，什么时候应该用而什么时候用了会掉坑里呢？首先，要了解的是这个参数的作用。在OracleSunJDK这个具体实现上，System。gc（）的默认效果是引发一次stoptheworld的FullGC，由上面所知就是针对于整个GC堆做内存垃圾收集。再次，如果采用了用了XX：DisableExplicitGC参数后，System。gc（）的调用就会变成一个空调用，完全不会触发任何GC（但是函数调用本身的开销还是存在的哦～）。为啥要用这个参数呢？最主要的原因是为了防止某些小白同学在代码里到处写System。gc（）的调用而干扰了程序的正常运行吧。有些应用程序本来可能正常跑一天也不会出一次FullGC，但就是因为有人在代码里调用了System。gc（）而不得不间歇性被暂停。有些时候这些调用是在某些库或框架里写的，改不了它们的代码但又不想被这些调用干扰也会用这参数。XX：DisableExplicitGC看起来这参数应该总是开着嘛。有啥坑呢？下述三个条件同时满足时会发生的应用本身在GC堆内的对象行为良好，正常情况下很久都不发生FullGC。应用大量使用了NIO的directmemory，经常、反复的申请DirectByteBuffer。使用了XX：DisableExplicitGC。能观察到的现象是：java。lang。OutOfMemoryError：Directbuffermemoryatjava。nio。Bits。reserveMemory（Bits。java：633）atjava。nio。DirectByteBuffer。init（DirectByteBuffer。java：98）atjava。nio。ByteBuffer。allocateDirect（ByteBuffer。java：288）复制代码用一个案例来分析这现象：importjava。nio。；publicclassDisableExplicitGCDemo｛publicstaticvoidmain（String〔〕args）｛for（inti0；i100000；i）｛ByteBuffer。allocateDirect（128）；｝System。out。println（Done）；｝｝复制代码
　　然后编译、运行。javaversionjavaversion1。6。025Java（TM）SERuntimeEnvironment（build1。6。025b06）JavaHotSpot（TM）64BitServerVM（build20。0b11，mixedmode）javacDisableExplicitGCDemo。javajavaXX：MaxDirectMemorySize10mXX：PrintGCXX：DisableExplicitGCDisableExplicitGCDemoExceptioninthreadmainjava。lang。OutOfMemoryError：Directbuffermemoryatjava。nio。Bits。reserveMemory（Bits。java：633）atjava。nio。DirectByteBuffer。init（DirectByteBuffer。java：98）atjava。nio。ByteBuffer。allocateDirect（ByteBuffer。java：288）atDisableExplicitGCDemo。main（DisableExplicitGCDemo。java：6）javaXX：MaxDirectMemorySize10mXX：PrintGCDisableExplicitGCDemo〔GC10996K10480K（120704K），0。0433980secs〕〔FullGC10480K10415K（120704K），0。0359420secs〕Done复制代码可以看到，同样的程序，不带XX：DisableExplicitGC时能正常完成运行，而带上这个参数后却出现了OOM。XX：MaxDirectMemorySize10m限制了DirectByteBuffer能分配的空间的限额，以便问题更容易展现出来。不用这个参数就得多跑一会儿了。循环不断申请DirectByteBuffer但并没有引用，所以这些DirectByteBuffer应该刚创建出来就已经满足被GC的条件，等下次GC运行的时候就应该可以被回收。实际上却没这么简单。DirectByteBuffer是种典型的冰山对象，也就是说它的Java对象虽然很小很无辜，但它背后却会关联着一定量的nativememory资源，而这些资源并不在GC的控制之下，需要自己注意控制好。
　　对JVM如何使用nativememory不熟悉的同学可以研究一下这篇演讲，WhereDoesAlltheNativeMemoryGo。【盲点问题】DirectByteBuffer的回收问题
　　OracleSunJDK的实现里，DirectByteBuffer有几处值得注意的地方。DirectByteBuffer没有finalizer，它的nativememory的清理工作是通过sun。misc。Cleaner自动完成的。sun。misc。Cleaner是一种基于PhantomReference的清理工具，比普通的finalizer轻量些。
　　Acleanertracksareferentobjectandencapsulatesathunkofarbitrarycleanupcode。SometimeaftertheGCdetectsthatacleanersreferenthasbecomephantomreachable，thereferencehandlerthreadwillrunthecleaner。源码注释Generalpurposephantomreferencebasedcleaners。pCleanersarealightweightandmorerobustalternativetofinalization。TheyarelightweightbecausetheyarenotcreatedbytheVMandthusdonotrequireaJNIupcalltobecreated，andbecausetheircleanupcodeisinvokeddirectlybythereferencehandlerthreadratherthanbythefinalizerthread。Theyaremorerobustbecausetheyusephantomreferences，theweakesttypeofreferenceobject，therebyavoidingthenastyorderingproblemsinherenttofinalization。pAcleanertracksareferentobjectandencapsulatesathunkofarbitrarycleanupcode。SometimeaftertheGCdetectsthatacleanersreferenthasbecomephantomreachable，thereferencehandlerthreadwillrunthecleaner。Cleanersmayalsobeinvokeddirectly；theyarethreadsafeandensurethattheyruntheirthunksatmostonce。pCleanersarenotareplacementforfinalization。Theyshouldbeusedonlywhenthecleanupcodeisextremelysimpleandstraightforward。Nontrivialcleanersareinadvisablesincetheyriskblockingthereferencehandlerthreadanddelayingfurthercleanupandfinalization。authorMarkReinholdversionI，E复制代码
　　OracleSunJDK中的HotSpotVM只会在OldGenGC（FullGCMajorGC或者ConcurrentGC都算）的时候才会对OldGen中的对象做ReferenceProcessing，而在YoungGCMinorGC时只会对YoungGen里的对象做Referenceprocessing。FullGC会对OldGen做Referenceprocessing，进而能触发Cleaner对已死的DirectByteBuffer对象做清理工作。如果很长一段时间里没做过GC或者只做了YoungGC的话则不会在OldGen触发Cleaner的工作，那么就可能让本来已经死了的、但已经晋升到OldGen的DirectByteBuffer关联的NativeMemory得不到及时释放。为DirectByteBuffer分配空间过程中会显式调用System。gc（），以通过FullGC来强迫已经无用的DirectByteBuffer对象释放掉它们关联的nativememory。Thesemethodsshouldbecalledwheneverdirectmemoryisallocatedorfreed。Theyallowtheusertocontroltheamountofdirectmemorywhichaprocessmayaccess。Allsizesarespecifiedinbytes。staticvoidreserveMemory（longsize）｛synchronized（Bits。class）｛if（！memoryLimitSetVM。isBooted（））｛maxMemoryVM。maxDirectMemory（）；memoryLimitSettrue；｝if（sizemaxMemoryreservedMemory）｛reservedMemorysize；return；｝｝System。gc（）；try｛Thread。sleep（100）；｝catch（InterruptedExceptionx）｛RestoreinterruptstatusThread。currentThread（）。interrupt（）；｝synchronized（Bits。class）｛if（reservedMemorysizemaxMemory）thrownewOutOfMemoryError（Directbuffermemory）；reservedMemorysize；｝｝复制代码总结分析
　　这几个实现特征使得OracleSunJDK依赖于System。gc（）触发GC来保证DirectByteMemory的清理工作能及时完成。
　　如果打开了XX：DisableExplicitGC，清理工作就可能得不到及时完成，于是就有机会见到directmemory的OOM，也就是上面的例子演示的情况。我们这边在实际生产环境中确实遇到过这样的问题。
　　如果你在使用OracleSunJDK，应用里有任何地方用了directmemory，那么使用XX：DisableExplicitGC要小心。如果用了该参数而且遇到directmemory的OOM，可以尝试去掉该参数看是否能避开这种OOM。如果担心System。gc（）调用造成FullGC频繁，可以尝试下面提到XX：ExplicitGCInvokesConcurrent参数
　　原文链接：https：juejin。cnpost7177565339801092152