记录一下线上机器的JVM参数配置：
CATALINA_OPTS="$CATALINA_OPTS -server -Djava.awt.headless=true
6.7补充：之前贴的是web机器的JVM参数配置，看了service的参数配置，稍稍有点不同
web配了新生代1G，老年代1.5G，service配了新生代1.5G，老年代1G【为什么会产生这种不同？】
-Xms2560m [JVM初始分配的堆内存 2.5G]
-Xmx2560m [JVM最大可用堆内存 2.5G]
-Xss256k [每个线程的堆栈大小]
-XX:PermSize=128m [永久代大小]
-XX:MaxPermSize=384m [永久代最大值]
-XX:NewSize=1024m [新生代初始内存大小]
-XX:MaxNewSize=1024m [新生代最大内存大小]
-XX:SurvivorRatio=22 [新生代中eden与survivor的容量比值，默认为8，线上竟然设置为这么大!!]
-XX:+UseParNewGC [使用ParNew+Serial Old的组合回收器]
-XX:ParallelGCThreads=4 [GC时进行内存回收的线程数]
-XX:MaxTenuringThreshold=9 [老年代阈值，熬过9次young GC就进入老年代]
-XX:+UseConcMarkSweepGC [使用ParNew+CMS+SerialOld进行组合回收，当CMS失败时，SerialOld作为后备回收器]
-XX:+DisableExplicitGC [忽略System.gc()方法触发的垃圾回收，即在程序中，是无法通过System.gc()进行垃圾回收的]
-XX:+ScavengeBeforeFullGC [开启在full GC之前触发一次minor GC]
-XX:+CMSParallelRemarkEnabled [并行的进行remark标记，降低GC停顿时间]
-XX:+UseCMSCompactAtFullCollection [开启在CMS回收老年代之后进行一次内存碎片整理]
-XX:CMSFullGCsBeforeCompaction=9 [在9次CMS老年代回收之后，进行一次内存碎片整理]
-XX:+UseCMSInitiatingOccupancyOnly [强迫JVM仅仅使用CMSInitiatingOccupancyFraction的值作为触发CMS的因素，否则JVM可能会使用其他指标启动CMS]
-XX:CMSInitiatingOccupancyFraction=60 [当老年代使用比率达到这个值时，就出发CMS]
-XX:SoftRefLRUPolicyMSPerMB=0 [如此设置，会在每次GC时，均将软引用回收掉，默认是在内存不够时，才试图去回收软引用]
-XX:-ReduceInitialCardMarks
-XX:+CMSPermGenSweepingEnabled [启用CMS清理永久代]
-XX:+CMSClassUnloadingEnabled [启用CMS清理永久代的功能，CMS卸载无用的classes]
-XX:CMSInitiatingPermOccupancyFraction=70 [永久代使用比率达到多少时，会回收永久代]
-XX:+ExplicitGCInvokesConcurrent -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dj
ava.util.logging.config.file="%CATALINA_HOME%conflogging.properties"
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintHeapAtGC
-Xloggc:/data/applogs/heap_trace.txt
-XX:-HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/applogs/HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow