JVM調優之 -Xms -Xmx -Xmn -Xss

原博客地址：http://uule.iteye.com/

一、JVM內存模型及垃圾收集算法

1.根據Java虛擬機規範，JVM將內存劃分爲：

New（年輕代）
Tenured（年老代）
永久代（Perm）

其中New和Tenured屬於堆內存，堆內存會從JVM啓動參數（-Xmx:3G）指定的內存中分配，Perm不屬於堆內存，有虛擬機直接分配，但可以通過-XX:PermSize -XX:MaxPermSize 等參數調整其大小。

年輕代（New）：年輕代用來存放JVM剛分配的Java對象
年老代（Tenured)：年輕代中經過垃圾回收沒有回收掉的對象將被Copy到年老代
永久代（Perm）：永久代存放Class、Method元信息，其大小跟項目的規模、類、方法的量有關，一般設置爲128M就足夠，設置原則是預留30%的空間。

New又分爲幾個部分：

Eden：Eden用來存放JVM剛分配的對象
Survivor1
Survivro2：兩個Survivor空間一樣大，當Eden中的對象經過垃圾回收沒有被回收掉時，會在兩個Survivor之間來回Copy，當滿足某個條件，比如Copy次數，就會被Copy到Tenured。顯然，Survivor只是增加了對象在年輕代中的逗留時間，增加了被垃圾回收的可能性。

2.垃圾回收算法

垃圾回收算法可以分爲三類，都基於標記-清除（複製）算法：

Serial算法（單線程）
並行算法
併發算法

JVM會根據機器的硬件配置對每個內存代選擇適合的回收算法，比如，如果機器多於1個核，會對年輕代選擇並行算法，關於選擇細節請參考JVM調優文檔。

稍微解釋下的是，並行算法是用多線程進行垃圾回收，回收期間會暫停程序的執行，而併發算法，也是多線程回收，但期間不停止應用執行。所以，併發算法適用於交互性高的一些程序。經過觀察，併發算法會減少年輕代的大小，其實就是使用了一個大的年老代，這反過來跟並行算法相比吞吐量相對較低。

還有一個問題是，垃圾回收動作何時執行？

當年輕代內存滿時，會引發一次普通GC，該GC僅回收年輕代。需要強調的時，年輕代滿是指Eden代滿，Survivor滿不會引發GC
當年老代滿時會引發Full GC，Full GC將會同時回收年輕代、年老代
當永久代滿時也會引發Full GC，會導致Class、Method元信息的卸載

另一個問題是，何時會拋出OutOfMemoryException，並不是內存被耗空的時候才拋出

JVM98%的時間都花費在內存回收
每次回收的內存小於2%

滿足這兩個條件將觸發OutOfMemoryException，這將會留給系統一個微小的間隙以做一些Down之前的操作，比如手動打印Heap Dump。

二、內存泄漏及解決方法

1.系統崩潰前的一些現象：

每次垃圾回收的時間越來越長，由之前的10ms延長到50ms左右，FullGC的時間也有之前的0.5s延長到4、5s
FullGC的次數越來越多，最頻繁時隔不到1分鐘就進行一次FullGC
年老代的內存越來越大並且每次FullGC後年老代沒有內存被釋放

之後系統會無法響應新的請求，逐漸到達OutOfMemoryError的臨界值。

2.生成堆的dump文件

通過JMX的MBean生成當前的Heap信息，大小爲一個3G（整個堆的大小）的hprof文件，如果沒有啓動JMX可以通過Java的jmap命令來生成該文件。

3.分析dump文件

下面要考慮的是如何打開這個3G的堆信息文件，顯然一般的Window系統沒有這麼大的內存，必須藉助高配置的Linux。當然我們可以藉助X-Window把Linux上的圖形導入到Window。我們考慮用下面幾種工具打開該文件：

Visual VM
IBM HeapAnalyzer
JDK 自帶的Hprof工具

使用這些工具時爲了確保加載速度，建議設置最大內存爲6G。使用後發現，這些工具都無法直觀地觀察到內存泄漏，Visual VM雖能觀察到對象大小，但看不到調用堆棧；HeapAnalyzer雖然能看到調用堆棧，卻無法正確打開一個3G的文件。因此，我們又選用了Eclipse專門的靜態內存分析工具：Mat。

