共计 4530 个字符，预计需要花费 12 分钟才能阅读完成。
一：背景
1. 讲故事
我在年前写过一篇对于 CPU 爆高的剖析文章 再记一次 应用服务器 CPU 暴高事变剖析，过后是给同济做我的项目降级，看过那篇文章的敌人应该晓得，最初的论断是运维人员谬误的将 IIS 应用程序池设成 32bit 导致了事变的产生，这篇算是后续😂😂😂，拖了良久才续上哈。
犹记得那些天老板天天找咱们几个人散会，大略老板是在传导甲方给过去的压力，人晦气就是这样，你说 CPU 爆高可怕吧，我硬是给摁上来了，好了，Memory 又爆高了，尼玛我又给摁上来了，接着数据库死锁又来了，你能领会到这种压力吗？🤣 就像我在朋友圈发的那样，程序再不跑我就要跑了。
所以有时候敬敬风水还是很有必要的，有点扯远了哈，这篇咱们来看看程序的内存暴涨如何去排查，为了让你更有趣味，来一张运维发的内存监控图。
从图中能够看出，9 点开始内存直线暴涨，相对触目惊心，要是我的小诺安这样暴涨就好了🤑🤑🤑，接下来 windbg 谈话。
二：windbg 剖析
1. 说一下思路
内存暴涨了，最怕的就是 非托管层 出了问题，它的排查难度相比 托管层 要难 10 倍以上，所以遇到这类问题，先祷告一下吧，gc 堆也罢，loader 堆也不怕，所以先看看是否 过程内存 ≈ gc 堆内存 ?
2. 排查托管还是非托管
排查形式也很简略，通过 !address -summary 看看过程的已提交内存，如下输入：
0:000> !address -summary
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 261 7fb`4b151000 (7.982 TB) 99.77%
MEM_RESERVE 278 2`6aafc000 (9.667 GB) 51.35% 0.12%
MEM_COMMIT 2199 2`4a3a3000 (9.160 GB) 48.65% 0.11%
能够看到已提交内存是 9.1G，接下来看下 gc 堆的大小，应用 !eeheap -gc 即可。
0:000> !eeheap -gc
Number of GC Heaps: 8
------------------------------
Heap 0 (0000000002607740)
generation 0 starts at 0x00000001aaaa5500
generation 1 starts at 0x00000001aa3fd070
generation 2 starts at 0x0000000180021000
Heap 7 (0000000002713b40)
generation 0 starts at 0x000000053b3a2c28
generation 1 starts at 0x000000053a3fa770
generation 2 starts at 0x0000000500021000
------------------------------
GC Heap Size: Size: 0x1fdfe58c8 (8556271816) bytes.
从最初一行输入中能够看到以后的占用是 8556271816 / 1024 /1024 /1024 = 7.9G，太侥幸了，果然是托管层出了问题，gc 上有大块脏东西，这下没救了 😁😁😁。
3. 查看托管堆
晓得托管堆出了问题后，接下来就能够用 !dumpheap -stat 去 gc 堆上翻一翻。
0:000> !dumpheap -stat
Statistics:
MT Count TotalSize Class Name
000007fef7b5c308 32867 788808 System.DateTime
000007fef7b5e598 33049 793176 System.Boolean
000007feec7301f8 30430 1217200 System.Web.HttpResponseUnmanagedBufferElement
000007fef7b56020 2931 3130928 System.Object[]
000007fef7b580f8 219398 5265552 System.Int32
000007fe9a0c5428 46423 7799064 xxx.Laundry.Entities.V_InvoiceInfo
000007fef7b59638 164418 7892064 System.Text.StringBuilder
000007fef7b56980 164713 10059852 System.Char[]
000007fef7b5a278 7351 26037217 System.Byte[]
000007fe9a0d8758 35 28326856 xxx.Laundry.Entities.V_ClothesTagInfo[]
0000000002536f50 76837 77016088 Free
000007fe9a327ab0 46534 312964608 xxx.Laundry.Entities.V_InvoiceClothesInfo[]
000007fe9a0c4868 2068912 397231104 xxx.Laundry.Entities.V_ClothesTagInfo
000007fef7b55b70 98986851 3483764540 System.String
000007fe9a10ef80 23998759 3839801440 xxx.Laundry.Entities.V_InvoiceClothesInfo
Total 126039641 objects
我去，托管堆上的 xxx.Laundry.Entities.V_InvoiceClothesInfo 对象竟然高达 2399w，占了大略 3.6G，这还不算其从属对象，对了，如果间接用 !dumpheap -mt xxx 输入 address 的话，很难进行 UI 停止，所以这里有一个小技巧，用 range 来限定一下，如下代码所示：
0:000> !dumpheap -mt 000007fe9a10ef80 0 0000000180027b30
Address MT Size
0000000180027800 000007fe9a10ef80 160
0000000180027910 000007fe9a10ef80 160
0000000180027a20 000007fe9a10ef80 160
0000000180027b30 000007fe9a10ef80 160
Statistics:
MT Count TotalSize Class Name
000007fe9a10ef80 4 640 xxx.Laundry.Entities.V_InvoiceClothesInfo
Total 4 objects
4. 查找援用根
接下来用 !gcroot 轻易找一个 address 查看它的援用链，看看它到底被谁援用着？
0:000> !gcroot 0000000180027800
HandleTable:
00000000013715e8 (pinned handle)
-> 000000058003c038 System.Object[]
-> 00000004800238a0 System.Collections.Generic.List`1[[xxx.Laundry.APIService.Models.Common.BaseModel, xxx.Laundry.APIService]]
-> 0000000317e01ae0 xxx.Laundry.APIService.Models.Common.BaseModel[]
-> 000000028010caf0 xxx.Laundry.APIService.Models.Common.BaseModel
-> 00000003014cbbd0 System.Collections.Generic.List`1[[xxx.Laundry.Entities.V_InvoiceInfo, xxx.Laundry.Entities]]
-> 00000003014f3580 xxx.Laundry.Entities.V_InvoiceInfo[]
-> 00000003014cd7f0 xxx.Laundry.Entities.V_InvoiceInfo
-> 000000038cc49bf0 System.Collections.Generic.List`1[[xxx.Laundry.Entities.V_InvoiceClothesInfo, xxx.Laundry.Entities]]
-> 000000038cc49c18 xxx.Laundry.Entities.V_InvoiceClothesInfo[]
-> 0000000180027800 xxx.Laundry.Entities.V_InvoiceClothesInfo
Found 1 unique roots (run '!GCRoot -all' to see all roots).
从输入中能够看到，它貌似被一个 List<BaseModel> 所持有，哈哈，总算找到了，接下来就简略了，间接用 !objsize 看一看它的 size 有多大？
0:000> !objsize 00000004800238a0
sizeof(00000004800238a0) = -1972395312 (0x8a6fa2d0) bytes (System.Collections.Generic.List`1[[xxx.Laundry.APIService.Models.Common.BaseModel, xxx.Laundry.APIService]])
看到下面的 -1972395312 了吗？我去，int 类型的 size 间接给爆掉了，果然是个大对象，就是你了。。。如果非要看大小也能够，写一个脚本遍历一下。
三：总结
晓得是 List<BaseModel> 做的孽后，仔细阅读了源码才晓得，原来是给用户第一次数据全量同步的时候，服务端为了减速将数据缓存在 List<BaseModel> 这个动态变量中，很遗憾的是并没有在适合的机会进行开释，造成了高峰期内存直线暴增，优化计划很简略，就是批改业务逻辑咯，减少开释内存的机会。
题外话
- 如果你遇到的是这种
Strong Handles的动态变量，也能够间接用可视化的 dotMemory 查看。
当然你要保障你有足够的内存，毕竟也算是小 10G 的 dump 🤣，我的 16G 内存一下子就被吃掉了。。。
- 长于用 String 驻留池机制来优化，看看它的源码定义吧。
public sealed class String
{[SecuritySafeCritical]
public static string Intern(string str)
{if (str == null)
{throw new ArgumentNullException("str");
}
return Thread.GetDomain().GetOrInternString(str);
}
}
对于那些反复度很高的 string，用驻留池机制能够节俭千百倍的内存空间，至于为什么能够优化，可参考我之前的文章：字符串太占内存了，我想了各种奇思淫巧对它进行压缩
更多高质量干货：参见我的 GitHub: dotnetfly
