前言
在生产环境中，你是否遇到过这样的问题？
1）系统运行一段时间后old区空间正逐渐减少？
2）遇到秒杀促销活动等场景old区存储突然暴增，导致JVM Full GC。fgc time持续过长导致cpu 100%？
3）jvm eden区分配的内存实际并没有按照配置的指定？survivor区对象晋升到old区并没有达到默认的15次？
4）如何避免Full GC，JVM产生FGC后如何解决？
……
接下来的内容，我将从实际场景出发，分别使用三种垃圾收集器：ParallelGC,Concurrent Mark Sweep(cms),G1，进行参数调优，解决我们在生产中jvm遇到的各种问题。jvm调优会作为专题持续更新。
以下GC调优默认使用jdk1.8
JVM性能调优实战——Concurrent Mark Sweep
jdk1.8默认使用ParallelGC。新生代采用的是Parallel Scavenge，老年代Parallel Old。
并发垃圾收集器调优的内容一般为：
1）关闭jvm自动分配策略。
2）survivior空间调优。
通过这两点调整，使创建的对象按照设定的阈值执行。
-
关闭JVM自动分配策略
先来看默认情况下jvm内存空间的分配情况：
-server -Xms4G -Xmx4G -Xss512K -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/deploy_service_heap.log -verbose:gc -Xloggc:/deploy_service_gc.log
我们使用jdk1.8自带的jvisualvm工具监控查看运行情况，如图：
tips：对于并发类型的GC来说，jvm默认开启了内存自动适配策略参数是UseAdaptiveSizePolicy。使用-XX:-UseAdaptiveSizePolicy来关闭jvm的自动适配策略。
-
survivior空间调优
通常的网文会说-XX:SurvivorRatio这个参数默认为8，意思是eden:s1:s2 = 8:1:1。这个比值到底要不要改，修改后效果就一定好吗？答案是否定的。举例说明：如果改成6(6:2:2)或者4(4:3:3)增加了survivor空间的同时缩减了eden区空间，这会导致eden区由于内存分配不够ygc的频次增加，每ygc一次，存活的对象就会进入survivor,但实际情况是survivor中的对象会很少，作者的应用程序qps200~500之间，持续时间为24小时，但survivor中的对象总量最大不超过70M，所以扩大survivor区空间是在浪费资源。
survivor区真正要调整的是TargetSurvivorRatio,MaxTenuringThreshold这两个参数。
TargetSurvivorRatio：表示目标survivor区存储率超过指定百分比时，会重新计算一次TenuringThreshold值。在生产中如果你遇到这种情况，说明需要调整TargetSurvivorRatio了。如图：
图中survivor区在每次ygc后都会重新计算一次threshold的值（默认最大为15），说明在survivor区中的对象并不都是经过15次以上的ygc才进入老年代。
tips：在并发类型的GC中，-XX:-UseAdaptiveSizePolicy保证新生代内存分配按照你指定的参数执行。-XX:TargetSurvivorRatio=80 -XX:MaxTenuringThreshold=15 让目标survivor使用空间达到指定的百分比才会重新计算threshold值。如此一来，survivor中大部分的对象会活到15岁以上才进入老年代。优点是：阻止新对象快速进入old区将其填满，导致old区空间使用率100%而触发full gc。
通过上述调整后，我们来看一下jvm运行的效果：
我们看到eden区实际内存分配为1.6G，survivor区为204.5M，并且survivor区内的对象全部都在第16次ygc后进入了old区，这才是我们想要的效果！
另外补充说明一下，ParallelGC优调当然远不止这些，比如还有一些协助参数：-XX:+PrintTenuringDistribution 这个在jvm启动后每次进行内存分配可以打印出详细的内存分配情况。
以上是作者通过实际生产监控发现的问题，并整理出一些容易被我们忽略的问题点。欢迎各位读者评论区留言进行经验分享和探讨。
