首先介紹一下程序，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。首先對程序的運(yùn)行有個大概的了解。（比如說 程序運(yùn)行了多長時間，內(nèi)存多大）

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

打開windbg，打開dump,呃，程序運(yùn)行了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。找到其中一個對象，看看是因?yàn)檎l的引用而沒有釋放（!gcroot +對象地址 這個命令就可以得到這個對象的“根”，這個過程會非常長，具體講該命令將會遍歷所有的根，我們看到Scan Thread 67 實(shí)際上就是在掃描67號線程的線程Stack是不是引用了該對象。）

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

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

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

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

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

【編輯推薦】