记一次 .NET 某智慧医保云服务Linux 非托管泄露分析

一：背景

1. 讲故事

说来也奇怪，最近分析了好几例内存暴涨事故，这不又来了，哈哈，今天再给大家带来一份非托管内存泄露导致的程序生产故障，而且是部署在Linux上.NET程序。

前些天有位朋友找到我，自己有一定的分析能力，发现程序是非托管内存泄露，但能力有限暂时也不知道怎么弄，让我帮忙看下，把dump也丢给我了，既然dump有了，那就开始分析吧。

二：内存暴涨分析

1. 为什么会暴涨

虽然朋友说了是非托管内存泄露，但我们还是要相信数据，使用 !maddress 观察即可。

0:000> !maddress +-------------------------------------------------------------------------+  | Memory Type            |          Count |         Size |   Size (bytes) |  +-------------------------------------------------------------------------+  | PAGE_READWRITE         |          2,465 |       3.64gb |  3,913,596,928 |  | GCHeap                 |              9 |       1.45gb |  1,557,557,248 |  | Stack                  |             63 |     972.26mb |  1,019,490,304 |  | Image                  |          1,413 |     287.81mb |    301,786,112 |  | HighFrequencyHeap      |          1,722 |     107.54mb |    112,758,784 |  | LowFrequencyHeap       |            903 |      66.32mb |     69,545,984 |  | LoaderCodeHeap         |             35 |      61.00mb |     63,963,136 |  | HostCodeHeap           |             85 |      19.97mb |     20,942,848 |  | ResolveHeap            |              3 |       1.09mb |      1,142,784 |  | IndirectionCellHeap    |              9 |     536.00kb |        548,864 |  | StubHeap               |              8 |     460.00kb |        471,040 |  | DispatchHeap           |              2 |     452.00kb |        462,848 |  | CacheEntryHeap         |              7 |     420.00kb |        430,080 |  | LookupHeap             |              5 |     272.00kb |        278,528 |  | PAGE_READONLY          |            125 |     263.00kb |        269,312 |  | PAGE_EXECUTE_WRITECOPY |              6 |     232.00kb |        237,568 |  | PAGE_EXECUTE_READ      |              2 |       8.00kb |          8,192 |  +-------------------------------------------------------------------------+  | [TOTAL]                |          6,862 |       6.58gb |  7,063,490,560 |  +-------------------------------------------------------------------------+ 

从卦中我们看到程序总计吃了 6.58G 内存，其中 PAGE_READWRITE = 3.64G，很显然这是赤裸裸的非托管内存泄露，说实话Linux上的非托管内存泄露不是很好弄，接下来我们的研究方向在哪里呢？

在如今AI横行的时代，可以用一个小技巧，那就是用AI将 2465个 PAGE_READWRITE 做一个 groupby 操作，寻找size的特征，这里取 top5 的记录，截图如下：

从卦中可以清晰的看到，主体上是被 50~200MB 这个区间吃掉了，接下来我们随便挑选几个观察其中内容，截图如下：

从卦中可以看到大量的 lambda_methodxxx 的字样，看起来和动态代码生成有关系，但还不是那么清晰。

2. lambda_method 为啥这么多

不管怎么说，数字这么大了，冥冥之中应该是一种失控，熟悉C# 的朋友应该知道这个应该是 C# 通过 DynamicMethod 类似的机制动态生成的方法，所以我们的接下来的注意力应该投向托管堆了，使用 !dumpheap -stat 观察托管堆。

