原文地址，譯文地址，作者：PATRICK PESCHLOW，譯者：鄭旭東  校對：樑海艦

理想的情況下，一個Java程式使用JVM的預設設定也可以執行得很好，所以一般來說，沒有必要設定任何JVM引數。然而，由於一些效能問題（很不幸的是，這些問題經常出現），一些相關的JVM引數知識會是我們工作中得好夥伴。在這篇文章中，我們將介紹一些關於JVM記憶體管理的引數。知道並理解這些引數，將對開發者和運維人員很有幫助。

所有已制定的HotSpot記憶體管理和垃圾回收演算法都基於一個相同的堆記憶體劃分：新生代（young generation）裡儲存著新分配的和較年輕的物件，老年代（old generation）裡儲存著長壽的物件。在此之外，永久代（permanent generation）儲存著那些需要伴隨整個JVM生命週期的物件，比如，已載入的物件的類定義或者String物件內部Cache。接下來，我們將假設堆記憶體是按照新生代、老年代和永久代這一經典策略劃分的。然而，其他的一些堆記憶體劃分策略也是可行的，一個突出的例子就是新的G1垃圾回收器，它模糊了新生代和老年代之間的區別。此外，目前的開發程序似乎表明在未來的HotSpot JVM版本中，將不會區分老年代和永久代。

-Xms and -Xmx (or: -XX:InitialHeapSize and -XX:MaxHeapSize)

-Xms和-Xmx可以說是最流行的JVM引數，它們可以允許我們指定JVM的初始和最大堆記憶體大小。一般來說，這兩個引數的數值單位是Byte，但同時它們也支援使用速記符號，比如“k”或者“K”代表“kilo”，“m”或者“M”代表“mega”，“g”或者“G”代表“giga”。舉個例子，下面的命令啟動了一個初始化堆記憶體為128M，最大堆記憶體為2G，名叫“MyApp”的Java應用程式。

java -Xms128m -Xmx2g MyApp

在實際使用過程中，初始化堆記憶體的大小通常被視為堆記憶體大小的下界。然而JVM可以在執行時動態的調整堆記憶體的大小，所以理論上來說我們有可能會看到堆記憶體的大小小於初始化堆記憶體的大小。但是即使在非常低的堆記憶體使用下，我也從來沒有遇到過這種情況。這種行為將會方便開發者和系統管理員，因為我們可以通過將“-Xms”和“-Xmx”設定為相同大小來獲得一個固定大小的堆記憶體。 -Xms和-Xmx實際上是-XX:InitialHeapSize和-XX:MaxHeapSize的縮寫。我們也可以直接使用這兩個引數，它們所起得效果是一樣的：

$ java -XX:InitialHeapSize=128m -XX:MaxHeapSize=2g MyApp

需要注意的是，所有JVM關於初始\最大堆記憶體大小的輸出都是使用它們的完整名稱：“InitialHeapSize”和“InitialHeapSize”。所以當你查詢一個正在執行的JVM的堆記憶體大小時，如使用-XX:+PrintCommandLineFlags引數或者通過JMX查詢，你應該尋找“InitialHeapSize”和“InitialHeapSize”標誌而不是“Xms”和“Xmx”。

-XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath

如果我們沒法為-Xmx（最大堆記憶體）設定一個合適的大小，那麼就有可能面臨記憶體溢位（OutOfMemoryError）的風險，這可能是我們使用JVM時面臨的最可怕的猛獸之一。就同另外一篇關於這個主題的博文說的一樣，導致記憶體溢位的根本原因需要仔細的定位。通常來說，分析堆記憶體快照（Heap Dump）是一個很好的定位手段，如果發生記憶體溢位時沒有生成記憶體快照那就實在是太糟了，特別是對於那種JVM已經崩潰或者錯誤只出現在順利運行了數小時甚至數天的生產系統上的情況。

