这是未处理的项目问题还是大对象堆问题？答案

【问题标题】：Is this an undisposed item issue or Large Object Heap issue?这是未处理的项目问题还是大对象堆问题？
【发布时间】：2017-09-24 03:45:10
【问题描述】：

我正在尝试找出为什么我们的一个站点使用 2.3GB 内存。从 windbg，当我运行 !dumpheap -stat 时，我得到了这个：

000007fe992ae8d8    39413     11489246 System.Byte[]
000007fe992abf40     8567     14995548 System.Char[]
000007fe994500b0    31763     31617136 System.Int32[]
000007fe9c7b4cf8  1221470     48858800 XXXXXXX.SearchService+SectorItem
000007fe9925ba30   219828     49646032 System.Object[]
000007fe992a46f0  4273039    264621916 System.String
0000000002a35c10     2214    923713198      Free
Total 6994094 objects
Fragmented blocks larger than 0.5 MB:
            Addr     Size      Followed by
000000010625ef50    1.2MB 00000001063982e0 System.Collections.Hashtable
00000001064c9ed0    4.4MB 0000000106932128 System.Object[]
0000000206a4ee48    0.6MB 0000000206ae0a10 System.String
0000000206d270a0    3.9MB 0000000207106058 Free
0000000305282098    0.8MB 000000030534d248 System.Xml.XmlElementListListener
00000003053c5ad0    0.9MB 00000003054a87c0 System.String
0000000406a8b0f0    1.9MB 0000000406c73f10 System.WeakReference
0000000406c7aac8    2.2MB 0000000406ea43a8 System.Byte[]
0000000406ef89a8    1.5MB 00000004070721d8 System.Collections.Concurrent.ConcurrentDictionary`2+Node[[System.String, mscorlib],[System.DateTime, mscorlib]]
0000000407072208    1.2MB 00000004071a77c0 System.Threading.ThreadPoolWorkQueueThreadLocals
00000004073d1110   11.3MB 0000000407f1a7f8 Free

我们可以看到有超过 900MB 的“空闲”对象并且从未从 IIS 内存中释放（我看了几天的图表）。如果我这样做，则有 2200 个免费对象：

!dumpheap -mt 0000000002a35c10

有很多免费对象：

00000005310b8008 0000000002a35c10       30 Free
00000005310dce28 0000000002a35c10       30 Free
0000000531101a50 0000000002a35c10       30 Free
0000000531126870 0000000002a35c10       30 Free
000000053114c680 0000000002a35c10       30 Free
0000000531187ee8 0000000002a35c10       30 Free
00000005311c3538 0000000002a35c10       30 Free
00000005311fefe0 0000000002a35c10 18583286 Free
0000000532a5e3a0 0000000002a35c10  9499822 Free
0000000533383848 0000000002a35c10  9830638 Free
0000000533d98db8 0000000002a35c10 46462326 Free
0000000536a40d70 0000000002a35c10       30 Free
0000000536a6f300 0000000002a35c10 10549646 Free
00000005374cf138 0000000002a35c10 10246582 Free
0000000537ee4f98 0000000002a35c10 80664406 Free
000000053cccb570 0000000002a35c10 22118654 Free

根据这篇文章： https://www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/ 任何大于 85000 字节的内容都不会被自动回收。那么我可以得出结论，我们在内存中有一些非常大的对象（例如，可能是一个大字典）并且永远不会被 GC 删除吗？所以这是一个LOH问题而不是内存泄漏问题？

如果是 LOH 问题，如果大对象在缓存中（如此重用）或在内存中使用一次，是否有什么区别？ GC 会收集其中任何一个吗？

【问题讨论】：

标签： clr windbg

【解决方案1】：

任何大于 85000 字节的内容都不会被自动回收。

它将被收集，但不会包含在 GC 堆的压缩中。

所以我可以得出结论，我们在内存中有一些非常大的对象 [...]

不是来自给定的数据。如果两个Free 区域相互跟随，它们将合并为一个更大的区域。因此，一个 9 MB Free 区域可能是 1000 个“小”对象，每个 9000 字节，随后在内存中对齐。

[...] 并且永远不会被 GC 删除？

它们已被 GC 删除，因为它是 Free。这些不是Free 类型的对象。从 .NET 的角度来看，它确实是免费的，当您创建新对象时，它会被 .NET 框架重用。

但是，该内存尚未使用 VirtualFree() 调用从 .NET 返回到操作系统。因此，从操作系统的角度来看，内存仍在使用中。

所以这是一个 LOH 问题 [...]

如果不知道 GC 堆的边界，就无法判断这一点。尝试!eeheap 来查看生成从哪里开始或使用 SOSEX'!dumpgen 转储特定的 GC 堆，仅查看它是否包含 Free 对象。

[...] 除了内存泄漏问题？

这不是内存泄漏，因为内存已被垃圾收集器释放。您的开发人员无法让 .NET 将该内存返回给操作系统。出于某种原因，.NET 认为它应该保留内存以供以后使用。

如果大对象在缓存中（如此重用）或在内存中使用一次，有什么区别吗？

如果它被缓存引用，对象将不会被垃圾回收（如果它不是弱引用）。然后，您将不再看到 Free 对象，而是看到真实的对象。

GC 会收集其中任何一个吗？

GC 将收集未被引用的对象，并可能收集被弱引用（缓存可能使用）引用的对象。

【讨论】：

问题是为什么内存中有这么多免费对象却永远不会被删除？我应该每小时手动调用一次GC来清除内存吗？
@daxu：这些不是对象，它是空闲内存——从 .NET 的角度来看是免费的。它们已经被垃圾回收了，所以执行GC.Collect() 不会做任何事情。决定不调用VirtualFree()的是.NET框架，所以空闲内存不会回到操作系统。
谢谢你，有没有一些关于为什么没有调用 VirtualFree() 的文章？查看我们的代码，我意识到我们默认将每个数据库调用的结果缓存 30 分钟（在内存缓存中，而不是在 redis 中）。难道是我们不断地缓存并从缓存中删除东西，所以.net决定保留内存空间还是什么？
@daxu：这可能是原因之一。另一个可能是 .NET 一次获得大量内存，例如100 MB，其中只有 90 MB 是免费的。这时就不能调用VirtualFree()，因为内存只能整体释放。
@daxu：你好像有一个64位的进程。我想知道你为什么这么关心。你的程序应该运行良好。如果您只关心内存泄漏，则所描述的行为不是内存泄漏。您是否还在寻找可能由该内存行为引起的性能问题？