jvm性能调优笔记

 -Xms2500m -Xmx2500m -Xmn1536m -XX:PermSize=256m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -server -XX:+DisableExplicitGC -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCDetails

参数说明：

-XX:CMSFullGCsBeforeCompaction=1  说明：CMS fullGC时每隔一次进行内存压缩整理；

-XX:+PrintTenuringDistribution 说明：gc日志输出具体年龄分布

-XX:+PrintHeapAtGC  说明:输出gc前后堆占用情况日志 

-Xmn配置的为eden+from+to区的大小，默认一个survior占yong区的1/8
-XX:MaxTenuringThreshold 对象被放入old区之前，from/to之间转换的次数

-XX:SurvivorRatio 设置from+to区与整个Young区的比率，若为6，表示(from+to):eden = 2:6,(from+to):Young = 2:8

当对象的大小超过这个值时，将直接在年老代分配。参数-XX:PetenureSizeThreshold 只对串行收集器和年轻代并行收集器有效，并行回收收集器不识别这个参数。

 ----------------------------------------------------------------------------------------

jstat -gcutil <pid>   说明：统计gc信息 

S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 49.49 76.56 21.45 25.98 551 19.685 0 0.000 19.685

S0  年轻代中第一个survivor（幸存区）已使用的占当前容量百分比

S1  年轻代中第二个survivor（幸存区）已使用的占当前容量百分比

E    年轻代中Eden（伊甸园）已使用的占当前容量百分比

O   old代已使用的占当前容量百分比

P    perm代已使用的占当前容量百分比

YGC  从应用程序启动到采样时年轻代中gc次数

YGCT  从应用程序启动到采样时年轻代中gc所用时间(s)

FGC  从应用程序启动到采样时old代(全gc)gc次数

FGCT 从应用程序启动到采样时old代(全gc)gc所用时间(s)

GCT  从应用程序启动到采样时gc用的总时间(s)

--------------------------------------------------------------------------

Major GC和Full GC的区别是什么？

作者：RednaxelaFX
链接：https://www.zhihu.com/question/41922036/answer/93079526
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

针对HotSpot VM的实现，它里面的GC其实准确分类只有两大种：

• Partial GC：并不收集整个GC堆的模式
• Young GC：只收集young gen的GC
• Old GC：只收集old gen的GC。只有CMS的concurrent collection是这个模式
• Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式
• Full GC：收集整个堆，包括young gen、old gen、perm gen（如果存在的话）等所有部分的模式。

Major GC通常是跟full GC是等价的，收集整个GC堆。但因为HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，当有人说“major GC”的时候一定要问清楚他想要指的是上面的full GC还是old GC。

最简单的分代式GC策略，按HotSpot VM的serial GC的实现来看，触发条件是：

• young GC：当young gen中的eden区分配满的时候触发。注意young GC中有部分存活对象会晋升到old gen，所以young GC后old gen的占用量通常会有所升高。
• full GC：当准备要触发一次young GC时，如果发现统计数据说之前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC（因为HotSpot VM的GC里，除了CMS的concurrent collection之外，其它能收集old gen的GC都会同时收集整个GC堆，包括young gen，所以不需要事先触发一次单独的young GC）；或者，如果有perm gen的话，要在perm gen分配空间但已经没有足够空间时，也要触发一次full GC；或者System.gc()、heap dump带GC，默认也是触发full GC。

HotSpot VM里其它非并发GC的触发条件复杂一些，不过大致的原理与上面说的其实一样。
当然也总有例外。Parallel Scavenge（-XX:+UseParallelGC）框架下，默认是在要触发full GC前先执行一次young GC，并且两次GC之间能让应用程序稍微运行一小下，以期降低full GC的暂停时间（因为young GC会尽量清理了young gen的死对象，减少了full GC的工作量）。控制这个行为的VM参数是-XX:+ScavengeBeforeFullGC。这是HotSpot VM里的奇葩嗯。可跳传送门围观：JVM full GC的奇怪现象，求解惑？ - RednaxelaFX 的回答

并发GC的触发条件就不太一样。以CMS GC为例，它主要是定时去检查old gen的使用量，当使用量超过了触发比例就会启动一次CMS GC，对old gen做并发收集。

 

---------------------------------------------------------------

1. Full GC == Major GC指的是对老年代/永久代的stop the world的GC

2. Full GC的次数 = 老年代GC时 stop the world的次数

3. Full GC的时间 = 老年代GC时 stop the world的总时间

4. CMS 不等于Full GC，我们可以看到CMS分为多个阶段，只有stop the world的阶段被计算到了Full GC的次数和时间，而和业务线程并发的GC的次数和时间则不被认为是Full GC

5. Full GC本身不会先进行Minor GC，我们可以配置，让Full GC之前先进行一次Minor GC，因为老年代很多对象都会引用到新生代的对象，先进行一次Minor GC可以提高老年代GC的速度。比如老年代使用CMS时，设置CMSScavengeBeforeRemark优化，让CMS remark之前先进行一次Minor GC。

http://blog.csdn.net/iter_zc/article/details/41825395

-----------------------------------------------------------------

都知道jvm运行java代码是解释器模式，随着系统的运行会自动优化，编译热点代码为本地代码，提升运行速度。这种是jvm默认的混合模式 -Xmixed.

-Xint 参数强制jvm 启动解释模式，不编译本地代码
-Xcomp 参数强制jvm启动编译模式

详细：http://ifeve.com/useful-jvm-flags-part-1-jvm-types-and-compiler-modes-2/

------------------------------

本篇文章基于Java 6（update 21oder 21之后）版本， HotSpot JVM 提供给了两个新的参数，在JVM启动后，在命令行中可以输出所有XX参数和值。

-XX:+PrintFlagsFinal and -XX:+PrintFlagsInitial

详细：http://ifeve.com/useful-jvm-flags-part-3-printing-all-xx-flags-and-their-values/

ExplicitGCInvokesConcurrent

ExplicitGCInvokesConcurrent这的使用前提是打开System.gc 开关，并且是用的是CMS GC算法，这样这个参数才有用。

手动System.gc默认是做一次FullGc操作，ExplicitGCInvokesConcurrent 打开后，手动的System.gc将只做一次并发gc周期（CMS中一个周期），有效缩短时间。

ExplicitGCInvokesConcurrent一般与NIO配合使用，NIO使用了大量的非堆内存，young gc清理不掉，需要fullgc进行清理。

一般NIO框架中，在申请空间前会使用System.gc进行手动清理内存，防止oom.这时打开ExplicitGCInvokesConcurrent就是很有必要的

http://lovestblog.cn/blog/2015/05/07/system-gc/

UseAdaptiveSizePolicy  自动选择年轻代区大小和相应的Survivor区比例

UseCMSInitiatingOccupancyOnly   指定HotSpot VM总是使用-XX:CMSInitiatingOccupancyFraction的值作为old的空间使用率限制来启动CMS垃圾回收。如果没有使用-XX:+UseCMSInitiatingOccupancyOnly，那么HotSpot VM只是利用这个值来启动第一次CMS垃圾回收，后面都是使用HotSpot VM自动计算出来的值。

CMSClassUnloadingEnabled cmsGC时对永久带进行回收

-XX:+CMSScavengeBeforeRemark这个参数还蛮重要的，它的意思是在执行CMS remark之前进行一次youngGC，这样能有效降低remark的时间，之前我没有加这个参数，remark时间最大能达到3s，加上这个参数之后remark时间减少到1s之内。