原文地址，譯文地址，做者：PATRICK PESCHLOW，譯者：鄭旭東 校對：梁海艦java
理想的狀況下，一個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應用程序。緩存
1 java -Xms128m -Xmx2g MyApp
在實際使用過程當中，初始化堆內存的大小一般被視爲堆內存大小的下界。然而JVM能夠在運行時動態的調整堆內存的大小，因此理論上來講咱們有可能會看到堆內存的大小小於初始化堆內存的大小。可是即便在很是低的堆內存使用下，我也歷來沒有遇到過這種狀況。這種行爲將會方便開發者和系統管理員，由於咱們能夠經過將「-Xms」和「-Xmx」設置爲相同大小來得到一個固定大小的堆內存。 -Xms和-Xmx其實是-XX:InitialHeapSize和-XX:MaxHeapSize的縮寫。咱們也能夠直接使用這兩個參數，它們所起得效果是同樣的：併發
1 $ 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已經崩潰或者錯誤只出如今順利運行了數小時甚至數天的生產系統上的狀況。jvm
幸運的是，咱們能夠經過設置-XX:+HeapDumpOnOutOfMemoryError 讓JVM在發生內存溢出時自動的生成堆內存快照。有了這個參數，當咱們不得不面對內存溢出異常的時候會節約大量的時間。默認狀況下，堆內存快照會保存在JVM的啓動目錄下名爲java_pid<pid>.hprof 的文件裏（在這裏<pid>就是JVM進程的進程號）。也能夠經過設置-XX:HeapDumpPath=<path>來改變默認的堆內存快照生成路徑，<path>能夠是相對或者絕對路徑。post
雖然這一切聽起來很不錯，但有一點咱們須要牢記。堆內存快照文件有可能很龐大，特別是當內存溢出錯誤發生的時候。所以，咱們推薦將堆內存快照生成路徑指定到一個擁有足夠磁盤空間的地方。性能
-XX:OnOutOfMemoryError
當內存溢發生時，咱們甚至能夠能夠執行一些指令，好比發個E-mail通知管理員或者執行一些清理工做。經過-XX:OnOutOfMemoryError 這個參數咱們能夠作到這一點，這個參數能夠接受一串指令和它們的參數。在這裏，咱們將不會深刻它的細節，但咱們提供了它的一個例子。在下面的例子中，當內存溢出錯誤發生的時候，咱們會將堆內存快照寫到/tmp/heapdump.hprof 文件而且在JVM的運行目錄執行腳本cleanup.shspa
1 $ 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 用於設置永久代初始大小。下面是一個簡單的例子：
1 $ 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 模式。不過，我仍建議儘快解決代碼緩存問題發生的根本緣由，如找出內存泄漏並修復它。
原創文章，轉載請註明： 轉載自併發編程網 – ifeve.com本文連接地址: JVM實用參數（四）內存調優