那些年黑了你的微软BUG

素颜马尾好姑娘i 2021-11-26 12:52 311阅读 0赞

## 前言 ##

炎炎夏日，朗朗乾坤，30℃的北京，你还在Coding吗？

整个7月都在忙项目，还加了几天班，终于在这周一29号，成功的Release了产品。方能放下心来，潜心地研究一些技术细节，希望能形成一篇Blog，搭上7月最后一天的末班车。

## 背景 ##

本篇文章起源于项目中的一个Issue，这里大概描述下Issue背景。

首先，我们在开发一个NetTcpBinding的WCF服务，基于.NET4.0版本的Windows服务应用。

在设计的软件中有Promotion的概念，Promotion可以理解为“促销”，而“促销”就会有起始时间（StartTime）和结束时间（EndTime）的时间段（Duration）的概念。在“促销”时间段内，参与的用户会得到一些额外的奖励。

测试人员发现，在测试部署的环境中，在Service启动之后，Schedule第一个Promotion，当该Promotion经历开始与结束的过程之后，Promotion结束后的Service内存占用会比Promotion开始前多30-100M左右。这些多出来的内存还会变化，比如在Schedule第二个Promotion并运行之后，内存可能多或者可能少，所以会有一个30-100M的浮动空间。

一开始并不觉得这是个问题，比如我考虑在Promotion结束后，会进行一些清理工作，清除一些不再使用的缓存，而这些原先被引用的数据有些比较大，可能在Gen2的GC的LOH大对象堆中，还没有被GC及时回收。后来，手动增加了GC.Collect()方法进行触发，但也不能完全确认就一定能回收掉，因为GC可能会评估当前的情况选择合适的回收时机。这样的解释很含糊，所以不足以解决问题。

再者，在我自己的开发机上进行测试，没有发现类似的问题。所以该问题一直没有引起我的重视，直到这个月在Release前的持续测试中，决定用WinDbg上去看看到底内存中残留了什么东西，才发现了真正的问题根源。

## 问题根源 ##

问题的Root Cause是由于使用了多个ConcurrentQueue<T>泛型类，而ConcurrentQueue在Dequeue后并不会移除对T类型对象的引用，进而造成内存泄漏。而这是一个微软确认的已知Bug。

业务上说，就是当Promotion开始之后，会不断的有新的Item被Enqueue到ConcurrentQueue实例中，有不同的线程会不断的Dequeue来处理Item。而当Promotion结束时，会TryDequeue出所有ConcurrentQueue中的Item，此时会有一部分对象仍然遗留，造成内存泄漏。同时，根据业务对象的大小不同，以及业务对象引用的对象等等均不能释放，造成泄漏内存的数量还不是恒定的。

什么？你不信微软有Bug？猛击这里：*[Memory leak in ConcurrentQueue<T> class -- dequeued enteries are still rooted][Memory leak in ConcurrentQueue_T_ class -- dequeued enteries are still rooted]* 早在2010年时，社区就已经上报了Bug。

现在已经是2013年了，甚至微软已经出了.NET4.5，并且修复了这个Bug，只是我Out的太久，才知道这个Bug而已。不过能被黑到也是一种运气。

而在我开发机上没有复现的原因是因为部署的.NET环境不同，下面会详解。

## 复现问题 ##

我尝试编写最简单的代码来复现这个问题，这里会编写一个简单的命令行程序。

首先我们定义两个类，Tree类和Leaf类，显然Tree将包含多个Leaf，而Leaf中会包含一个泛型T的Content，我们将在Content属性上根据要求设定占用内存空间的大小。

1   internal class Tree
     2   {
     3     public Tree(string name)
     4     {
     5       Name = name;
     6       Leaves = new List<Leaf<byte[]>>();
     7     }
     8 
     9     public string Name { get; private set; }
    10     public List<Leaf<byte[]>> Leaves { get; private set; }
    11   }
    12 
    13   internal class Leaf<T>
    14   {
    15     public Leaf(Guid id)
    16     {
    17       Id = id;
    18     }
    19 
    20     public Guid Id { get; private set; }
    21     public T Content { get; set; }
    22   }

