之前一直對於JVM調優這塊比較混淆，看到這篇文章後豁然開朗，好文應該分享，記錄下來，慢慢“品味”。
文章轉自來源
Tomcat、Jetty、GlassFish 等等這系列 Web容器/應用服務器，雖然做爲容器，提供的是一個 Java Web 的運行時環境，以支持Servlet/JSP 等等這些內容的運行，但我們都很清楚，其本質上還是一個 Java 應用程序。 每次對於 容器的啓動運行，都是把這個 Java 程序跑起來，來實現 Web 容器的能力。
做爲一類“特殊”的 Java 應用程序，和任務其他的 Java 應用一樣，需要使用到JVM，會有堆，會使用到垃圾回收，會涉及到不同的堆分區比例...
因此在對Web 容器( 應用服務器) 的調優中必不可少的是對於 JVM 的調優。
對於 JVM 的調優，主要有兩個方面考慮：
- 內存大小配置
- 垃圾回收算法選擇
當然，確切的說，以上兩點並不互相獨立，內存的大小配置也會影響垃圾回收的執行效率。
其中內存大小配置，最主要做的有
- 確定內存佔用的總大小
- 確定內存中各個代(Gen) 的大小劃分
內存大小配置
所謂內存大小的佔用，是指應用程序啓動後穩定運行一小段時間時，觀察到的內存佔用情況。
以 HotSpot 虛擬機爲例，Java 堆主要有三個空間：
新生代、老年代和永久代。
根據不同應用的特別，觀察應用對於內存的佔用，如果有大量的臨時對象，不會重複使用，則可以調整 New Gen， 這樣這些臨時對象就在新生代創建完成，並在 Minor GC 產生時被回收，這樣較短生存活的對象不會晉升到老年代，從而可以避免垃圾堆集產生 Full GC。
理想狀態下，短期存活的對象都只在新生代完成生命週期，被費時勁少的
Minor GC 回收完成， 而長期存活，將會多次使用的在多次回收之後晉升到老年代， 最終經過 Full GC 完成生命週期。
這裏涉及到關於內存大小的調整參數有：
- -Xms
- -Xmx
這兩個參數用於配置 heap 的起始大小和最大值。這裏需要經過觀察，找一個合適的值，設置太大會導致內存浪費，同時也會導致垃圾回收耗時太長。對於 Tomcat 來說，一般都會將初始值和最大值設置爲相同值，這樣就避免在初始內存不足時觸發 Full GC 來進行擴展內存。
設定 heap 大小之後，要根據對象生命週期的特徵，來調整新生代與老年代的大小比例。
涉及到的參數有：
- -XX:NewSize
- -XX:NewRatio
- -XX:MaxNewSize
- -Xmn
第一個是直接設置新生代初始大小，第二個是設置比例(Ratio)。太高或太低都會導致 GC 不能高效的工作。畢竟 Minor GC 也是要耗時的。最後一個設置新生代的初始值和最大值相同，堆空間的變化不影響其值。
對於使用了大量第三方類庫的應用來說，會加載許多框架依賴的類，使用過程中可能會遇到因爲Perm Gen 不足產生的 OOM，這種情況可以通過觀察穩定狀態下 Perm 區的佔用，再通過參數設置。
- -XX:PermSize
- -XX:MaxPermSize
- -XX:MaxMetaspaceSize
第一個會設置Perm區的初始大小，第二個用於設置Perm 區的最大值。在Java 8的時候， Perm 區被移除，改爲Metaspace，不過如果遇到類似的OOM,依然可以調整其大小。
此外，對於使用大量線程的應用，也可以配置 -Xss，主要用於設置單個線程的stack 大小。注意，是單個的大小，因此設置值越大，會佔用越大，可用的線程數也就越少。
這裏的配置一般對於-X開始的可以直接在後面用數字加單位，而-XX的則需要等號後數字再加單位，例如：
java -Xms100m -Xmx200m -XX:PermSize=300m
這裏數字後的單可以是m,g,k代表計算機中的不同單位。
那我們前面一直在說根據不同的應用，觀察分析設置堆的大小，堆的各個代的大小，那具體觀察什麼呢？
我們一般在JVM的配置中增加一些打印 GC 日誌的選項，配置方式和上面的類似，這樣在 GC 產生時，會打印出各個代佔用的大小，具體觸發時間等。推薦的配置有以下幾個：
- -XX:+PrintGCTimeStamps
- -XX:+PrintGCDetails
- -Xloggc:<文件名>
- -XX:PrintGCDateStamps
第一個和第四個選項可以任選一個，第一個打印自JVM啓動以來的時間，一般也稱爲uptime, 第四個打印的是系統當前日期和時間。
根據 GC 日誌產生的內容，來觀察具體的大小，開始使用上述的配置參數進行調整。當然，也可以用 JConsole, JVisual VM 這些工具可視化的進行了解再調整。
垃圾回收算法
不同的垃圾回收算法，對於應用的影響很大。一方面可能在一個服務器上卻使用了單線程的回收算法，也可能應用對於響應要求很高，但卻使用了一個吞吐量優先的算法，導致響應太慢。
所以對於垃圾回收算法的選擇，一般都是根據應用的特點，是要低延遲還是高吞吐量，選擇合適的算法。我們前面也提到，垃圾回收算法和內存的大小配置並非獨立的，內存設置大是回收的頻率會降低，但每次的執行時間也會變長。所以這裏也是一個需要權衡的地方。
- 延遲、吞吐量調優
- 其他 JVM 配置
垃圾回收算法對應到的就是不同的垃圾收集器，具體到在 JVM 中的配置，是使用 -XX:+UseParallelOldGC 或者 -XX:+UseConcMarkSweepGC 這種不同的收集器來達到選擇算法的目的。
其中 ParallelGC 也稱爲 吞吐量優先收集器，可以提升應用的吞吐量，但在老年代大小調整之，進行幾次垃圾回收後，不能滿足應用的低延遲要求。
一般常用到ConcMarkSweepGC， 也稱之爲 CMS GC，其可以做到老年代的垃圾回收與應用程序的純種並行執行，所以可以實現低延遲。
這裏注意，由於 CMS GC 和其他GC回收算法使用的框架不同，因此不能混用，在使用CMS 進行老年代回收時，新生代默認使用了單線程回收算法，此時可以通過配置 -XX:+UseParNewGC來使用 新生代並行回收。
由於CMS是垃圾回收和應用線程並行，因此需要額外的CPU處理資源，如果只有一個CPU的機器，或者有多個忙碌的CPU，又想要使用低延遲的收集器，此時可以通過配置 CMS 收集器的增量模式來進行回收，通過指定 -XX:+CMSIncrementalMode 來開啓增量模式。此時交替運行垃圾收集器應用線程。通過配置
-XX:CMSIncrementalSafetyFactor=X， -XX:CMSIncrementalDutyCycleMin=Y,
-XX:CMSIncrementalPacing 可以控制垃圾收集後臺線程爲應用線程讓出多少CPU週期。
參數-XX:+CMSParallelRemarkEnabled 用來降低標記停頓，另外由於CMS 回收後的老年代內存空間並不是連續的，因此通過參數
-XX:+UseCMSCompactAtFullCollection 在Full GC的時候對年老代的壓縮。
在JDK1.7 的時候引入了 G1 收集器，可以通過配置-XX:+UseG1GC 來開啓。這一方面的實戰經驗不多，有相關使用經驗的朋友歡迎分享。
此外，還可以對新生代進行更細緻的配置，比如設置Eden 和 Suvivor 區的比例等，和Newxx類似，可以通過SuvivorRation設置比例。
其他 JVM 配置
可以使用 -XX:+DisableExplicitGC 選項來禁止顯式的 System.gc 的調用。這個使用時需要評估後再使用。
所謂調優，就是一個不斷調整和優化的過程，需要觀察、配置、測試再如此重複。有相關經驗的朋友歡迎留言補充！
說到底，那上面的這些選項是要配置在哪裏呢？ 我們前面提到 Tomcat 本質也是個普通的 Java 應用，因此和一般的 Java 啓動方式類似，也是類似
java -Xms100m -XX:+UseParallelOldGC 應用主類
通過這種形式來啓動，區別只是 Tomcat 將上述命令放到了文件中，對應到不同的操作系統，Windows下使用 bat文件， Linux下使用 sh 文件。
所以我們的配置項也是加到這些文件中。
我們來看catalina.sh中實際啓動時執行的命令：
所以我們的選項可以加到
JAVA_OPTS
CATALINA_OPTS
這些可選項中。
配置比較簡單，例如下面這樣：
配置的時候需要特別注意的是，不要把前面已經有的配置沖掉，比如
在配置JAVA_OPTS的時候，要把前面已經配置的加上，寫起來是這樣：
JAVA_OPTS="$JAVA_OPTS 新增的內容"