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

這是我接手這個程序之后的一些Bug的發現和修改，把他記錄下來，以做茶余飯后的談資。

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

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

1。首先對程序的運行有個大概的了解。（比如說 程序運行了多長時間，內存多大）

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

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

設置上符號地址，然后加載sos

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

***一行GC Heap Size是1.2G，1.8G的內存，GC堆1.2G，肯定有問題了，當然，Loader堆也不大可能有600M，以后我會對Loader堆繼續分析。。。）

***個命令  !EEHeap -GC

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

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

看到一個很熟悉的名字 “SingallingContext”，這是一個Context，這個Context是接收到數據之后包裝一下經過業務的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。我們找到了“罪魁禍首”的對象，一般我們看看代碼就OK了。（這里閑的無聊的話我們可以看看這個對象到底占了多大的內存，!objsize +對象地址，我們就看到了，這個命令時間非常長，長到你可以蹲著抽煙)

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

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

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

【編輯推薦】