然后我们定义一个ConcurrentQueue<Tree>类型，用于存放多个Tree。

static ConcurrentQueue<Tree> _leakedTrees = new ConcurrentQueue<Tree>();

编写一个方法，根据输入的配置，构造指定大小的Tree，并将Tree放入ConcurrentQueue<Tree>中。

1     private static void VerifyLeakedMethod(IEnumerable<string> fruits, int leafCount)
     2     {
     3       foreach (var fruit in fruits)
     4       {
     5         Tree fruitTree = new Tree(fruit);
     6         BuildFruitTree(fruitTree, leafCount);
     7         _leakedTrees.Enqueue(fruitTree);
     8       }
     9 
    10       Tree ignoredItem = null;
    11       while (_leakedTrees.TryDequeue(out ignoredItem)) { }
    12     }

这里起的名字为VerifyLeakedMethod，然后在Main函数中调用。

1     static void Main(string[] args)
     2     {
     3       List<string> fruits = new List<string>() // 6 items
     4       { 
     5         "Apple", "Orange", "Pear", "Banana", "Peach", "Hawthorn",
     6       };
     7 
     8       VerifyLeakedMethod(fruits, 100); // 6 * 100 = 600M
     9 
    10       GC.Collect(2);
    11       GC.WaitForPendingFinalizers();
    12 
    13       Console.WriteLine("Leaking or Unleaking ?");
    14       Console.ReadKey();
    15     }

我们指定了fruits列表包含6种水果类型，期待构造6棵水果树，每个树包含100个叶子，而每个叶子中的Content默认为1M的byte数组。

1     private static void BuildFruitTree(Tree fruitTree, int leafCount)
     2     {
     3       Console.WriteLine("Building {0} ...", fruitTree.Name);
     4 
     5       for (int i = 0; i < leafCount; i++) // size M
     6       {
     7         Leaf<byte[]> leaf = new Leaf<byte[]>(Guid.NewGuid())
     8         {
     9           Content = CreateContentSizeOfOneMegabyte()
    10         };
    11         fruitTree.Leaves.Add(leaf);
    12       }
    13     }
    14 
    15     private static byte[] CreateContentSizeOfOneMegabyte()
    16     {
    17       byte[] content = new byte[1024 * 1024]; // 1 M
    18       for (int j = 0; j < content.Length; j++)
    19       {
    20         content[j] = 127;
    21       }
    22       return content;
    23     }

那么，运行起来之后，由于每颗Tree的大小为100M，所以整个应用程序会占用600M以上的内存。

而当执行TryDequeue循环之后，会清空该Queue。理论上讲，我们会认为TryDequeue之后，ConcurrentQueue<Tree>已经失去了对各个Tree对象实例的引用，而各个Tree对象已经在程序中没有被任何其他对象引用，则可认为在执行GC.Collect()之后，会从堆中将Tree对象回收掉。

但泄漏就这么赤裸裸的发生了。

![SouthEast][]

我们用WinDbg看一下。

*  **.loadby sos clr**
 *  **!eeheap -gc**

![SouthEast 1][]

可以看到LOH大对象堆占用了600M左右的内存。

*  **!dumpheap -stat**

![SouthEast 2][]

这里我们可以看出，Tree对象和Leaf对象均都存在内存中，而System.Byte\[\]类型的对象占用了600M左右的内存。

我们直接看看Tree类型的对象在哪里？

*  **!dumpheap -type MemoryLeakDetection.Tree**

![SouthEast 3][]

这里可以看出，内存中一共有6颗树，而且它们都与ConcurrentQueue类型有关联。

看看每颗Tree及其引用占用多少内存。

*  **!objsize 00000000025ec0d8**

![SouthEast 4][]

我们看到了，每个Tree对象及其引用占用了100M左右的内存。

*  **.load sosex.dll**
 *  **!gcgen 00000000025ec0d8**

![SouthEast 5][]

这里明确的看到 00000000025ec0d8 地址上的这个Tree在GC的2代中。

*  **!gcroot 00000000025ec0d8**

![SouthEast 6][]

很明确，00000000025ec0d8 地址上的这个Tree被ConcurrentQueue对象引用着。

