一：背景

1. 講故事

前幾天有位朋友找到我，說他們公司的后端服務(wù)內(nèi)存暴漲，而且CPU的一個(gè)核也被打滿，讓我?guī)兔聪略趺椿厥?，一般來說內(nèi)存暴漲的問題都比較好解決，就讓朋友抓一個(gè) dump 丟過來，接下來我們用 WinDbg 一探究竟。

二：WinDbg 分析

1. 到底是誰在暴漲

拿到 dump 之后，首先要判斷是托管還是非托管問題，這決定了我們后續(xù)的探究方向，我們直接用?!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 Free7ff9858ab160 ? ? ? ? 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 Name7ff9858ab160 ? ? 8 2,147,484,480 xxx.xxxUnit[] Total 8 objects, 2,147,484,480 bytes

從卦象看，3.6G?的提交內(nèi)存，xxx.xxxUnit[]?就占用了?2.1G，可以確定當(dāng)前是托管內(nèi)存暴漲，并且也看到了內(nèi)存都被?022694c91020?這個(gè)對象給吃掉了，接下來就是看下這個(gè)對象到底被誰持有著？ 使用?!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.

我去，從卦中看當(dāng)前的?022694c91020?沒有引用根，也就表明這個(gè)對象應(yīng)該會(huì)在后續(xù)過程中被回收，但這里有一個(gè)問題，這個(gè)?xxx.xxxUnit[]?到底定義在代碼何處呢？ 知道在何處，就可以完美的解決問題。

2. 數(shù)組到底定義在何處

可以仔細(xì)想一想，xxx.xxxUnit[]?沒有被 GC 回收，從側(cè)面也表明它可能剛分配不久，并且是一個(gè)局部變量，既然是局部變量，就可以反向找到是哪一個(gè)線程分配的，如果線程棧還殘留著?返回地址?信息，就可以反推出是哪一個(gè)方法，有了這個(gè)思路，接下來就可以動(dòng)手挖了。

按照編碼人的習(xí)慣，?xxx.xxxUnit[]?肯定是某一個(gè)?List<xxxUnit>?集合，可以用內(nèi)存搜索解決。

0:000> s-q 0 L?0xffffffffffffffff 022694c9102000000225`a89530a0 ?00000226`94c91020 0cca3690`0cca36900: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.

從卦中看，果然用的是一個(gè)?List<xxx.xxxUnit>?集合，萬事開頭難，接下來繼續(xù)反向搜索，如果線程棧還有殘留的話，就可以找到它所屬的線程棧。

0:000> s-q 0 L?0xffffffffffffffff 00000225a89530980000004c`417ecd98 ?00000225`a8953098 00000005`000000000000004c`417eceb8 ?00000225`a8953098 0cca3695`0000000000000225`f1070180 ?00000225`a8953098 00000225`d7d287f800000225`f10701e0 ?00000225`a8953098 00000225`d7d287f80: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`41670000Allocation Protect: ? ? 00000004 ? ? ? ? ?PAGE_READWRITE More info: ? ? ? ? ? ? ?~0k Content source: 1 (target), length: 3268

從卦中的?More info:?信息來看，它是屬于?0?號線程，如果你不相信的話，可以拿?417d1000?去內(nèi)存段驗(yàn)證下，輸出如下：

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 號線程啥都沒有，我懷疑這個(gè) dump 抓的有問題，可以截圖為證。

看不到任何線程棧信息，這就難搞了，接下來的路在何方呢？

3. 還有希望嗎

作為調(diào)試人，一定要在絕望中尋找希望，突破口就是考驗(yàn)線程棧布局的理解，可以在棧上往小地址找，會(huì)找到子函數(shù)的返回地址(returnAddress)，即類似的格式：?0x00007ffxxxxxx，這個(gè)地址和?List<xxx.xxxUnit>?都同屬一個(gè)方法，如果不清楚的話畫個(gè)簡圖如下：

如圖中所述找到?子方法 ReturnAddress?地址值即可，接下來使用windbg 的?dqs?命令外加?!ip2md?觀察方法名即可。

0:000> dqs 0000004c`417ecd98 L-500000004c`417ecb18 ?0000004c`417ed6780000004c`417ecb20 ?00000225`b9e785180000004c`417ecb28 ?00007ff9`85f3f8610000004c`417ecb30 ?00000225`ba22b8c00000004c`417ecb38 ?0000001a`000000270000004c`417ecb40 ?00000225`000000270000004c`417ecb48 ?00000225`84aef0f8 ...0000004c`417ecd88 ?0000001a`000000000000004c`417ecd90 ?00000225`82278a680: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>?集合，為什么高達(dá) 2個(gè)G，經(jīng)過仔細(xì)研讀代碼，終于發(fā)現(xiàn)了問題，截圖如下：

從圖中看，核心點(diǎn)就是這里的?num++，在某些情況下會(huì)導(dǎo)致在 for 中出不來繼而不斷的 List.Add ，最終導(dǎo)致問題的發(fā)生。

再回頭結(jié)合朋友說的內(nèi)存暴漲，伴隨一個(gè) CPU 核心被打滿，完全就可以解釋了。

三：總結(jié)

這是一個(gè)比較隱晦的邏輯bug導(dǎo)致的內(nèi)存暴漲,如果僅僅從代碼層面去分析，相信你可能要花費(fèi)好久的時(shí)間，從高級調(diào)試的角度看，在 List 無根的情況下如何快速的找到 List 所屬的代碼塊，也是對基礎(chǔ)知識的一個(gè)考驗(yàn)。