理想的情況下，一個 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 模式。不過，我仍建議盡快解決代碼緩存問題發生的根本原因，如找出內存洩漏並修復它。