我们直接看下 00000000025e1720 和 00000000025e1748 这些对象是什么？

*  **!do 00000000025e1720**
 *  **!dumpobj 00000000025e1748**

![SouthEast 7][]

我们看到Segment类型对象应该是ConcurrentQueue内部引用的一个对象，而Segment中包含一个名称为m\_array的System.Object\[\]类型的字段。

那么直接看看m\_array数组吧。

*  **!dumparray 00000000025e1780**

![SouthEast 8][]

哎~~发现数组中居然有6个对象，这显然不是巧合，看看是什么？

*  **!do 00000000025e1d80**

![SouthEast 9][]

该对象的类型居然就是Tree类型，我们看的是数组中第一个值的类型，再看看它的Name属性。

*  **!do 00000000025e1b50**

![SouthEast 10][]

名字“Apple”正是我们设置的fruit的名字。

到此为止，我们可以完全确认，我们希望失去引用被GC回收的6个Tree类型对象，仍然被ConcurrentQueue的内部的Segment对象引用着，导致无法被GC回收。

## 真相 ##

真像就是，这是.NET4.0第一个版本中的Bug。我们在前文的链接中 *[Memory leak in ConcurrentQueue<T> class -- dequeued enteries are still rooted][Memory leak in ConcurrentQueue_T_ class -- dequeued enteries are still rooted]*  已经可以明确。

再具体到.NET4.0的代码就是：

![SouthEast 11][]

在Segment的TryRemove方法中，仅将m\_array中的对象返回，并减少了Queue长度的计数，而并没有将对象从m\_array中移除。

internal volatile T[] m_array;

也就是说，我们至少需要一句下面这样的代码来保证对象的引用被释放掉。

m_array[lowLocal] = default(T)

微软官方的解释在这里 ：*[ConcurrentQueue<T> holding on to a few dequeued elements][ConcurrentQueue_T_ holding on to a few dequeued elements]*

也就是说，其实最多也就有m\_array长度的对象个数仍然在内存中。

private const int SEGMENT_SIZE = 32;
    m_array = new T[SEGMENT_SIZE];

而长度已经被定义为32，也就是最多有32个对象仍然被保存在内存中，导致无法被GC回收。单个对象越大，泄漏的内存越多。

同时，由于新Enqueue的对象会覆盖掉原有的对象引用，如果每个对象的大小不同，就会引起内存的变化。这也就是为什么我的程序的内存会有30-100M左右的内存变更，而且还不确定。

## 解决办法 ##

在文章 *[ConcurrentQueue<T> holding on to a few dequeued elements][ConcurrentQueue_T_ holding on to a few dequeued elements]* 中描述了一个 Workaround，这也算官方的 Workaround 了。

就是使用 StrongBox 类型进行包装，在Dequeue之后将 StrongBox 中 Value 属性的引用置为 null ，间接的移除对象的引用。这种情况下，我们最多泄漏 32 个 StrongBox 对象，而 StrongBox 对象又特别小，每个只占 24 Bytes，如果不计较的话这个大小几乎可以忽略不计，也就变向解决了问题。

1     static ConcurrentQueue<StrongBox<Tree>> _unleakedTrees = new ConcurrentQueue<StrongBox<Tree>>();
     2 
     3     private static void VerifyUnleakedMethod(IEnumerable<string> fruits, int leafCount)
     4     {
     5       foreach (var fruit in fruits)
     6       {
     7         Tree fruitTree = new Tree(fruit);
     8         BuildFruitTree(fruitTree, leafCount);
     9         _unleakedTrees.Enqueue(new StrongBox<Tree>(fruitTree));
    10       }
    11 
    12       StrongBox<Tree> ignoredItem = null;
    13       while (_unleakedTrees.TryDequeue(out ignoredItem))
    14       {
    15         ignoredItem.Value = null;
    16       }
    17     }

修改完的代码运行后，内存只有6M多。我们再用WinDbg看看。

![SouthEast 12][]

*  **.loadby sos clr**
 *  **.load sosex.dll**
 *  **!dumpheap -stat**
 *  **!dumpheap -mt 000007ff00055928**

**![SouthEast 13][]**