4.分析內存泄漏

通過Mat我們能清楚地看到，哪些對象被懷疑爲內存泄漏，哪些對象佔的空間最大及對象的調用關係。針對本案，在ThreadLocal中有很多的JbpmContext實例，經過調查是JBPM的Context沒有關閉所致。

另，通過Mat或JMX我們還可以分析線程狀態，可以觀察到線程被阻塞在哪個對象上，從而判斷系統的瓶頸。

5.迴歸問題

Q：爲什麼崩潰前垃圾回收的時間越來越長？

A:根據內存模型和垃圾回收算法，垃圾回收分兩部分：內存標記、清除（複製），標記部分只要內存大小固定時間是不變的，變的是複製部分，因爲每次垃圾回收都有一些回收不掉的內存，所以增加了複製量，導致時間延長。所以，垃圾回收的時間也可以作爲判斷內存泄漏的依據

Q：爲什麼Full GC的次數越來越多？

A：因此內存的積累，逐漸耗盡了年老代的內存，導致新對象分配沒有更多的空間，從而導致頻繁的垃圾回收

Q:爲什麼年老代佔用的內存越來越大？

A:因爲年輕代的內存無法被回收，越來越多地被Copy到年老代

三、性能調優

除了上述內存泄漏外，我們還發現CPU長期不足3%，系統吞吐量不夠，針對8core×16G、64bit的Linux服務器來說，是嚴重的資源浪費。

在CPU負載不足的同時，偶爾會有用戶反映請求的時間過長，我們意識到必須對程序及JVM進行調優。從以下幾個方面進行：

線程池：解決用戶響應時間長的問題
連接池
JVM啓動參數：調整各代的內存比例和垃圾回收算法，提高吞吐量
程序算法：改進程序邏輯算法提高性能

1.Java線程池（java.util.concurrent.ThreadPoolExecutor）

大多數JVM6上的應用採用的線程池都是JDK自帶的線程池，之所以把成熟的Java線程池進行羅嗦說明，是因爲該線程池的行爲與我們想象的有點出入。Java線程池有幾個重要的配置參數：

corePoolSize：核心線程數（最新線程數）
maximumPoolSize：最大線程數，超過這個數量的任務會被拒絕，用戶可以通過RejectedExecutionHandler接口自定義處理方式
keepAliveTime：線程保持活動的時間
workQueue：工作隊列，存放執行的任務

Java線程池需要傳入一個Queue參數（workQueue）用來存放執行的任務，而對Queue的不同選擇，線程池有完全不同的行爲：

SynchronousQueue： 一個無容量的等待隊列，一個線程的insert操作必須等待另一線程的remove操作，採用這個Queue線程池將會爲每個任務分配一個新線程
LinkedBlockingQueue ： 無界隊列，採用該Queue，線程池將忽略 maximumPoolSize參數，僅用corePoolSize的線程處理所有的任務，未處理的任務便在LinkedBlockingQueue中排隊
ArrayBlockingQueue：有界隊列，在有界隊列和 maximumPoolSize的作用下，程序將很難被調優：更大的Queue和小的maximumPoolSize將導致CPU的低負載；小的Queue和大的池，Queue就沒起動應有的作用。

其實我們的要求很簡單，希望線程池能跟連接池一樣，能設置最小線程數、最大線程數，當最小數<任務<最大數時，應該分配新的線程處理；當任務>最大數時，應該等待有空閒線程再處理該任務。

但線程池的設計思路是，任務應該放到Queue中，當Queue放不下時再考慮用新線程處理，如果Queue滿且無法派生新線程，就拒絕該任務。設計導致“先放等執行”、“放不下再執行”、“拒絕不等待”。所以，根據不同的Queue參數，要提高吞吐量不能一味地增大maximumPoolSize。

當然，要達到我們的目標，必須對線程池進行一定的封裝，幸運的是ThreadPoolExecutor中留了足夠的自定義接口以幫助我們達到目標。我們封裝的方式是：