幸運的是，我們可以通過設定-XX:+HeapDumpOnOutOfMemoryError 讓JVM在發生記憶體溢位時自動的生成堆記憶體快照。有了這個引數，當我們不得不面對記憶體溢位異常的時候會節約大量的時間。預設情況下，堆記憶體快照會儲存在JVM的啟動目錄下名為java_pid<pid>.hprof 的檔案裡（在這裡<pid>就是JVM程序的程序號）。也可以通過設定-XX:HeapDumpPath=<path>來改變預設的堆記憶體快照生成路徑，<path>可以是相對或者絕對路徑。

雖然這一切聽起來很不錯，但有一點我們需要牢記。堆記憶體快照檔案有可能很龐大，特別是當記憶體溢位錯誤發生的時候。因此，我們推薦將堆記憶體快照生成路徑指定到一個擁有足夠磁碟空間的地方。

-XX:OnOutOfMemoryError

當記憶體溢發生時，我們甚至可以可以執行一些指令，比如發個E-mail通知管理員或者執行一些清理工作。通過-XX:OnOutOfMemoryError 這個引數我們可以做到這一點，這個引數可以接受一串指令和它們的引數。在這裡，我們將不會深入它的細節，但我們提供了它的一個例子。在下面的例子中，當記憶體溢位錯誤發生的時候，我們會將堆記憶體快照寫到/tmp/heapdump.hprof 檔案並且在JVM的執行目錄執行指令碼cleanup.sh

$ java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:OnOutOfMemoryError ="sh ~/cleanup.sh" MyApp

 -XX:PermSize and -XX:MaxPermSize

永久代在堆記憶體中是一塊獨立的區域，它包含了所有JVM載入的類的物件表示。為了成功執行應用程式，JVM會載入很多類（因為它們依賴於大量的第三方庫，而這又依賴於更多的庫並且需要從裡面將類載入進來）這就需要增加永久代的大小。我們可以使用-XX:PermSize 和-XX:MaxPermSize 來達到這個目的。其中-XX:MaxPermSize 用於設定永久代大小的最大值，-XX:PermSize 用於設定永久代初始大小。下面是一個簡單的例子：

$ java -XX:PermSize=128m -XX:MaxPermSize=256m MyApp

請注意，這裡設定的永久代大小並不會被包括在使用引數-XX:MaxHeapSize 設定的堆記憶體大小中。也就是說，通過-XX:MaxPermSize設定的永久代記憶體可能會需要由引數-XX:MaxHeapSize 設定的堆記憶體以外的更多的一些堆記憶體。

-XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize

JVM一個有趣的，但往往被忽視的記憶體區域是“程式碼快取”，它是用來儲存已編譯方法生成的原生代碼。程式碼快取確實很少引起效能問題，但是一旦發生其影響可能是毀滅性的。如果程式碼快取被佔滿，JVM會打印出一條警告訊息，並切換到interpreted-only 模式：JIT編譯器被停用，位元組碼將不再會被編譯成機器碼。因此，應用程式將繼續執行，但執行速度會降低一個數量級，直到有人注意到這個問題。就像其他記憶體區域一樣，我們可以自定義程式碼快取的大小。相關的引數是-XX:InitialCodeCacheSize 和-XX:ReservedCodeCacheSize，它們的引數和上面介紹的引數一樣，都是位元組值。

-XX:+UseCodeCacheFlushing

如果程式碼快取不斷增長，例如，因為熱部署引起的記憶體洩漏，那麼提高程式碼的快取大小隻會延緩其發生溢位。為了避免這種情況的發生，我們可以嘗試一個有趣的新引數：當代碼快取被填滿時讓JVM放棄一些編譯程式碼。通過使用-XX:+UseCodeCacheFlushing 這個引數，我們至少可以避免當代碼快取被填滿的時候JVM切換到interpreted-only 模式。不過，我仍建議儘快解決程式碼快取問題發生的根本原因，如找出記憶體洩漏並修復它。