我正在使用的C＃/。NET应用程序正遭受缓慢的内存泄漏。我已经将CDB与SOS结合使用，试图确定正在发生的事情，但是数据似乎没有任何意义，因此我希望你们中的一个以前可能已经经历过这种情况。
该应用程序在64位框架上运行。它正在不断地计算数据并将其序列化到远程主机，并且相当大地达到了大对象堆（LOH）。但是，我希望大多数LOH对象都是瞬态的：一旦完成计算并将其发送到远程主机，就应该释放内存。但是，我看到的是大量（活动的）对象数组与空闲的内存块交错，例如，从LOH中获取随机段：
0:000> !DumpHeap 000000005b5b1000 000000006351da10
Address MT Size
...
000000005d4f92e0 0000064280c7c970 16147872
000000005e45f880 00000000001661d0 1901752 Free
000000005e62fd38 00000642788d8ba8 1056 <--
000000005e630158 00000000001661d0 5988848 Free
000000005ebe6348 00000642788d8ba8 1056
000000005ebe6768 00000000001661d0 6481336 Free
000000005f214d20 00000642788d8ba8 1056
000000005f215140 00000000001661d0 7346016 Free
000000005f9168a0 00000642788d8ba8 1056
000000005f916cc0 00000000001661d0 7611648 Free
00000000600591c0 00000642788d8ba8 1056
00000000600595e0 00000000001661d0 264808 Free
...显然，如果我的应用程序在每次计算过程中都创建了长寿命的大对象，我希望情况会如此。（这样做是可以的，我接受会有一定程度的LOH碎片，但这不是问题所在。）问题是您在上述转储中看到的对象数组非常小（1056字节），我在代码中看不到被创建，并以某种方式保持根源。
还要注意，转储堆段时CDB不会报告类型：我不确定这是否相关。如果我转储标记的（<-）对象，CDB / SOS会很好地报告它：
0:015> !DumpObj 000000005e62fd38
Name: System.Object[]
MethodTable: 00000642788d8ba8
EEClass: 00000642789d7660
Size: 1056(0x420) bytes
Array: Rank 1, Number of elements 128, Type CLASS
Element Type: System.Object
Fields:
None对象数组的元素都是字符串，从我们的应用程序代码中可以识别出这些字符串。
另外，由于！GCRoot命令挂起并且再也没有回来，所以我找不到他们的GC根目录（我什至试图将其放置一夜）。
因此，如果有人能解释为什么这些小的（<85k）对象数组最终出现在LOH上，我将不胜感激：.NET在什么情况下会在其中放置一个小的对象数组？而且，有人碰巧知道确定这些对象根源的另一种方法吗？
更新1
我昨天晚些时候提出的另一种理论是，这些对象数组起初很大，但是已经缩小了，留下了内存转储中明显的可用内存块。使我感到怀疑的是，对象数组总是看起来长1056字节（128个元素），引用的长度为128 * 8，开销为32字节。
想法是，库中或CLR中的某些不安全代码可能破坏了数组头中元素数量的字段。我知道远射...
更新2
多亏了Brian Rasmussen（请参见接受的答案），该问题已被确定为由字符串实习生表引起的LOH碎片！我编写了一个快速测试应用程序来确认这一点：
static void Main()
{
const int ITERATIONS = 100000;
for (int index = 0; index < ITERATIONS; ++index)
{
string str = "NonInterned" + index;
Console.Out.WriteLine(str);
}
Console.Out.WriteLine("Continue.");
Console.In.ReadLine();
for (int index = 0; index < ITERATIONS; ++index)
{
string str = string.Intern("Interned" + index);
Console.Out.WriteLine(str);
}
Console.Out.WriteLine("Continue?");
Console.In.ReadLine();
}应用程序首先在循环中创建和取消引用唯一的字符串。这只是为了证明在这种情况下内存不会泄漏。显然，它不应该也不应。
在第二个循环中，创建并插入了唯一的字符串。此操作将它们根植在实习表中。我没有意识到实习表是如何表示的。看起来它由一组页面组成-由LOH创建的128个字符串元素的对象数组。这在CDB / SOS中更为明显：
0:000> .loadby sos mscorwks
0:000> !EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00f7a9b0
generation 1 starts at 0x00e79c3c
generation 2 starts at 0x00b21000
ephemeral segment allocation context: none
segment begin allocated size
00b20000 00b21000 010029bc 0x004e19bc(5118396)
Large object heap starts at 0x01b21000
segment begin allocated size
01b20000 01b21000 01b8ade0 0x00069de0(433632)
Total Size 0x54b79c(5552028)
------------------------------
GC Heap Size 0x54b79c(5552028)提取LOH段的转储揭示了我在泄漏的应用程序中看到的模式：
0:000> !DumpHeap 01b21000 01b8ade0
...
01b8a120 793040bc 528
01b8a330 00175e88 16 Free
01b8a340 793040bc 528
01b8a550 00175e88 16 Free
01b8a560 793040bc 528
01b8a770 00175e88 16 Free
01b8a780 793040bc 528
01b8a990 00175e88 16 Free
01b8a9a0 793040bc 528
01b8abb0 00175e88 16 Free
01b8abc0 793040bc 528
01b8add0 00175e88 16 Free total 1568 objects
Statistics:
MT Count TotalSize Class Name
00175e88 784 12544 Free
793040bc 784 421088 System.Object[]
Total 1568 objects请注意，对象数组的大小为528（而不是1056），因为我的工作站是32位，而应用程序服务器是64位。对象数组仍为128个元素长。
因此，这个故事的寓意是非常小心地进行实习。如果未知您正在实习的字符串是有限集的成员，则您的应用程序将因LOH的碎片而泄漏，至少在CLR的版本2中如此。
在我们的应用程序的情况下，反序列化代码路径中存在通用代码，可在解组期间实习实体标识符：我现在强烈怀疑这是罪魁祸首。但是，开发人员的意图显然是好的，因为他们想确保如果同一实体多次反序列化，那么只有一个标识符字符串实例将保留在内存中。