以SynchronousQueue作爲參數，使maximumPoolSize發揮作用，以防止線程被無限制的分配，同時可以通過提高maximumPoolSize來提高系統吞吐量
自定義一個RejectedExecutionHandler，當線程數超過maximumPoolSize時進行處理，處理方式爲隔一段時間檢查線程池是否可以執行新Task，如果可以把拒絕的Task重新放入到線程池，檢查的時間依賴keepAliveTime的大小。

2.連接池（org.apache.commons.dbcp.BasicDataSource）

在使用org.apache.commons.dbcp.BasicDataSource的時候，因爲之前採用了默認配置，所以當訪問量大時，通過JMX觀察到很多Tomcat線程都阻塞在BasicDataSource使用的Apache ObjectPool的鎖上，直接原因當時是因爲BasicDataSource連接池的最大連接數設置的太小，默認的BasicDataSource配置，僅使用8個最大連接。

我還觀察到一個問題，當較長的時間不訪問系統，比如2天，DB上的Mysql會斷掉所以的連接，導致連接池中緩存的連接不能用。爲了解決這些問題，我們充分研究了BasicDataSource，發現了一些優化的點：

Mysql默認支持100個鏈接，所以每個連接池的配置要根據集羣中的機器數進行，如有2臺服務器，可每個設置爲60
initialSize：參數是一直打開的連接數
minEvictableIdleTimeMillis：該參數設置每個連接的空閒時間，超過這個時間連接將被關閉
timeBetweenEvictionRunsMillis：後臺線程的運行週期，用來檢測過期連接
maxActive：最大能分配的連接數
maxIdle：最大空閒數，當連接使用完畢後發現連接數大於maxIdle，連接將被直接關閉。只有initialSize < x < maxIdle的連接將被定期檢測是否超期。這個參數主要用來在峯值訪問時提高吞吐量。
initialSize是如何保持的？經過研究代碼發現，BasicDataSource會關閉所有超期的連接，然後再打開initialSize數量的連接，這個特性與minEvictableIdleTimeMillis、timeBetweenEvictionRunsMillis一起保證了所有超期的initialSize連接都會被重新連接，從而避免了Mysql長時間無動作會斷掉連接的問題。

3.JVM參數

在JVM啓動參數中，可以設置跟內存、垃圾回收相關的一些參數設置，默認情況不做任何設置JVM會工作的很好，但對一些配置很好的Server和具體的應用必須仔細調優才能獲得最佳性能。通過設置我們希望達到一些目標：

GC的時間足夠的小
GC的次數足夠的少
發生Full GC的週期足夠的長

前兩個目前是相悖的，要想GC時間小必須要一個更小的堆，要保證GC次數足夠少，必須保證一個更大的堆，我們只能取其平衡。

（1）針對JVM堆的設置，一般可以通過-Xms -Xmx限定其最小、最大值，爲了防止垃圾收集器在最小、最大之間收縮堆而產生額外的時間，我們通常把最大、最小設置爲相同的值
（2）年輕代和年老代將根據默認的比例（1：2）分配堆內存，可以通過調整二者之間的比率NewRadio來調整二者之間的大小，也可以針對回收代，比如年輕代，通過 -XX:newSize -XX:MaxNewSize來設置其絕對大小。同樣，爲了防止年輕代的堆收縮，我們通常會把-XX:newSize -XX:MaxNewSize設置爲同樣大小

（3）年輕代和年老代設置多大才算合理？這個我問題毫無疑問是沒有答案的，否則也就不會有調優。我們觀察一下二者大小變化有哪些影響

更大的年輕代必然導致更小的年老代，大的年輕代會延長普通GC的週期，但會增加每次GC的時間；小的年老代會導致更頻繁的Full GC
更小的年輕代必然導致更大年老代，小的年輕代會導致普通GC很頻繁，但每次的GC時間會更短；大的年老代會減少Full GC的頻率
如何選擇應該依賴應用程序對象生命週期的分佈情況：如果應用存在大量的臨時對象，應該選擇更大的年輕代；如果存在相對較多的持久對象，年老代應該適當增大。但很多應用都沒有這樣明顯的特性，在抉擇時應該根據以下兩點：（A）本着Full GC儘量少的原則，讓年老代儘量緩存常用對象，JVM的默認比例1：2也是這個道理（B）通過觀察應用一段時間，看其他在峯值時年老代會佔多少內存，在不影響Full GC的前提下，根據實際情況加大年輕代，比如可以把比例控制在1：1。但應該給年老代至少預留1/3的增長空間

