近期需要對公司的接口做線上的巡查監(jiān)控，需要寫一個(gè)腳本放到服務(wù)器上，定時(shí)運(yùn)行腳本監(jiān)測線上接口是否正常。
測試的接口不是HTTP協(xié)議，而是公司基于TCP協(xié)議開發(fā)的私有協(xié)議，因此不能直接用現(xiàn)成的一些接口測試工具，需要自己寫代碼來調(diào)用接口。
由于是私有協(xié)議，為了方便各業(yè)務(wù)項(xiàng)目進(jìn)行通信，開發(fā)部門統(tǒng)一提供了一個(gè)TClient的jar包，底層使用了netty框架進(jìn)行通信。調(diào)用方只需要按照協(xié)議的格式組裝二進(jìn)制的包，然后直接調(diào)用TClient的sendMessage方法就可以把數(shù)據(jù)發(fā)送出去，服務(wù)端處理完成后會異步回調(diào)，將響應(yīng)數(shù)據(jù)返回給客戶端。
腳本寫完了，偽代碼如下
public class Demo{
???????public void invoke(){
??????????????//?創(chuàng)建TClient并初始化
??????????????TClient client = new TClient(xxx);
??????????????//?組裝接口數(shù)據(jù)包
??????????????Data data = new Data(xxx);
??????????????//?發(fā)送數(shù)據(jù)
??????????????Response res = client.sendMessage(data);
??????????????//?檢查結(jié)果、存儲結(jié)果、發(fā)送郵件
??????????????doSomething();
??????????????//?關(guān)閉client
??????????????client.close();
????? }
}
測試腳本中，每隔一分鐘，創(chuàng)建一個(gè)Demo對象，調(diào)用invoke方法
Demo demo = new Demo();
demo.invoke();
腳本寫好后在服務(wù)器上調(diào)試了下，接口返回?cái)?shù)據(jù)正常，于是正式啟動定時(shí)任務(wù)，觀察了一會，運(yùn)行一切正常，Perfect！
第二天早上到公司，登上服務(wù)器，查看昨晚腳本的運(yùn)行情況，看了下日志。
打開日志我就震驚了，What？OutOfMemoryError！竟然內(nèi)存泄漏了！
平常都是開發(fā)寫bug時(shí)出現(xiàn)內(nèi)存泄漏，今天終于輪到我自己了！
最后一條日志顯示為下午17:17左右，也就是腳本大概運(yùn)行了4小時(shí)后出現(xiàn)了內(nèi)存泄漏。查看了下腳本進(jìn)程，果然已經(jīng)崩潰了，并且生成了一個(gè)dump文件。
經(jīng)常做性能測試的同學(xué)，對內(nèi)存泄漏都不陌生。內(nèi)存泄漏總結(jié)來說就是JVM中存儲的對象太多了，占滿了全部內(nèi)存空間，并且這些對象都是不可回收的。這樣程序就不能再繼續(xù)運(yùn)行了，因?yàn)橐呀?jīng)沒有空間了。
舉個(gè)例子，就好像去飯館吃飯，飯館里總是不斷的有人進(jìn)去，也有人出來。如果某天來了一幫人占滿了飯店，并且賴著不走了，這樣新顧客就進(jìn)不來了，這個(gè)時(shí)候估計(jì)老板就崩潰了。
我先review了腳本的代碼，沒發(fā)現(xiàn)什么異常的問題。有的朋友可能會說，你不是每個(gè)1分鐘創(chuàng)建一個(gè)Demo對象嗎，運(yùn)行這么長時(shí)間，會不會是Demo對象太多了？
其實(shí)并不會，寫腳本的時(shí)候也考慮過這個(gè)問題，每次new Demo對象，因?yàn)樯弦淮文_本已經(jīng)執(zhí)行完了，那么上一次的Demo對象就沒有引用了，這樣JVM在垃圾回收的時(shí)候會把上一次的Demo對象清理掉。這樣并不會造成內(nèi)存泄漏。
目光再回到服務(wù)器上，Java進(jìn)程在崩潰時(shí)，自動生成了一個(gè)堆dump文件，如果已經(jīng)發(fā)生了內(nèi)存泄漏，可以分析這個(gè)dump文件，看看里面那些對象比較多，這樣就能確定原因了。
一般在工作中分析內(nèi)存泄漏時(shí)，可以把dump文件下載到本地，然后通過jvisualvm或者jprofiler打開文件，工具自動會分析哪些對象數(shù)量最多。
但是這個(gè)文件有1.3G，公司服務(wù)器下載有限速，想下載下來估計(jì)得等到7月7號testfan性能測試實(shí)戰(zhàn)班開課那天了。
突然想到另外一個(gè)分析內(nèi)存泄漏的工具M(jìn)AT，之前都是在windows下使用MAT，其實(shí)MAT也有Linux版本，可以直接在服務(wù)器上對dump文件進(jìn)行分析。
簡單介紹下工具的使用方法：
1、?登錄官網(wǎng)，下載Linux x86_64/GTK+版本
https://www.eclipse.org/mat/downloads.php
2、?解壓后修改MemoryAnalyzer.ini配置文件，配置jvm參數(shù)（要比dump文件大）
3、?執(zhí)行.mat提供的腳本
./ParseHeapDump.sh /home/xxx.hprof org.eclipse.mat.api:suspects
（/home/xxx.hprof是dump文件的路徑）
4、?在xxx.hprof目錄下，生成了java_pid32523_Leak_Suspects.zip壓縮文件
5、?下載到windows下，解壓，打開index.html
在分析頁面中可以看到，io.netty.channel.nio.NioEventLoopGroup對象占用了JVM中61.36%的空間。其次是io.netty.buffer.PoolThreadCache對象，占用了21.38%。
看名字這倆對象都是netty框架中的類，在網(wǎng)上查了下資料，“NioEventLoopGroup”是netty中的一個(gè)線程池對象。
看頁面上的統(tǒng)計(jì)，JVM中有1145個(gè)netty的線程池對象，這是什么操作？線程池不就一個(gè)就行了嗎？為什么有這么多？
看到線程池對象，就想到會不會JVM線程方面有問題？因?yàn)槟_本進(jìn)程現(xiàn)在已經(jīng)崩潰了，只能重新運(yùn)行腳本，然后再對線程進(jìn)行監(jiān)控。
腳本運(yùn)行過程中，通過監(jiān)控jvm，發(fā)現(xiàn)old區(qū)確實(shí)在不斷的緩慢增加，這樣長時(shí)間跑下去，應(yīng)該就會重現(xiàn)昨天晚上的問題。
執(zhí)行jstack命令打印線程堆棧信息
jstack pid > thread.log
打開thread.log看了下，線程狀態(tài)倒沒啥問題，但是堆棧中有大量的nioEventLoopGroup線程，看編號有1000+，通過命令統(tǒng)計(jì)了下，確實(shí)有1000+個(gè)nioEventLoopGroup線程。
這個(gè)數(shù)量跟上面MAT工具分析的實(shí)例數(shù)量也差不多對應(yīng)上了，現(xiàn)在問題基本上就確定了。也就是說在內(nèi)存泄漏發(fā)生前，JVM中存在1000+個(gè)nioEventLoopGroup線程，每個(gè)線程創(chuàng)建了一個(gè)NioEventLoopGroup對象，因?yàn)榫€程池的特性，所以這些線程處于都是運(yùn)行狀態(tài)的。
并且在腳本運(yùn)行過程中發(fā)現(xiàn)，這個(gè)nioEventLoopGroup線程并不是開始就是1000+，而是從0慢慢漲上來的。也就是說隨著腳本的運(yùn)行，慢慢積累上來的。
這個(gè)時(shí)候目光又回到了我的腳本中，雖然并不是因?yàn)槲也粩嗟膎ew
Demo對象造成了內(nèi)存泄漏，但是肯定跟這個(gè)行為有關(guān)系，nioEventLoopGroup是netty框架用到的對象，于是就想到了代碼中的TClient
client = new TClient(xxx);??
打開TClient的jar包看了下，在TClient的構(gòu)造函數(shù)里，確實(shí)創(chuàng)建了一個(gè)nioEventLoopGroup對象
然后在connect方法中，使用了這個(gè)線程池對象bossGroup
現(xiàn)在基本上確定是什么原因了，如下：
a>???每隔1分鐘，腳本會new一個(gè)Demo對象
b>???Demo對象的invoke方法里又new了一個(gè)TClient對象
c>???TClient對象內(nèi)部在做netty連接初始化的時(shí)候，創(chuàng)建了NioEventLoopGroup線程池對象
雖然腳本中創(chuàng)建的Demo對象和TClient對象都會被JVM回收，但是可能是因?yàn)閚etty使用NioEventLoopGroup線程池和服務(wù)端建立了長連接，導(dǎo)致線程池對象并不會被回收。這樣長時(shí)間跑下來，JVM中中的NioEventLoopGroup對象就會越來越多，最終導(dǎo)致了內(nèi)存泄漏。
這么來看，還真是每次new Demo間接帶來的影響。知道原因就好說了，Demo對象不能在每次運(yùn)行的時(shí)候創(chuàng)建，而且放在類初始化的時(shí)候創(chuàng)建一個(gè)。無論腳本跑多少次，都只有一個(gè)NioEventLoopGroup對象了。
重新修改了下腳本，長時(shí)間運(yùn)行監(jiān)控了下，確實(shí)內(nèi)存使用很穩(wěn)定，沒有出現(xiàn)內(nèi)存泄漏的情況。
問題似乎是得到了解決，但是等等。我腦海中突然又想到另外一個(gè)問題，雖然我在腳本中每次都創(chuàng)建一個(gè)TClient對象，但是每次跑完后，都會調(diào)用TClient的close方法啊，close方法里應(yīng)該會釋放NioEventLoopGroup對象啊，難道沒做嗎？
打開TClient的jar包看了下close方法
在close方法中，確實(shí)把NioEventLoopGroup置為null了，對于一個(gè)普通的對象來說，只要對象引用為null，那么在下次JVM垃圾回收的時(shí)候，就會把這個(gè)對象回收掉。但是對于一個(gè)線程池對象來說，因?yàn)榫€程池中有活動線程存在，所以盡管置為null了，JVM也不會回收這個(gè)線程池。一般的線程池對象，都是通過shutdown方法來銷毀線程池的。
查看了下netty的api文檔，確實(shí)有shutdownGracefully方法（優(yōu)雅關(guān)閉）
現(xiàn)在問題徹底搞清楚了，TClient的close方法中，只是簡單的將線程池對象置為null，并沒有進(jìn)行shutdown操作，因此JVM并不能回收線程池對象。從而造成了，即便用戶調(diào)用了close方法，其實(shí)資源也沒有銷毀，最終自然就會出現(xiàn)內(nèi)存泄漏。
作為一個(gè)通用的工具包，內(nèi)部的資源的釋放，并不能靠調(diào)用者來保證。理論上來說，即便我每次都new TClient對象，只要我都關(guān)閉了。在業(yè)務(wù)層面來說，也是正常行為。不能讓調(diào)用者必須緩存client對象，否則就會出現(xiàn)內(nèi)存泄漏，這樣是不合理的。
在跟相關(guān)開發(fā)溝通后，對代碼做了修改，加上了shutdown方法，仍然用老的腳本進(jìn)行測試，在長時(shí)間的運(yùn)行后，內(nèi)存依然保持正常。因此這個(gè)問題終于解決了。
最后總結(jié)一下
1、?此問題的根本原因是client包中close方法沒有成功銷毀資源
2、?理論上來說，重復(fù)創(chuàng)建大量對象并不會造成內(nèi)存泄漏，但是如果代碼中同時(shí)也創(chuàng)建了第三方包的對象，在不了解其實(shí)現(xiàn)細(xì)節(jié)的情況了，可能其內(nèi)部會創(chuàng)建一些不可被回收的對象，這個(gè)時(shí)候就會有內(nèi)存泄漏的風(fēng)險(xiǎn)。因此還是盡量的復(fù)用對象，減少內(nèi)存泄漏問題的發(fā)生。
作 者：Testfan 北河
出 處：微信公眾號：自動化軟件測試平臺
版權(quán)說明：歡迎轉(zhuǎn)載，但必須注明出處，并在文章頁面明顯位置給出文章鏈接
