記錄一下線上機器的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%\conf\logging.properties"
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintHeapAtGC
-Xloggc:/data/applogs/heap_trace.txt
-XX:-HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/applogs/HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
原文地址：https://www.cnblogs.com/dosmile/p/6926404.html