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

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

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

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

1。首先對(duì)程序的運(yùn)行有個(gè)大概的了解。（比如說 程序運(yùn)行了多長時(shí)間，內(nèi)存多大）

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

打開windbg，打開dump,呃，程序運(yùn)行了2個(gè)半小時(shí)。

設(shè)置上符號(hào)地址，然后加載sos

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

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

***個(gè)命令  !EEHeap -GC

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

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

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

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

于是 第三個(gè)命令 !Dumpheap -mt 00000644803111a0   

5。找到其中一個(gè)對(duì)象，看看是因?yàn)檎l的引用而沒有釋放（!gcroot +對(duì)象地址 這個(gè)命令就可以得到這個(gè)對(duì)象的“根”，這個(gè)過程會(huì)非常長，具體講該命令將會(huì)遍歷所有的根，我們看到Scan Thread 67 實(shí)際上就是在掃描67號(hào)線程的線程Stack是不是引用了該對(duì)象。）

額，這么多，隨便找一個(gè)，就找***一個(gè)吧，第四個(gè)命令 !gcroot 00000001677ceda8，這個(gè)時(shí)候該去廁所抽支煙....

6。我們找到了“罪魁禍?zhǔn)?rdquo;的對(duì)象，一般我們看看代碼就OK了。（這里閑的無聊的話我們可以看看這個(gè)對(duì)象到底占了多大的內(nèi)存，!objsize +對(duì)象地址，我們就看到了，這個(gè)命令時(shí)間非常長，長到你可以蹲著抽煙)

額，看到根了，SingallingContextTracer，這個(gè)東西是個(gè)跟蹤器，不會(huì)是跟蹤器沒有釋放吧？？先不管，看看多大，第五個(gè)命令 !objsize 00000000c1707658 

打開代碼，找到SingallingContextTracer，呃，這個(gè)可憐的家伙把每個(gè)Context放到自己的Queue中，然后開啟另外的線程來處理，可惜處理線程被誰注釋掉了（跟蹤功能因?yàn)闆]啥用處，被去掉了，但是去掉了應(yīng)該不讓入隊(duì)啊），好吧，趕緊修改代碼，重新部署......

原文鏈接：http://www.cnblogs.com/StevenChennet/archive/2012/07/24/2606780.html

【編輯推薦】