## 一：背景 ### 1. 講故事 前幾天有位朋友找到我，說他們公司的後端服務記憶體暴漲，而且CPU的一個核也被打滿，讓我幫忙看下怎麼回事，一般來說記憶體暴漲的問題都比較好解決，就讓朋友抓一個 dump 丟過來，接下來我們用 WinDbg 一探究竟。 ## 二：WinDbg 分析 ### 1. 到底是 ...
一：背景
1. 講故事
前幾天有位朋友找到我，說他們公司的後端服務記憶體暴漲，而且CPU的一個核也被打滿，讓我幫忙看下怎麼回事，一般來說記憶體暴漲的問題都比較好解決，就讓朋友抓一個 dump 丟過來，接下來我們用 WinDbg 一探究竟。
二：WinDbg 分析
1. 到底是誰在暴漲
拿到 dump 之後，首先要判斷是托管還是非托管問題，這決定了我們後續的探究方向，我們直接用 !address -summary + !dumpheap -stat 即可。
0:000> !address -summary
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 212 7dfe`fb4e7000 ( 125.996 TB) 98.43%
MEM_RESERVE 368 200`1dbd6000 ( 2.000 TB) 99.82% 1.56%
MEM_COMMIT 1741 0`e6f33000 ( 3.609 GB) 0.18% 0.00%
0:000> !dumpheap -stat
Statistics:
MT Count TotalSize Class Name
...
7ff9858ad8e0 409,869 258,383,328 System.Collections.Generic.Dictionary<System.Int64, xxx.xxx>+Entry[]
0225cc98e1f0 283,654 479,330,568 Free
7ff9858ab160 8 2,147,484,480 xxx.xxxUnit[]
0:000> !dumpheap -mt 7ff9858ab160
Address MT Size
022585dd26b8 7ff9858ab160 24
02258beb3c78 7ff9858ab160 24
02259f272aa8 7ff9858ab160 152
0225a8ae0858 7ff9858ab160 152
0225a8d015c8 7ff9858ab160 152
0225a91da130 7ff9858ab160 152
0225a9395ad0 7ff9858ab160 152
022694c91020 7ff9858ab160 2,147,483,672
Statistics:
MT Count TotalSize Class Name
7ff9858ab160 8 2,147,484,480 xxx.xxxUnit[]
Total 8 objects, 2,147,484,480 bytes
從卦象看，3.6G 的提交記憶體，xxx.xxxUnit[] 就占用了 2.1G，可以確定當前是托管記憶體暴漲，並且也看到了記憶體都被 022694c91020 這個對象給吃掉了，接下來就是看下這個對象到底被誰持有著？ 使用 !gcroot 即可。
0:000> !gcroot 022694c91020
Caching GC roots, this may take a while.
Subsequent runs of this command will be faster.
Found 0 unique roots.
我去，從卦中看當前的 022694c91020 沒有引用根，也就表明這個對象應該會在後續過程中被回收，但這裡有一個問題，這個 xxx.xxxUnit[] 到底定義在代碼何處呢？ 知道在何處，就可以完美的解決問題。
2. 數組到底定義在何處
可以仔細想一想，xxx.xxxUnit[] 沒有被 GC 回收，從側面也表明它可能剛分配不久，並且是一個局部變數，既然是局部變數，就可以反向找到是哪一個線程分配的，如果線程棧還殘留著 返回地址 信息，就可以反推出是哪一個方法，有了這個思路，接下來就可以動手挖了。
按照編碼人的習慣， xxx.xxxUnit[] 肯定是某一個 List<xxxUnit> 集合，可以用記憶體搜索解決。
0:000> s-q 0 L?0xffffffffffffffff 022694c91020
00000225`a89530a0 00000226`94c91020 0cca3690`0cca3690
0:000> !lno 00000225`a89530a0
Before: 00000225a8953098 32 (0x20) System.Collections.Generic.List`1[[xxx.xxxUnit, xx.xx]]
After: 00000225a89530b8 1224 (0x4c8) Free
Heap local consistency confirmed.
從卦中看，果然用的是一個 List<xxx.xxxUnit> 集合，萬事開頭難，接下來繼續反向搜索，如果線程棧還有殘留的話，就可以找到它所屬的線程棧。
0:000> s-q 0 L?0xffffffffffffffff 00000225a8953098
0000004c`417ecd98 00000225`a8953098 00000005`00000000
0000004c`417eceb8 00000225`a8953098 0cca3695`00000000
00000225`f1070180 00000225`a8953098 00000225`d7d287f8
00000225`f10701e0 00000225`a8953098 00000225`d7d287f8
0:000> !address 0000004c`417ecd98
Usage: Stack
Base Address: 0000004c`417d1000
End Address: 0000004c`417f0000
Region Size: 00000000`0001f000 ( 124.000 kB)
State: 00001000 MEM_COMMIT
Protect: 00000004 PAGE_READWRITE
Type: 00020000 MEM_PRIVATE
Allocation Base: 0000004c`41670000
Allocation Protect: 00000004 PAGE_READWRITE
More info: ~0k
Content source: 1 (target), length: 3268
從卦中的 More info: 信息來看，它是屬於 0 號線程，如果你不相信的話，可以拿 417d1000 去記憶體段驗證下，輸出如下：
0:000> !address -f:Stack
BaseAddress EndAddress+1 RegionSize Type State Protect Usage
--------------------------------------------------------------------------------------------------------------------------
4c`41670000 4c`417cc000 0`0015c000 MEM_PRIVATE MEM_RESERVE Stack [~0; ec8.1584]
4c`417cc000 4c`417d1000 0`00005000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE | PAGE_GUARD Stack [~0; ec8.1584]
4c`417d1000 4c`417f0000 0`0001f000 MEM_PRIVATE MEM_COMMIT PAGE_READWRITE Stack [~0; ec8.1584]
既然找到了是 0 號線程，接下來可以用 !clrstack 觀察下，奇怪的是 0 號線程啥都沒有，我懷疑這個 dump 抓的有問題，可以截圖為證。
看不到任何線程棧信息，這就難搞了，接下來的路在何方呢？
3. 還有希望嗎
作為調試人，一定要在絕望中尋找希望，突破口就是考驗線程棧佈局的理解，可以在棧上往小地址找，會找到子函數的返回地址(returnAddress)，即類似的格式： 0x00007ffxxxxxx，這個地址和 List<xxx.xxxUnit> 都同屬一個方法，如果不清楚的話畫個簡圖如下：
如圖中所述找到 子方法 ReturnAddress 地址值即可，接下來使用windbg 的 dqs 命令外加 !ip2md 觀察方法名即可。
0:000> dqs 0000004c`417ecd98 L-50
0000004c`417ecb18 0000004c`417ed678
0000004c`417ecb20 00000225`b9e78518
0000004c`417ecb28 00007ff9`85f3f861
0000004c`417ecb30 00000225`ba22b8c0
0000004c`417ecb38 0000001a`00000027
0000004c`417ecb40 00000225`00000027
0000004c`417ecb48 00000225`84aef0f8
...
0000004c`417ecd88 0000001a`00000000
0000004c`417ecd90 00000225`82278a68
0:000> !ip2md 00007ff9`85f3f861
MethodDesc: 00007ff983ef1af0
Method Name: xxx.xxx.xxxRange(xxx,xxx,xxx,xxx)
Class: 00007ff983ef1a58
MethodTable: 00007ff983ef1b70
mdToken: 0000000006000A47
Module: 00007ff983d9c060
IsJitted: yes
Current CodeAddr: 00007ff985f3f160
Version History:
ILCodeVersion: 0000000000000000
ReJIT ID: 0
IL Addr: 00000225ef226c48
CodeAddr: 00007ff985f3f160 (MinOptJitted)
NativeCodeVersion: 0000000000000000
在卦中獲取到這些信息之後，接下來看下 xxx.xxx.xxxRange 中是否有 List<xxxUnit> 集合，為什麼高達 2個G，經過仔細研讀代碼，終於發現了問題，截圖如下：
從圖中看，核心點就是這裡的 num++，在某些情況下會導致在 for 中出不來繼而不斷的 List.Add ，最終導致問題的發生。
再回頭結合朋友說的記憶體暴漲，伴隨一個 CPU 核心被打滿，完全就可以解釋了。
三：總結
這是一個比較隱晦的邏輯bug導致的記憶體暴漲,如果僅僅從代碼層面去分析，相信你可能要花費好久的時間，從高級調試的角度看，在 List 無根的情況下如何快速的找到 List 所屬的代碼塊，也是對基礎知識的一個考驗。
