1. 背景

硬體供應商多次反映，在tomcat啟動一段時間後，經常出現cpu佔用率100%，且重啟前一直保持在100%的情況。在重啟後cpu佔用率回落，但是一段時間後再次出現問題。

下圖為cpu佔用率100%時使用top命令的截圖，可以看到java程序的cpu佔用率幾經幾乎達到了400%（伺服器為4核cpu）

<1>

2.問題定位

2.1問題猜測

對於cpu佔用率100%的情況，產生以下兩種猜測：

a. 程式長時間佔用系統IO，導致CPU佔用率100%

b.程式存在嚴重記憶體洩露，導致jvm頻繁執行full GC，從而使cpu佔用率提高，造成伺服器假死

2.2jvm的記憶體管理和垃圾回收機制

java對記憶體的管理主要分為兩種：棧（stack）和堆（heap） 方法區，程式計數器等不做討論

stack: 在每個執行緒啟動時由jvm自動分配固定大小的地址，stack內主要儲存操作符，值物件(int,float等基礎資料型別)，和引用物件的指標由於stack固定大小，且主要操作為push和pop，並不涉及到垃圾回收等問題，因此不做展開。

heap:堆線上程執行過程中自動分配大小，大小可以隨時改變，主要用於儲存物件(Object),物件在結束生命週期結束之後便會由JVM的垃圾回收機制自動進行回收堆可分為3大部分年輕代(Young Generation)、年老代(Old Generation)和持久代(Permanent Generation)。

年輕代：年輕代又可分為3個小區：Eden，兩個等大的Survior區(from 和 to)。其中Eden主要存放新建的物件，當Eden區無法再存放更多的物件時，jvm會發起年輕代GC(Minor GC),釋放Eden中的物件，Minor GC的特點是發生頻率高，執行速度也極快，對系統效率的影響並不是很大。當Eden區中的物件經過一次Minor GC仍然沒有被釋放時，這部分物件將被移入Survior區(物件可能進入from區，也可能進入to區，有具體演算法，此處不做展開)。當Survior區中的物件經歷過數次的Minor GC之後仍然存活，將被移入年老代。

年老代：年老代中用來存放從年輕代過來的長時間使用的物件，大部分的JVM記憶體溢位錯誤均發生在這個區域。當年老代被過度佔用，無法存放下更多的資料時，jvm會發起一次年老代GC(Major GC\Full GC),該型別GC會釋放年老代中的資源，雖然該GC觸發頻率很低，但是對硬體資源的消耗較高，且Full GC過程中會暫停該執行緒的

執行。如果系統中存在記憶體洩露，頻繁的觸發Full GC,將會嚴重的佔用伺服器資源，造成應用的假死，這也是我之前猜測b的依據。

持久代：持久代中用於存放jvm的反射類等，如class等，此區域對GC的影響不大，也不大會發生記憶體溢位的情況。

下圖是引用網上的一張圖片，更形象的描述了heap區的構成

<2>

2.3jstat、jmap實戰

ok，在弄清楚jvm的GC機制之後，就有了努力的方向了，為了弄清楚GC具體的工作情況，就要使用到jstat命令了。

jstat(Java Virtual Machine Statistics Monitoring Tool)是jdk自帶的監控工具，位置在%JAVA_HOME%/bin 下,命令使用方法為

 jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

下圖是我對系統中tomcat程序的監控情況

<3>

<4>

命令中 -gcutil表示統計GC情況，5125為tomcat的pid,10000表示沒10s統計一次，5表示一共統計5次

結果中s0為from區，s1為to區，E為Eden區，O為Old區，P為Permanent區，YGC為yong GC次數，YGCT為yong GC執行的總時間，FGC為Full GC次數，FGCT為Full GC總時間，GCT為GC總時間。

上面圖<3>為cpu佔用率高時的截圖，圖<4>為正常情況下截圖。

很明顯的看到GC次數相差不大的情況下，GC耗時存在很大的差距，推測此時系統中可能存在記憶體洩漏的情況。

為了確定jvm中具體有哪些生存的物件，就需要用到jdk自帶的另一個監控工具，jmap了

jmap(Memory Map)用於監控系統記憶體中存活的物件。

使用命令: jmap -histo:live 5125>> /opt/jmap.txt  

（如果要dump所有物件，可以通過命令：

jmap -dump:file=a.hprof pid

）

其中5125為pid ，由於資料較多，將資料儲存在txt檔案中進行分析，下圖列出了對記憶體佔用排名前幾的物件

<5>

一眼看去，String物件穩居第一，好吧，專案中對String的處理確實有不少問題，但是，排名第三的這是什麼東西？！

在程式碼中一查，這個物件只在一個上傳檔案中的Servlet中被用到了一次，很明顯的記憶體洩漏！

3.問題解決

很明顯，jspsmart這個外掛正是記憶體洩漏的元凶，網上查詢資料之後確定，jspsmart由於自身bug，在長時間執行後會產生兩個嚴重問題： a. 客戶端在未完成上傳時便主動終止了上傳操作，此時客戶端不再上傳檔案，但是服務端仍然會佔用InputStream，並且不會主動釋放，造成cpu佔用率100%，猜測a證實 b. 客戶上傳的檔案損壞，在建立File物件時無法找到檔案終止標識，因此一直在建立新的File物件，造成記憶體洩漏。 由此，伺服器記憶體溢位和cpu佔用率100%兩個問題都找到了關鍵所在，接下來的工作就像對簡單了，使用apache的開源專案commons-upload替換原來的jspsmart來完成檔案上傳的工作，替換過後，系統資源佔用正常，附上bug修復後的jmap截圖 <6>