Source的内存运行情况
Source作为公司内部代码托管工具，用户通过git的push、pull、clone等操作以及在web端查看代码进行代码对比的操作都将在短时间内产生大量的对象，并且这些对象的存活时间也不会很长。
调优之前的jvm运行情况分析
调优之前jvm使用的垃圾回收策略是新生代老年代均使用parallel Scanvenge，也就是默认策略，堆大小为2G。出现的问题是：
- 永久代初始内存64M设置过小，运行过程中永久代内存可达到90M
- Minor gc频繁，说明eden区内存不足
- Minor gc时间过长，平均一次需要80ms
- 垃圾收集的并行线程数43个，服务器是8核，线程数偏多
- Full gc频繁，平均是半个小时一次，一次full gc耗时800ms左右
第一次调优
参数设置：
-XX:+PrintGCDetails
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:ParallelGCThreads=20
-Xmn900m
-XX:SurvivorRatio=1
-XX:PermSize=128m
-Xmx2048m
-Xms2048m
第一次调优新生代收集器改用parnew，parnew收集器不会动态的去调整新生代大小去达到吞吐率要求，但更容易控制。垃圾收集线程数改为20，减少线程之间的切换开销，提升minor gc速度，设置survivor:eden=1:1，永久代初始大小设置为128m，老年代收集器默认是单线程的serial old。同时禁止代码显式GC。
得到的结果是full频率下降很多，这里的原因在于survivor区增大，因为survivor区内存不足而直接进入老年代的情况减少，minor gc频率有所提高，minor gc耗费的平均时间变为此前的一半，频率更高的原因可能在于eden区300m大小偏小，而耗费时间的减少一方面是eden区较小，另一方面则是垃圾收集线程的切换开销减小了。
第二次调优
参数设置：
-XX:+PrintGCDetails
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:ParallelGCThreads=20
-Xmn900m
-XX:SurvivorRatio=2
-XX:PermSize=128m
-XX:MaxTenuringThreshold=10
-Xmx2048m
-Xms2048m
第二次调优修改eden区大小为450m，力图降低minor gc频率，同时设置经过多少次minor gc过后，存活的对象进入老年代，默认值15，调整过后full gc的频率有所提高，minor gc频率仍然偏高，说明eden区还是太小，此外过小的survivor区大小也影响了full gc的频率。
第三次调优
参数设置：
-XX:+PrintGCDetails
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:ParallelGCThreads=8
-Xmn1000m
-XX:SurvivorRatio=2
-XX:PermSize=128m
-XX:MaxTenuringThreshold=10
-Xmx2048m
-Xms2048m
第三次增大年轻代大小到1000m，减少gc时的并发线程数至CPU核数相同，结果是minor gc频率降低，并且每次minor gc时间骤降到16ms左右，十个小时内进行过一次full gc，耗时接近1s。
继续观察出现的问题，由于短暂的出现大量的大对象，造成短时间内大量的minor gc并且由此引发了数次full gc，判断是否是一次“良好”的minor gc可以从本次gc时新生代大小判断，如果大小接近最大值说明引发gc的对象不大，如果当前新生代大小很小，说明出现了大对象，并且该对象很有可能将会由于survivor不够大而进入老年代。
结合三次调优可以发现source jvm的内存空间还不太够。
第四次调优
参数设置：
-XX:+PrintGCDateStamps
-XX:TargetSurvivorRatio=100
-XX:+PrintTenuringDistribution //minor gc后打印分代信息
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled //启用CMS并发标记
-XX:+UseCMSCompactAtFullCollection //启用碎片整理
-XX:CMSFullGCsBeforeCompaction=0 //设置多少次FULL GC过后执行一次碎片整理
-XX:+UseCMSInitiatingOccupancyOnly //启用CMS占比阈值
-XX:CMSInitiatingOccupancyFraction=80 //设置阈值百分比，内存超过该百分比将执行CMS GC
-XX:SurvivorRatio=2
-XX:+PrintGCDetails
-XX:+UseParNewGC
-XX:ParallelGCThreads=8
-Xmn1500m
-XX:+DisableExplicitGC
-XX:PermSize=128m
-XX:MaxTenuringThreshold=10
-Xmx4096m
-Xms4096m
这一次调优是经过了几个参数调整的最终成型结果，有如下一些比较重要的改变
- 老年代收集器使用CMS，CMS分为多个阶段，其中耗时的阶段都不是stop the world，因此可以显著提高系统响应性能，缺点是采用标记清除算法，因此存在内存碎片问题以及并发模式下的失败问题。内存碎片问题可以通过设置full gc后执行内存整理来解决，这里必须要注意的是CMS GC不是FULL GC，FULL GC停顿的时间会很长，理想情况下如果FULL GC频率超过一天一次，可以考虑在外部通过脚本在凌晨执行一次定时FULL GC以达到清理碎片的效果。并发模式下的失败问题一个显著的原因是垃圾收集的速度已经跟不上对象分配的速度， source针对大代码库的服务器会偶发这个失败问题。
- -XX:TargetSurvivorRatio=100强调下这个参数，该参数表示survivor区的使用率，如果survivor去的对象大小超过了使用率则会以survivor区age的最大值作为晋升老年代的参考，最终取该参考值以及设置的最大晋升代数的较小值，hot spot默认是50，这里改成100，意思就是对象必须待满足够的代数才能进入老年代，结合-XX:MaxTenuringThreshold=10可知对象需要待满10代。为什么选择10代，这是通过设置-XX:+PrintTenuringDistribution观察存活对象晋升的情况作出的决定（这里并没有经过绝对准确的调研，要想准确的得到更合理的分代门限值可以做一个晋升的统计），实际当中发现大部分对象无法存活超过10代。
- CMS GC启动阈值-XX:CMSInitiatingOccupancyFraction=80，这个值非常重要，实际情况下可以根据jvm具体情形设置。这里设置为80表示一旦老年代内存空间超过百分之八十将进行CMS GC。预留的空间可以保证在CMS GC的并发阶段新进入老年代的对象可以找到空间进行存储，一旦找不到足够的空间就将产生并发模式错误并触发FULL GC。
调优之后新生代GC频率下降，时间有所提升，变为20+ms（完全可以接受），老年代GC频率骤降，平均一天一次（非大代码库），高峰期可能一天会出现2-3次，XX:TargetSurvivorRatio=100大大地降低了新生代对象进入老年代的可能性，因为大部分对象存活时间都无法超过10代。
目前source非大代码库对应的服务器一直使用该配置，运行情况良好，并且比起调优之前性能好了很多。