（4）在配置較好的機器上（比如多核、大內存），可以爲年老代選擇並行收集算法： -XX:+UseParallelOldGC ，默認爲Serial收集

（5）線程堆棧的設置：每個線程默認會開啓1M的堆棧，用於存放棧幀、調用參數、局部變量等，對大多數應用而言這個默認值太了，一般256K就足用。理論上，在內存不變的情況下，減少每個線程的堆棧，可以產生更多的線程，但這實際上還受限於操作系統。

（4）可以通過下面的參數打Heap Dump信息

-XX:HeapDumpPath
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:/usr/aaa/dump/heap_trace.txt

通過下面參數可以控制OutOfMemoryError時打印堆的信息

-XX:+HeapDumpOnOutOfMemoryError

請看一下一個時間的Java參數配置：（服務器：Linux 64Bit，8Core×16G）

JAVA_OPTS=”$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/aaa/dump/heap_trace.txt -XX:NewSize=1G -XX:MaxNewSize=1G”

經過觀察該配置非常穩定，每次普通GC的時間在10ms左右，Full GC基本不發生，或隔很長很長的時間才發生一次

通過分析dump文件可以發現，每個1小時都會發生一次Full GC，經過多方求證，只要在JVM中開啓了JMX服務，JMX將會1小時執行一次Full GC以清除引用，關於這點請參考附件文檔。

4.程序算法調優：本次不作爲重點

參考資料：

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

來源：http://blog.csdn.net/chen77716/article/details/5695893

=======================================================================================

調優方法

一切都是爲了這一步，調優，在調優之前，我們需要記住下面的原則：

1、多數的Java應用不需要在服務器上進行GC優化；

2、多數導致GC問題的Java應用，都不是因爲我們參數設置錯誤，而是代碼問題；

3、在應用上線之前，先考慮將機器的JVM參數設置到最優（最適合）；

4、減少創建對象的數量；

5、減少使用全局變量和大對象；

6、GC優化是到最後不得已才採用的手段；

7、在實際使用中，分析GC情況優化代碼比優化GC參數要多得多；

GC優化的目的有兩個（http://www.360doc.com/content/13/0305/10/15643_269388816.shtml）：

1、將轉移到老年代的對象數量降低到最小；

2、減少full GC的執行時間；

爲了達到上面的目的，一般地，你需要做的事情有：

1、減少使用全局變量和大對象；

2、調整新生代的大小到最合適；

3、設置老年代的大小爲最合適；

4、選擇合適的GC收集器；

在上面的4條方法中，用了幾個“合適”，那究竟什麼纔算合適，一般的，請參考上面“收集器搭配”和“啓動內存分配”兩節中的建議。但這些建議不是萬能的，需要根據您的機器和應用情況進行發展和變化，實際操作中，可以將兩臺機器分別設置成不同的GC參數，並且進行對比，選用那些確實提高了性能或減少了GC時間的參數。

真正熟練的使用GC調優，是建立在多次進行GC監控和調優的實戰經驗上的，進行監控和調優的一般步驟爲：

1，監控GC的狀態

使用各種JVM工具，查看當前日誌，分析當前JVM參數設置，並且分析當前堆內存快照和gc日誌，根據實際的各區域內存劃分和GC執行時間，覺得是否進行優化；

2，分析結果，判斷是否需要優化

如果各項參數設置合理，系統沒有超時日誌出現，GC頻率不高，GC耗時不高，那麼沒有必要進行GC優化；如果GC時間超過1-3秒，或者頻繁GC，則必須優化；

注：如果滿足下面的指標，則一般不需要進行GC：

Minor GC執行時間不到50ms；

