日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間:8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
捉蟲記(一)GC堆中的“內(nèi)存泄漏”

首先介紹一下程序,Server程序,同時有好多Client連接,Client用tcpSocket發(fā)送數(shù)據(jù)給Server,Server對數(shù)據(jù)進(jìn)行處理并返回處理結(jié)果給Client。雖然整個程序的開發(fā)時間很長,但中間不停的需求變更,功能不停地增加減少,代碼也是好多人,每人幾個模塊甚至是幾個函數(shù)雜湊起來,系統(tǒng)正在被使用,功能也不斷被增加,總之......是一個SHZY初級階段特色的絕對代表的Server程序。

這是我接手這個程序之后的一些Bug的發(fā)現(xiàn)和修改,把他記錄下來,以做茶余飯后的談資。

對于這種要文檔沒文檔、要規(guī)范沒規(guī)范程序,要在一邊添加新功能,一邊發(fā)現(xiàn)和修改bug是極其困難的,如果沒有一些大殺器,不太好搞,而一但有了一些大殺器,對于有些問題的發(fā)現(xiàn)以及解決又簡單到令人發(fā)指,WinDbg就是這樣一種大殺器。

程序一天部署好幾次,沒辦法,bug太多了,催的又急,每次修改一下就趕緊部署了,某天突然有個經(jīng)理電話里喊道,你這程序內(nèi)存怎么越用越大,幸好我早有防備,呃,經(jīng)理,先別著急,請雙擊一下桌面的“Server.Bat”,然后重新啟動一下程序(重新啟動一下內(nèi)存就小了哈)。

1。首先對程序的運行有個大概的了解。(比如說 程序運行了多長時間,內(nèi)存多大)

登到服務(wù)器上一看,我的天, dump文件1.8G---程序大概是2個小時之前部署

打開windbg,打開dump,呃,程序運行了2個半小時。

設(shè)置上符號地址,然后加載sos

2。查看GC堆上的內(nèi)存占用是多大。(一般來講,內(nèi)存泄露都是GC堆上的問題,也就是說new了一些對象在某些情況下沒有釋放,!EEHeap -GC 正是查看GC堆得命令,我們看到

***一行GC Heap Size是1.2G,1.8G的內(nèi)存,GC堆1.2G,肯定有問題了,當(dāng)然,Loader堆也不大可能有600M,以后我會對Loader堆繼續(xù)分析。。。)

***個命令  !EEHeap -GC

3。確定是GC堆的問題,就看看GC堆上存活的對象是那些。(!dumpheap -stat 就是GC堆上的統(tǒng)計,我們看到統(tǒng)計結(jié)果,***行SingnallingContex,  00000644803111a0  是該對象的MethondTable的地址,而186402是該對象在內(nèi)存中的個數(shù),35789184是大小,這是純凈的大小,該對象里面所包含的對象的大小不算在內(nèi),看到Context相關(guān)聯(lián)的ProcessDetail竟然有5325513個,所占字節(jié)為488804488,這足夠驚人了。。。)

呃,看到這里都能猜想到,Loader堆里肯定有很多垃圾,先不管這么多了[我會在后續(xù)中介紹Loader堆里面的事情],先看看GC堆里有什么,第二個命令!DumpHeap -stat。

看到一個很熟悉的名字 “SingallingContext”,這是一個Context,這個Context是接收到數(shù)據(jù)之后包裝一下經(jīng)過業(yè)務(wù)的pipfilter。1W多個,而Context上多呆的ProcessDetail竟然到了百萬,猜測是某個處理Module緩存住了,沒有釋放。

4。確定了是哪種類型對象的問題,那就看看該對象。( !Dumpheap -mt 00000644803111a0  你也可以用 !Dumpheap -type SingnallingContex 這個命令)

于是 第三個命令 !Dumpheap -mt 00000644803111a0

5。找到其中一個對象,看看是因為誰的引用而沒有釋放(!gcroot +對象地址 這個命令就可以得到這個對象的“根”,這個過程會非常長,具體講該命令將會遍歷所有的根,我們看到Scan Thread 67 實際上就是在掃描67號線程的線程Stack是不是引用了該對象。)

額,這么多,隨便找一個,就找***一個吧,第四個命令 !gcroot 00000001677ceda8,這個時候該去廁所抽支煙....

6。我們找到了“罪魁禍?zhǔn)住钡膶ο螅话阄覀兛纯创a就OK了。(這里閑的無聊的話我們可以看看這個對象到底占了多大的內(nèi)存,!objsize +對象地址,我們就看到了,這個命令時間非常長,長到你可以蹲著抽煙)

額,看到根了,SingallingContextTracer,這個東西是個跟蹤器,不會是跟蹤器沒有釋放吧??先不管,看看多大,第五個命令 !objsize 00000000c1707658

打開代碼,找到SingallingContextTracer,呃,這個可憐的家伙把每個Context放到自己的Queue中,然后開啟另外的線程來處理,可惜處理線程被誰注釋掉了(跟蹤功能因為沒啥用處,被去掉了,但是去掉了應(yīng)該不讓入隊?。冒?,趕緊修改代碼,重新部署......


網(wǎng)站名稱:捉蟲記(一)GC堆中的“內(nèi)存泄漏”
網(wǎng)站路徑:http://www.dlmjj.cn/article/dhiidjj.html