*  **!dumpheap -type StrongBox**

![SouthEast 14][]

*  **!dumpheap -type System.Collections.Concurrent.ConcurrentQueue\`1+Segment**

![SouthEast 15][]

*  **!do 0000000002451960**

![SouthEast 16][]

*  **!da 0000000002451998**

![SouthEast 17][]

*  **!do 0000000002455a10**

![SouthEast 18][]

至此，我们完整复现了.NET4.0中的这个ConcurrentQueue<T>的Bug。

## 环境干扰 ##

前文中我们说了，这个问题在我的开发机上无法复现。这是为什么呢？

我的开发机是32位Windows7操作系统，而部署环境是64位WindowsServer2008操作系统。不过这并不是无法复现的原因，程序集上我设置了AnyCPU。

![SouthEast 19][]

ConcurrentQueue类在mscorlib.dll中，编译时可以看到：

Assembly mscorlib
        C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll

我们可以用WinDbg看下程序都加载了哪些程序集。

*  **lmf**

在开发机是32位Windows7操作系统上：

![SouthEast 20][]

在部署环境是64位WindowsServer2008操作系统上：

![SouthEast 21][]

*  **lmt**

![SouthEast 22][]

可以明确的是，程序引用了 .NET Framework v4.0.30319， 区别就在这里。

此处 mscorlib.dll 引自 Native Images，我们直接参考 C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\clr.dll。

在开发机是32位Windows7操作系统上：

![SouthEast 23][]

在部署环境是64位WindowsServer2008操作系统上：

![SouthEast 24][]

我们看到了引用的 mscorlib.dll 的版本不同。

那么 .NET 4.0 到底有哪些版本？

*  .NET 4.0 - 4.0.30319.1 （.NET 4.0 的第一个版本）
 *  .NET 4.0 - 4.0.30319.296 （.NET 4.0 的一个*[安全补丁 06-Sep-2012][06-Sep-2012]*）
 *  .NET 4.5 - 4.0.30319.17929 （.NET 4.5 版本）
 *  .NET 4.5 January Updates - 4.0.30319.18033 （.NET 4.5 的HotFix）

而我本机使用了 v4.0.30319.17929 版本的 mscorlib.dll，其是 .NET 4.5 的版本。

因为 .NET 4.5 和 .NET 4.0 均基于 .NET 4.0 CLR，而 .NET 4.5 对 CLR进行了升级和Bug修复，重要的是修复了ConcurrentQueue中的这个Bug。

![SouthEast 25][]

这就涉及到 .NET 4.5 对 .NET 4.0 CLR 的 "in-place upgrade" 升级了，可以参考这篇文章 *[.NET Versioning and Multi-Targeting - .NET 4.5 is an in-place upgrade to .NET 4.0][]* 。

![SouthEast 26][]

至此，我们清楚了为什么开发机无法复现的Bug，到了部署环境就出现了Bug。原因是开发机安装 Visual Studio 2012 的同时直接升级到了 .NET 4.5，进而 .NET 4.0 的程序使用修复后的类库，所以没有了该Bug。

## 修复细节 ##

那么微软是如何修复的这个Bug呢？直接看代码就可以了，在Segment类的TryRemove方法中加了一个处理，但这是基于新的设计，这里就不展开了。

1                         //if the specified value is not available (this spot is taken by a push operation, 
     2                         // but the value is not written into yet), then spin
     3                         SpinWait spinLocal = new SpinWait(); 
     4                         while (!m_state[lowLocal].m_value)
     5                         {
     6                             spinLocal.SpinOnce();
     7                         } 
     8                         result = m_array[lowLocal];
     9  
    10                         // If there is no other thread taking snapshot (GetEnumerator(), ToList(), etc), reset the deleted entry to null. 
    11                         // It is ok if after this conditional check m_numSnapshotTakers becomes > 0, because new snapshots won't include
    12                         // the deleted entry at m_array[lowLocal]. 
    13                         if (m_source.m_numSnapshotTakers <= 0)
    14                         {
    15                             m_array[lowLocal] = default(T); //release the reference to the object.
    16                         }

也就是原先存在问题是因为需要考虑为GetEnumerator()操作保存snapshot，保留引用而保证数据完整性。而现在通过了额外的机制设计来保证了，在合适的时机将m\_array内容置为default(T)。

## 社区讨论 ##

*  *[.NET Framework - Possible memory-leaky classes?][.NET Framework - Possible memory-leaky classes]*
 *  *[Usage of ConcurrentQueue<StrongBox<T>>][Usage of ConcurrentQueue_StrongBox_T]*

## 完整代码 ##

![ContractedBlock.gif][] ![ExpandedBlockStart.gif][]

1 using System;
      2 using System.Collections.Concurrent;
      3 using System.Collections.Generic;
      4 using System.Runtime.CompilerServices;
      5 
      6 namespace MemoryLeakDetection
      7 {
      8   class Program
      9   {
     10     static void Main(string[] args)
     11     {
     12       List<string> fruits = new List<string>() // 6 items
     13       { 
     14         "Apple", "Orange", "Pear", "Banana", "Peach", "Hawthorn",
     15       };
     16 
     17       VerifyUnleakedMethod(fruits, 100); // 6 * 100 = 600M
     18 
     19       GC.Collect(2);
     20       GC.WaitForPendingFinalizers();
     21 
     22       Console.WriteLine("Leaking or Unleaking ?");
     23       Console.ReadKey();
     24     }
     25 
     26     static ConcurrentQueue<Tree> _leakedTrees = new ConcurrentQueue<Tree>();
     27 
     28     private static void VerifyLeakedMethod(IEnumerable<string> fruits, int leafCount)
     29     {
     30       foreach (var fruit in fruits)
     31       {
     32         Tree fruitTree = new Tree(fruit);
     33         BuildFruitTree(fruitTree, leafCount);
     34         _leakedTrees.Enqueue(fruitTree);
     35       }
     36 
     37       Tree ignoredItem = null;
     38       while (_leakedTrees.TryDequeue(out ignoredItem)) { }
     39     }
     40 
     41     static ConcurrentQueue<StrongBox<Tree>> _unleakedTrees = new ConcurrentQueue<StrongBox<Tree>>();
     42 
     43     private static void VerifyUnleakedMethod(IEnumerable<string> fruits, int leafCount)
     44     {
     45       foreach (var fruit in fruits)
     46       {
     47         Tree fruitTree = new Tree(fruit);
     48         BuildFruitTree(fruitTree, leafCount);
     49         _unleakedTrees.Enqueue(new StrongBox<Tree>(fruitTree));
     50       }
     51 
     52       StrongBox<Tree> ignoredItem = null;
     53       while (_unleakedTrees.TryDequeue(out ignoredItem))
     54       {
     55         ignoredItem.Value = null;
     56       }
     57     }
     58 
     59     private static void BuildFruitTree(Tree fruitTree, int leafCount)
     60     {
     61       Console.WriteLine("Building {0} ...", fruitTree.Name);
     62 
     63       for (int i = 0; i < leafCount; i++) // size M
     64       {
     65         Leaf<byte[]> leaf = new Leaf<byte[]>(Guid.NewGuid())
     66         {
     67           Content = CreateContentSizeOfOneMegabyte()
     68         };
     69         fruitTree.Leaves.Add(leaf);
     70       }
     71     }
     72 
     73     private static byte[] CreateContentSizeOfOneMegabyte()
     74     {
     75       byte[] content = new byte[1024 * 1024]; // 1 M
     76       for (int j = 0; j < content.Length; j++)
     77       {
     78         content[j] = 127;
     79       }
     80       return content;
     81     }
     82   }
     83 
     84   internal class Tree
     85   {
     86     public Tree(string name)
     87     {
     88       Name = name;
     89       Leaves = new List<Leaf<byte[]>>();
     90     }
     91 
     92     public string Name { get; private set; }
     93     public List<Leaf<byte[]>> Leaves { get; private set; }
     94   }
     95 
     96   internal class Leaf<T>
     97   {
     98     public Leaf(Guid id)
     99     {
    100       Id = id;
    101     }
    102 
    103     public Guid Id { get; private set; }
    104     public T Content { get; set; }
    105   }
    106 }

[Memory leak in ConcurrentQueue_T_ class -- dequeued enteries are still rooted]: http://connect.microsoft.com/VisualStudio/feedback/details/552868/memory-leak-in-concurrentqueue-t-class-dequeued-enteries-are-still-rooted
[SouthEast]: /images/20211126/142cc1ca36164f28bbd1b7b63816f322.png
[SouthEast 1]: /images/20211126/0d1e2f492f8c470d9e55513e506fa188.png
[SouthEast 2]: /images/20211126/e6ef48342c714d51bbf7fbb0e159464a.png
[SouthEast 3]: /images/20211126/a28eeff5d8834841b136e1bd5cc8d946.png
[SouthEast 4]: /images/20211126/ddecf9e7ae19433f8882b8c40ec64220.png
[SouthEast 5]: /images/20211126/9a6bce240e90414392cc3914d68075b6.png
[SouthEast 6]: /images/20211126/adffd5ec3a63482fa1c5cb63bc16699e.png
[SouthEast 7]: /images/20211126/15fdd34cd775437a9119e9ebea0dd1a1.png
[SouthEast 8]: /images/20211126/d9b27e1f18f747edb0857f1bb20f27f8.png
[SouthEast 9]: /images/20211126/8ed45aac2bf24e4e8088bd47259b7259.png
[SouthEast 10]: /images/20211126/c0c5cd22d3a845d993cd7d6269f80c06.png
[SouthEast 11]: /images/20211126/0d7ff36f462e47af9d1ad748cff7d1aa.png
[ConcurrentQueue_T_ holding on to a few dequeued elements]: http://blogs.msdn.com/b/pfxteam/archive/2012/05/08/concurrentqueue-lt-t-gt-holding-on-to-a-few-dequeued-elements.aspx
[SouthEast 12]: /images/20211126/94f9c67c8555435b88de4cb5f3a269b8.png
[SouthEast 13]: /images/20211126/307e3c7e8fc24791b631e8b2a3d8f056.png
[SouthEast 14]: /images/20211126/d51f611beb7a4ec087e5fa0e739bec73.png
[SouthEast 15]: /images/20211126/0dff21805c664805ade8c6844a89131c.png
[SouthEast 16]: /images/20211126/28c3d8ab735f4b7b98a8ec4d6a9f6704.png
[SouthEast 17]: /images/20211126/ad500464633f4db582ac0e90d5618b95.png
[SouthEast 18]: /images/20211126/6ca5997570054375b31169f3721aebf4.png
[SouthEast 19]: /images/20211126/9a841e6ba95a4c6d8e370dfb63532148.png
[SouthEast 20]: /images/20211126/5f24b53684504a7a8b14075f806d85bb.png
[SouthEast 21]: /images/20211126/f140daddc5554d7b89565f6e412f363f.png
[SouthEast 22]: /images/20211126/37e19739963e462190bc41aa4b0942b5.png
[SouthEast 23]: /images/20211126/e0b054a8bb7d43de9b47e051233871ff.png
[SouthEast 24]: /images/20211126/0fe01dc6988c46588fdef93d7ebaba11.png
[06-Sep-2012]: http://support.microsoft.com/kb/2729449
[SouthEast 25]: /images/20211126/0933696f86334110910edb725d95767e.png
[.NET Versioning and Multi-Targeting - .NET 4.5 is an in-place upgrade to .NET 4.0]: http://www.hanselman.com/blog/NETVersioningAndMultiTargetingNET45IsAnInplaceUpgradeToNET40.aspx
[SouthEast 26]: /images/20211126/8388bf66bf3246edb2a993ad7d393315.png
[.NET Framework - Possible memory-leaky classes]: http://stackoverflow.com/questions/2678165/net-framework-possible-memory-leaky-classes/2679315#2679315
[Usage of ConcurrentQueue_StrongBox_T]: http://stackoverflow.com/questions/13612098/usage-of-concurrentqueuestrongboxt
[ContractedBlock.gif]: http://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif
[ExpandedBlockStart.gif]: /images/20211126/9b26e49126e241ddb0065a8ab5d8d7b7.png