TOMCAT 高併發配置

JVM配置以下：

JAVA_OPTS="$JAVA_OPTS -server -Xmn1024M -Xms4096M -Xmx4096M  -Djava.net.preferIPv4Stack=true -Djava.awt.headless=true -Dorg.apache.catalina.connector.RECYCLE_FACADES=false -XX:PermSize=512M -XX:MaxPermSize=512M  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly  -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=81 -XX:SoftRefLRUPolicyMSPerMB=0 -Xloggc:gc.log -XX:+PrintGCDetails -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=29010 -Dcom.sun.management.jmxremote.ssl=false"

 以上配置參數說明：

-XX:+UseCMSInitiatingOccupancyOnly 僅僅使用手動定義初始化定義開始CMS收集
-XX:+UseConcMarkSweepGC 使用CMS內存收集
-XX:+UseParNewGC 容許多線程收集新生代
-XX:+CMSParallelRemarkEnabled 下降標記停頓
-XX+UseCMSCompactAtFullCollection 在FULL GC的時候， 壓縮內存， CMS是不會移動內存的， 所以， 這個很是容易產生碎片， 致使內存不夠用， 所以， 內存的壓縮這個時候就會被啓用。 增長這個參數是個好習慣
-XX:CMSFullGCsBeforeCompaction：因爲併發收集器不對內存空間進行壓縮、整理，因此運行一段時間之後會產生「碎片」，使得運行效率下降。此值設置運行多少次GC之後對內存空間進行壓縮、整理。
-XX:+UseFastAccessorMethods 原始類型的快速優化
XX:SurvivorRatio=65536決定了新生代中eden與survivor的空間比例是65536：1，這裏設置爲65536的目的是不使用survivor的空間
-XX:MaxTenuringThreshold=0：設置垃圾最大年齡。若是設置爲0的話，則年輕代對象不通過Survivor區，直接進入年老代。對於年老代比較多的應用，能夠提升效率。若是將此值設置爲一個較大值，則年輕代對象會在Survivor區進行屢次複製，這樣能夠增長對象再年輕代的存活時間，增長在年輕代即被回收的概論。
-XX:CMSInitiatingOccupancyFraction=70 CMS堆上， 使用70％後開始CMS收集。
-XX:SoftRefLRUPolicyMSPerMB=0是測量一個軟引用存活的時間指標，用於使heap中的可用空間達到規定數量。默認值爲每兆1000毫秒。這可理解爲，對於heap中每兆大小的可用空間而言，一個軟引用有1秒的存活時間（在最後一個強引用的對象被回收後）。這個1秒的估算已很是接近真實狀態了

 

因爲Tocmat6存在一個BUG，以上的配置會引發JVM產生大量的FULL GC，在Tomcat一啓動的時候就會FULL GC。解決的辦法是在server.xml中增長以下項便可解決

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"gcDaemonProtection="false" />