Tomcat 性能調優之 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 這些工具可視化的進行了解再調整。工具的使用可以參考歷史文章
Java七武器系列多情環 --多功能Profiling工具 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 新增的內容"
【本文為51CTO專欄作者“侯樹成”的原創稿件，轉載請通過作者微信公眾號『Tomcat那些事兒』獲取授權】
