延迟指服务器处理一个请求所花费的时间，单位一般是ms、s。
本文主要讲降低延迟可以做的服务器端JVM优化。
JVM延迟优化
新生代
新生代大小决定了应用平均延迟
如果平均Minor GC持续时间大于应用程序平均延迟性要求，可以适当减小新生代空间大小；
如果Minor GC频率大于应用程序平均延迟性要求，可以适当增大新生代空间；
老年代
老年代大小决定了应用最差延迟
FullGC频率大于应用程序最大FullGC频率要求，可以适当增大老年代空间大小；
FullGC持续时间大于应用程序最差延迟性要求，可以使用CMS垃圾收集器；
CMS收集器调优
CMS主要特性
CMS为老年代收集器，收集线程能与应用程序线程实现最大的并行度，降低了延迟。
CMS并不进行压缩，所以老年代使用空闲列表分配内存，在一定程度上增加了新生代晋升老年代时，耗费的时间。
但一旦老年代溢出就会触发Stop-The-World压缩式垃圾收集。
所以，CMS的优化大概有下面几点：
1. 避免用尽老年代空间；
2. 解决老年代碎片化问题，解决方法包括压缩、MinorGC回收原则；
3. 降低初始标记阶段和重新标记阶段占用的时间，因为这两个阶段应用程序线程会被阻塞；
Survivor空间调优
调整Survivor空间，是为了让其有足够空间容纳存活对象足够长的时间，直到几个周期后对象老化，解决上面的第一、二条问题。
Survivor空间的大小可以通过下面这个参数调整：
-XX:SurvivorRatio=<ratio>
<ratio>必须大于0，-XX:SurvivorRatio=<ratio>表示单个Survivor和Eden的比率。
survivor空间大小 = –Xmn/(-XX:SurvivorRatio=<ratio> + 2)
监控晋升阈值
-XX:MaxTenuringThreshold=n //设置最大晋升阈值
-XX:+PrintTenuringDistribution //打印晋升的分布或对象年龄分布到GC日志
如下面这个晋升日志：
Desired survivor size 1114112 bytes, new threshold 1 (max 6) - age 1: 2213864 bytes, 2213864 total
Desired survivor size 1114112 bytes是Survivor空间大小 * 目标存活率（可以设定，默认50%）
new threshold 1 JVM内部计算出的晋升阈值 (max 6)设置的晋升阈值
age 1（对象年龄代） 2213864 bytes（这个年龄对象总大小）, 2213864 total（所有年龄对象总大小）
Survivor目标存活率:指Minor GC后Survivor空间占用比率，如果太大，下次Minor GC后存活的对象就有可能放不下
从这个日志可以看出，存活对象2213864bytes大于期望Survivor大小为1124112bytes，所以对象年龄为1时，就提升到了老年代。
解决这个问题的方法就是增大Survivor空间，存活对象大小 / 目标存活率 = Survivor空间大小，本例中大概4.5M，所以修改JVM参数为：
-Xmx512m -Xms512m -Xmn50m -XX:SurvivorRatio=5
调整后的晋升日志大概如下，这个已不是上面那个应用了，所以Survivor空间不一样，能说明问题就行：
Desired survivor size 87359488 bytes, new threshold 15 (max 15) - age 1: 20701528 bytes, 20701528 total - age 2: 4924656 bytes, 25626184 total - age 3: 3261000 bytes, 28887184 total - age 4: 7941120 bytes, 36828304 total
调整Survivor空间的一个重要原则：
调整Survivor空间时，应保持Eden空间不变，否则会导致Minor GC频率变小。
初始化CMS收集周期
CMS中发生的Stop-The-World压缩式垃圾收集可以在GC日志中查找并发模式失效（concurrent mode failure）定位。
如果有这个问题，就需要调整CMS收集周期。
-XX:CMSInitiatingOccupancyFraction=<percent> //设置CMS垃圾收集周期在老年代空间占用达到多少是启动
-XX:+UseCMSInitiatingOccupancyOnly //告知JVM总是使用 CMSInitiatingOccupancyFraction比率启动CMS，否则只是在CMS第一次启动时
原则：CMSInitiatingOccupancyFraction设置的比率至少是老年代活跃数据的1.5倍
如果老年代空间消耗的比较慢，可以稍晚启动CMS，即将CMSInitiatingOccupancyFraction设定的更大；
如果老年代空间消耗的很快，可以将CMSInitiatingOccupancyFraction设定的更小，但不能低于活跃数据占用的比率；
降低CMS重新标记阶段占用时间
-XX:ParallelGCThreads //控制重新标记的线程数，建议将CMS的收集线程数设置的小于默认值，否则大量GC线程会影响应用性能
-XX:+CMSScavengeBeforeRemark //在CMS进入重新标记阶段先进行一次Minor GC，可以减少引用老年代的新生代对象数量，降低重新标记阶段的工作量
-XX:+ParallelRefProcEnabled //使用多线程处理引用，不过在JDK6u25和6u26上有BUG