JVM記憶體調優

JVM 幾個重要的參數

Linux下修改JVM記憶體大小: linux下tomcat的參數JAVA_OPTS必須設在catalina.sh中cygwin=false前

要添加在tomcat 的bin 下catalina.sh 裡，位置cygwin=false前 。注意linux下設定JAVA_OPTS需要把引号帶上,紅色的為新添加的.

# OS specific support.  $var _must_ be set to either true or false.

JAVA_OPTS="$JAVA_OPTS -Xms1200m -Xmx1200m -Xss1024K -XX:PermSize=128m -XX:MaxPermSize=256m"

cygwin=false

Linux:  指令來修改參數

export JAVA_OPTS="-Xms256m -Xmx512m"
           

Windows:  set JAVA_OPTS="-Xms256m -Xmx512m"

執行啟動設定Jvm參數的操作。

1)
$ java -jar -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xms1024m -Xmx1024m -Xmn256m -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC demoproject-1.0.0.jar
2)
java -server -Xms32m -Xmx32m -jar mybatis05-0.0.1-SNAPSHOT.jar
           

1   項目先用maven 打包，然後直接用java -service指令帶參數，設定JVM啟動記憶體大小

2   容器的話，就配置在啟動腳本裡runshell.sh 裡可以一起啟動，

3  如果在Tomcat裡配置的話，catalina.sh 裡配置 JAVA_OPTS  JVM優化參數

<本文提供的設定僅僅是在高壓力，多CPU，高記憶體環境下設定>

最近對JVM的參數重新看了下，把應用的JVM參數調整了下。

1 幾個重要的參數

-server -Xmx3g -Xms3g -XX:MaxPermSize=128m

-XX:NewRatio=1 eden/old 的比例

-XX:SurvivorRatio=8 s/e的比例

-XX:+UseParallelGC -XX:ParallelGCThreads=8

-XX:+UseParallelOldGC 這個是JAVA 6出現的參數選項

-XX:LargePageSizeInBytes=128m 記憶體頁的大小，不可設定過大，會影響Perm的大小。

-XX:+UseFastAccessorMethods 原始類型的快速優化

-XX:+DisableExplicitGC 關閉System.gc()

-XX:MaxPermSize=128m:設定持久代大小

另外 -Xss 是線程棧的大小，這個參數需要嚴格的測試，一般小的應用，如果棧不是很深，應該是128k夠用的，不過，我們的應用調用深度比較大，還需要做詳細的測試。這個選項對性能的影響比較大。建議使用256K的大小.

-server -Xmx3g -Xms3g -Xmn=1g -XX:MaxPermSize=128m -Xss256k -XX:MaxTenuringThreshold=10 -XX:+DisableExplicitGC -XX:+UseParallelGC -XX:+UseParallelOld GC -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+AggressiveOpts -XX:+UseBiasedLocking

-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 列印參數

-Xms值可以設定與-Xmx相同，以避免每次垃圾回收完成後JVM重新配置設定記憶體

-Xmn350M -> -Xmn800M   年輕代，一般情況下是預設的，這裡設定了一個範圍，整個JVM記憶體大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m，是以增大年輕代後，将會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置為整個堆的3/8。 

2 關于CMS的設定:

使用CMS的前提條件是你有比較的長生命對象，比如有200M以上的OLD堆占用。那麼這個威力非常猛，可以極大的提高的FGC的收集能力。如果你的OLD占用非常的少，别用了，絕對降低你性能，因為CMS收集有2個STOP WORLD的行為。 OLD少的清情況，根據我的測試，使用并行收集參數會比較好

-XX:+UseConcMarkSweepGC 使用CMS記憶體收集

-XX:+AggressiveHeap 特别說明下：(對于做java cache應用有幫助)

· 試圖是使用大量的實體記憶體

· 長時間大記憶體使用的優化，能檢查計算資源（記憶體，處理器數量）

· 至少需要256MB記憶體

· 大量的CPU／記憶體，（在1.4.1在4CPU的機器上已經顯示有提升）

-XX:+UseParNewGC 允許多線程收集新生代 -XX:+CMSParallelRemarkEnabled 降低标記停頓

-XX+UseCMSCompactAtFullCollection 在FULL GC的時候，壓縮記憶體， CMS是不會移動記憶體的，是以，這個非常容易産生碎片，導緻記憶體不夠用，是以，記憶體的壓縮這個時候就會被啟用。增加這個參數是個好習慣。

壓力測試下合适結果：

-server -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods

-XX:+UseCMSInitiatingOccupancyOnly 僅僅使用手動定義初始化定義開始CMS收集

-XX:CMSInitiatingOccupancyFraction=70 CMS堆上，使用70％後開始CMS收集。

使用CMS的好處是用盡量少的新生代、，我的經驗值是128M－256M，然後老生代利用CMS并行收集，這樣能保證系統低延遲的吞吐效率。實際上cms的收集停頓時間非常的短，2G的記憶體，大約20－80ms的應用程式停頓時間。

GC參數配置：

JAVA_OPTS=" -server -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:MaxTenuringThreshold=31 -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 "

實際上我們可以看到并行young gc執行時間是： 324.198s／15211＝20ms, cms的執行時間是 1.668／66＝25ms. 當然嚴格來說，這麼算是不對的，世界停頓的時間要比這是資料稍微大5-10ms. 對我們來說如果不輸出日志，對我們是有參考意義的。

32位系統下，設定成2G，非常危險，除非你确定你的應用占用的native記憶體很少，不然可能導緻jvm直接crash。

-XX:+AggressiveOpts 加快編譯

-XX:+UseBiasedLocking 鎖機制的性能改善。

elipse運作環境配置JVM參數調優

參考 資料   https://www.cnblogs.com/likehua/p/3369823.html