Minor GC執行不頻繁，約10秒一次；

Full GC執行時間不到1s；

Full GC執行頻率不算頻繁，不低於10分鐘1次；

3，調整GC類型和內存分配

如果內存分配過大或過小，或者採用的GC收集器比較慢，則應該優先調整這些參數，並且先找1臺或幾臺機器進行beta，然後比較優化過的機器和沒有優化的機器的性能對比，並有針對性的做出最後選擇；

4，不斷的分析和調整

通過不斷的試驗和試錯，分析並找到最合適的參數

5，全面應用參數

如果找到了最合適的參數，則將這些參數應用到所有服務器，並進行後續跟蹤。

調優實例

上面的內容都是紙上談兵，下面我們以一些真實例子來進行說明：

實例1：

筆者昨日發現部分開發測試機器出現異常：java.lang.OutOfMemoryError: GC overhead limit exceeded，這個異常代表：

GC爲了釋放很小的空間卻耗費了太多的時間，其原因一般有兩個：1，堆太小，2，有死循環或大對象；

筆者首先排除了第2個原因，因爲這個應用同時是在線上運行的，如果有問題，早就掛了。所以懷疑是這臺機器中堆設置太小；

使用ps -ef |grep “java”查看，發現：

該應用的堆區設置只有768m，而機器內存有2g，機器上只跑這一個java應用，沒有其他需要佔用內存的地方。另外，這個應用比較大，需要佔用的內存也比較多；

筆者通過上面的情況判斷，只需要改變堆中各區域的大小設置即可，於是改成下面的情況：

跟蹤運行情況發現，相關異常沒有再出現；

實例2：（http://www.360doc.com/content/13/0305/10/15643_269388816.shtml）

一個服務系統，經常出現卡頓，分析原因，發現Full GC時間太長：

jstat -gcutil:

S0 S1 E O P YGC YGCT FGC FGCT GCT

12.16 0.00 5.18 63.78 20.32 54 2.047 5 6.946 8.993

分析上面的數據，發現Young GC執行了54次，耗時2.047秒，每次Young GC耗時37ms，在正常範圍，而Full GC執行了5次，耗時6.946秒，每次平均1.389s，數據顯示出來的問題是：Full GC耗時較長，分析該系統的是指發現，NewRatio=9，也就是說，新生代和老生代大小之比爲1:9，這就是問題的原因：

1，新生代太小，導致對象提前進入老年代，觸發老年代發生Full GC；

2，老年代較大，進行Full GC時耗時較大；

優化的方法是調整NewRatio的值，調整到4，發現Full GC沒有再發生，只有Young GC在執行。這就是把對象控制在新生代就清理掉，沒有進入老年代（這種做法對一些應用是很有用的，但並不是對所有應用都要這麼做）

實例3：

一應用在性能測試過程中，發現內存佔用率很高，Full GC頻繁，使用sudo -u admin -H jmap -dump:format=b,file=文件名.hprof pid 來dump內存，生成dump文件，並使用Eclipse下的mat差距進行分析，發現：

從圖中可以看出，這個線程存在問題，隊列LinkedBlockingQueue所引用的大量對象並未釋放，導致整個線程佔用內存高達378m，此時通知開發人員進行代碼優化，將相關對象釋放掉即可。

來源：Java系列筆記(4) - JVM監控與調優

原文二地址 http://unixboy.iteye.com/blog/174173

堆大小設置
JVM 中最大堆大小有三方面限制：相關操作系統的數據模型（32-bt還是64-bit）限制；系統的可用虛擬內存限制；系統的可用物理內存限制。32位系統下，一般限制在1.5G~2G；64爲操作系統對內存無限制。我在Windows Server 2003 系統，3.5G物理內存，JDK5.0下測試，最大可設置爲1478m。
典型設置：
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
  -Xmx3550m：設置JVM最大可用內存爲3550M。
  -Xms3550m：設置JVM初始內存爲3550m。此值可以設置與-Xmx相同，以避免每次垃圾回收完成後JVM重新分配內存。
  -Xmn2g：設置年輕代大小爲2G。整個JVM內存大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小爲64m，所以增大年輕代後，將會減小年老代大小。此值對系統性能影響較大，Sun官方推薦配置爲整個堆的3/8。
  -Xss128k：設置每個線程的堆棧大小。JDK5.0以後每個線程堆棧大小爲1M，以前每個線程堆棧大小爲256K。更具應用的線程所需內存大小進行調整。在相同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在3000~5000左右。
