理想的情況下，一個 Java 程式使用 JVM 的預設設置也可以運行得很好，所以一般來說，沒有必要設置任何 JVM 參數。然而，由於一些性能問題（很不幸的是，這些問題經常出現），一些相關的 JVM 參數知識會是我們工作中得好伙伴。在這篇文章中，我們將介紹一些關於 JVM 記憶體管理的參數。知道並理解這 ...
理想的情況下，一個 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.hprof 的文件里（在這裡 就是 JVM 進程的進程號）。也可以通過設置 - XX:HeapDumpPath= 來改變預設的堆記憶體快照生成路徑， 可以是相對或者絕對路徑。
雖然這一切聽起來很不錯，但有一點我們需要牢記。堆記憶體快照文件有可能很龐大，特別是當記憶體溢出錯誤發生的時候。因此，我們推薦將堆記憶體快照生成路徑指定到一個擁有足夠磁碟空間的地方。
-XX:OnOutOfMemoryError
當記憶體溢發生時，我們甚至可以可以執行一些指令，比如發個 E-mail 通知管理員或者執行一些清理工作。通過 - XX:OnOutOfMemoryError 這個參數我們可以做到這一點，這個參數可以接受一串指令和它們的參數。在這裡，我們將不會深入它的細節，但我們提供了它的一個例子。在下麵的例子中，當內 存溢出錯誤發生的時候，我們會將堆記憶體快照寫到 /tmp/heapdump.hprof 文件並且在 JVM 的運行目錄執行腳本 cleanup.sh
$ java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:OnOutOfMemoryError =
-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 模式。不過，我仍建議儘快解決代碼緩存問題發生的根本原因，如找出記憶體泄漏並修複它。