0:000> !dumpheap -stat...7f6cee5e6360   105,28810,949,952 System.Reflection.RuntimeMethodInfo7f6cf0943da8    81,26111,701,584 System.Reflection.Emit.DynamicILGenerator7f6cfc273e40     1,42811,732,448 IndexItem[]7f6cf883b510    13,18912,785,440 System.Collections.Concurrent.ConcurrentDictionary<System.String, System.Object>+Node[]7f6cf9c3aaa0   132,06313,734,552 OracleInternal.Common.ColumnDescribeInfo7f6cfa1f54b0    20,42416,314,756 Oracle.ManagedDataAccess.Client.OracleParameterStatus[]7f6cf97f7cb8    55,84428,145,376 Oracle.ManagedDataAccess.Client.OracleConnection7f6ceed94548    21,31032,195,096 System.Byte[][]7f6cedb852a8 1,445,51634,692,384 System.Object7f6cff21ea98   728,16240,777,072 SkiaSharp.SKString7f6cf561ca90 1,343,65042,996,800 Microsoft.Win32.SafeHandles.SafeEvpCipherCtxHandle7f6cedb8b110   144,68554,552,728 System.Object[]7f6cf0cd1110 1,878,51160,112,352 Microsoft.Win32.SafeHandles.SafeWaitHandle55ad23d21ab0    58,64870,742,904 Free7f6cedc38080   141,177100,202,360 System.Int32[]7f6cedc3d2e0 2,827,739188,196,546 System.String7f6cee5ea3a0 3,787,714280,567,631 System.Byte[]Total 18,171,140 objects, 1,533,484,720 bytesFragmented blocks larger than 0.5 MB:         Address           Size      Followed By7f6a1d47cb18      3,359,3447f6a1d7b0d88 System.Byte[]7f6a1d81c080      1,151,4087f6a1d935230 System.IO.Compression.ZLibNative+ZLibStreamHandle

看到卦中的 DynamicILGenerator=10.5w 的时候，猜想再次被印证，看样子非托管内存中都是它投放的，接下来观察 DynamicILGenerator 的引用根看看到底咋回事。

0:000> !dumpheap -mt 7f6cf0943da8         Address               MT           Size         ...7f6cc7f7a3f0     7f6cf0943da8            1447f6cc7f81168     7f6cf0943da8            1447f6cc7f81598     7f6cf0943da8            1447f6cc7f81988     7f6cf0943da8            1447f6cc7f83308     7f6cf0943da8            1447f6cc7f83ff8     7f6cf0943da8            1447f6cc7f8ceb8     7f6cf0943da8            144Statistics:          MT  Count  TotalSize Class Name7f6cf0943da8 81,26111,701,584 System.Reflection.Emit.DynamicILGeneratorTotal 81,261 objects, 11,701,584 bytes0:000> !gcroot 7f6cc7f7a3f0Found 0 unique roots.0:000> !gcroot  7f6b67d00990Found 0 unique roots.0:000> !gcroot 7f6cc7f83ff8Found 0 unique roots.

从卦中看，比较奇怪的是为什么这几个 DynamicILGenerator 样本都没有引用根呢？这里又藏了什么玄机呢？

3. DynamicILGenerator为什么无引用根

如果你有大量的dump分析经验，我相信你马上就会想到一个东西，对，它就是 finalizequeue，因为有析构但未被回收自然就想到了它，输出如下：

0:000> !fq -statSyncBlocks to be cleaned up: 0Free-Threaded Interfaces to be released: 0MTA Interfaces to be released: 0STA Interfaces to be released: 0----------------------------------Heap 0generation 0 has 25 objects (7f6b29d58238->7f6b29d58300)generation 1 has 90,693 objects (7f6b29ca7010->7f6b29d58238)generation 2 has 0 objects (7f6b29ca7010->7f6b29ca7010)Ready for finalization 4,088,657 objects (7f6b29d58488->7f6b2bc89f10)------------------------------Statistics for all finalizable objects (including all objects ready for finalization):

这一卦真的太灵验了，从尼玛 Ready for finalization 4,088,657 objects 中发现有 408w 的对象在freachable中等待释放，看样子FinalizerThread 有点麻烦了。

4. FinalizerThread 怎么了

不管怎么说，直觉告诉我马上就要真相大白了，有点抑制不住内心的喜悦，接下来切过去观察 FinalizerThread 的调用栈，输出如下：