- java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
  -XX:NewRatio=4:設置年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設置爲4，則年輕代與年老代所佔比值爲1：4，年輕代佔整個堆棧的1/5
  -XX:SurvivorRatio=4：設置年輕代中Eden區與Survivor區的大小比值。設置爲4，則兩個Survivor區與一個Eden區的比值爲2:4，一個Survivor區佔整個年輕代的1/6
  -XX:MaxPermSize=16m:設置持久代大小爲16m。
  -XX:MaxTenuringThreshold=0：設置垃圾最大年齡。如果設置爲0的話，則年輕代對象不經過Survivor區，直接進入年老代。對於年老代比較多的應用，可以提高效率。如果將此值設置爲一個較大值，則年輕代對象會在Survivor區進行多次複製，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。
回收器選擇
JVM回收器分爲三類：串行收集器、並行收集器、併發收集器，但是串行收集器只適用於小數據量的情況，所以這裏的選擇主要針對並行收集器和併發收集器。默認情況下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在啓動時加入相應參數。JDK5.0以後，JVM會根據當前系統配置進行判斷。
1. 吞吐量優先的並行收集器
  如上文所述，並行收集器主要以到達一定的吞吐量爲目標，適用於科學技術和後臺處理等。
  典型配置：
  - java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
    -XX:+UseParallelGC：選擇垃圾收集器爲並行收集器。此配置僅對年輕代有效。即上述配置下，年輕代使用併發收集，而年老代仍舊使用串行收集。
    -XX:ParallelGCThreads=20：配置並行收集器的線程數，即：同時多少個線程一起進行垃圾回收。此值最好配置與處理器數目相等。
  - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
    -XX:+UseParallelOldGC：配置年老代垃圾收集方式爲並行收集。JDK6.0支持對年老代並行收集。
  - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
    -XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間，如果無法滿足此時間，JVM會自動調整年輕代大小，以滿足此值。
  - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
    -XX:+UseAdaptiveSizePolicy：設置此選項後，並行收集器會自動選擇年輕代區大小和相應的Survivor區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用並行收集器時，一直打開。
2. 響應時間優先的併發收集器
  如上文所述，併發收集器主要是保證系統的響應時間，減少垃圾收集時的停頓時間。適用於應用服務器、電信領域等。
  典型配置：
  - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
    -XX:+UseConcMarkSweepGC：設置年老代爲併發收集。測試中配置這個以後，-XX:NewRatio=4的配置失效了，原因不明。所以，此時年輕代大小最好用-Xmn設置。
    -XX:+UseParNewGC:設置年輕代爲並行收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，所以無需再設置此值。
  - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
    -XX:CMSFullGCsBeforeCompaction：由於併發收集器不對內存空間進行壓縮、整理，所以運行一段時間以後會產生“碎片”，使得運行效率降低。此值設置運行多少次GC以後對內存空間進行壓縮、整理。
    -XX:+UseCMSCompactAtFullCollection：打開對年老代的壓縮。可能會影響性能，但是可以消除碎片
輔助信息
JVM提供了大量命令行參數，打印信息，供調試使用。主要有以下一些：
- -XX:+PrintGC
  輸出形式：[GC 118250K->113543K(130112K), 0.0094143 secs]
  [Full GC 121376K->10414K(130112K), 0.0650971 secs]
