炎炎夏日，朗朗乾坤，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 早在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对象回收掉。
但泄漏就这么赤裸裸的发生了。
我们用WinDbg看一下。
可以看到LOH大对象堆占用了600M左右的内存。
这里我们可以看出，Tree对象和Leaf对象均都存在内存中，而System.Byte[]类型的对象占用了600M左右的内存。
我们直接看看Tree类型的对象在哪里？
这里可以看出，内存中一共有6颗树，而且它们都与ConcurrentQueue类型有关联。
看看每颗Tree及其引用占用多少内存。
我们看到了，每个Tree对象及其引用占用了100M左右的内存。
这里明确的看到 00000000025ec0d8 地址上的这个Tree在GC的2代中。
很明确，00000000025ec0d8 地址上的这个Tree被ConcurrentQueue对象引用着。
我们直接看下 00000000025e1720 和 00000000025e1748 这些对象是什么？
我们看到Segment类型对象应该是ConcurrentQueue内部引用的一个对象，而Segment中包含一个名称为m_array的System.Object[]类型的字段。
那么直接看看m_array数组吧。
哎~~发现数组中居然有6个对象，这显然不是巧合，看看是什么？
该对象的类型居然就是Tree类型，我们看的是数组中第一个值的类型，再看看它的Name属性。
名字“Apple”正是我们设置的fruit的名字。
到此为止，我们可以完全确认，我们希望失去引用被GC回收的6个Tree类型对象，仍然被ConcurrentQueue的内部的Segment对象引用着，导致无法被GC回收。
真像就是，这是.NET4.0第一个版本中的Bug。我们在前文的链接中 Memory leak in ConcurrentQueue<T> class -- dequeued enteries are still rooted 已经可以明确。
再具体到.NET4.0的代码就是：
在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
也就是说，其实最多也就有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 中描述了一个 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看看。
至此，我们完整复现了.NET4.0中的这个ConcurrentQueue<T>的Bug。
前文中我们说了，这个问题在我的开发机上无法复现。这是为什么呢？
我的开发机是32位Windows7操作系统，而部署环境是64位WindowsServer2008操作系统。不过这并不是无法复现的原因，程序集上我设置了AnyCPU。
ConcurrentQueue类在mscorlib.dll中，编译时可以看到：
Assembly mscorlib C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll
我们可以用WinDbg看下程序都加载了哪些程序集。
在开发机是32位Windows7操作系统上：
在部署环境是64位WindowsServer2008操作系统上：
可以明确的是，程序引用了 .NET Framework v4.0.30319， 区别就在这里。
此处 mscorlib.dll 引自 Native Images，我们直接参考 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll。
在开发机是32位Windows7操作系统上：
在部署环境是64位WindowsServer2008操作系统上：
我们看到了引用的 mscorlib.dll 的版本不同。
那么 .NET 4.0 到底有哪些版本？
而我本机使用了 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。
这就涉及到 .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 。
至此，我们清楚了为什么开发机无法复现的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)。
logs_code_hide('7f849519-c57f-4536-8873-283090265c3e',event)" src="/Upload/Images/2013080111/2B1B950FA3DF188F.gif" alt="" />
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 }View Code
相关文章![ASP.NET Web API框架揭秘：HttpMessageHandler管道[上篇]](/Upload/SmallIMG/2013080110/CD85265EF91F53BB.png)