- -XX:+PrintGCDetails
  輸出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
  [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
- -XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可與上面兩個混合使用
  輸出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
- -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中斷的執行時間。可與上面混合使用
  輸出形式：Application time: 0.5291524 seconds
- -XX:+PrintGCApplicationStoppedTime：打印垃圾回收期間程序暫停的時間。可與上面混合使用
  輸出形式：Total time for which application threads were stopped: 0.0468229 seconds
- -XX:PrintHeapAtGC:打印GC前後的詳細堆棧信息
  輸出形式：
  34.702: [GC {Heap before gc invocations=7:
  def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
  eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
  from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
  to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
  tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
  the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
  compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
     the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
      ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
      rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
  34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
  def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
  eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
  from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
  to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
  tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
  the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
  compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
     the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
      ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
      rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
  }
  , 0.0757599 secs]
- -Xloggc:filename:與上面幾個配合使用，把相關日誌信息記錄到文件以便分析。
常見配置彙總
1. 堆設置
  - -Xms:初始堆大小
  - -Xmx:最大堆大小
  - -XX:NewSize=n:設置年輕代大小
  - -XX:NewRatio=n:設置年輕代和年老代的比值。如:爲3，表示年輕代與年老代比值爲1：3，年輕代佔整個年輕代年老代和的1/4
  - -XX:SurvivorRatio=n:年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如：3，表示Eden：Survivor=3：2，一個Survivor區佔整個年輕代的1/5
  - -XX:MaxPermSize=n:設置持久代大小
2. 收集器設置
  - -XX:+UseSerialGC:設置串行收集器
  - -XX:+UseParallelGC:設置並行收集器
  - -XX:+UseParalledlOldGC:設置並行年老代收集器
  - -XX:+UseConcMarkSweepGC:設置併發收集器
3. 垃圾回收統計信息
  - -XX:+PrintGC
  - -XX:+PrintGCDetails
  - -XX:+PrintGCTimeStamps
  - -Xloggc:filename
4. 並行收集器設置
  - -XX:ParallelGCThreads=n:設置並行收集器收集時使用的CPU數。並行收集線程數。
  - -XX:MaxGCPauseMillis=n:設置並行收集最大暫停時間
  - -XX:GCTimeRatio=n:設置垃圾回收時間佔程序運行時間的百分比。公式爲1/(1+n)
5. 併發收集器設置
  - -XX:+CMSIncrementalMode:設置爲增量模式。適用於單CPU情況。
  - -XX:ParallelGCThreads=n:設置併發收集器年輕代收集方式爲並行收集時，使用的CPU數。並行收集線程數。

四、調優總結

年輕代大小選擇
- 響應時間優先的應用：儘可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的對象。
- 吞吐量優先的應用：儘可能的設置大，可能到達Gbit的程度。因爲對響應時間沒有要求，垃圾收集可以並行進行，一般適合8CPU以上的應用。
年老代大小選擇
- 響應時間優先的應用：年老代使用併發收集器，所以其大小需要小心設置，一般要考慮併發會話率和會話持續時間等一些參數。如果堆設置小了，可以會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；如果堆大了，則需要較長的收集時間。最優化的方案，一般需要參考以下數據獲得：
  - 併發垃圾收集信息
  - 持久代併發收集次數
  - 傳統GC信息
  - 花在年輕代和年老代回收上的時間比例
  減少年輕代和年老代花費的時間，一般會提高應用的效率
- 吞吐量優先的應用：一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是，這樣可以儘可能回收掉大部分短期對象，減少中期的對象，而年老代盡存放長期存活對象。
較小堆引起的碎片問題
因爲年老代的併發收集器使用標記、清除算法，所以不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合併，這樣可以分配給較大的對象。但是，當堆空間較小時，運行一段時間以後，就會出現“碎片”，如果併發收集器找不到足夠的空間，那麼併發收集器將會停止，然後使用傳統的標記、清除方式進行回收。如果出現“碎片”，可能需要進行如下配置：
- -XX:+UseCMSCompactAtFullCollection：使用併發收集器時，開啓對年老代的壓縮。
- -XX:CMSFullGCsBeforeCompaction=0：上面配置開啓的情況下，這裏設置多少次Full GC後，對年老代進行壓縮

JVM調優之 -Xms -Xmx -Xmn -Xss

springboot2.1.8+sharding-jdbc3.x自定義分片

jvm指令手冊

centos7下canal1.1.4安裝

JAVA排序彙總

數字簽名是什麼？

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結