为什么.NET内存管理会创建如此大的对象堆？大部分似乎都是空的。这是值得关注的吗？
以下数据是否意味着实际上我的应用程序中只有179 MB大型对象？通过从1171428792（Heap0 LOH）减去983396616（免费LOH）得出179 MB。
通过在w3wp.exe（即ASP.NET进程）上创建的转储文件上使用WinDbg收集以下信息。该过程托管在Windows 2008 64位操作系统上。该应用程序使用Microsoft .NET Framework 4.0和ASP.NET MVC 3构建。
0:025> !HeapStat
Heap Gen0 Gen1 Gen2 LOH
Heap0 4628496 3840808 319586376 1171428792
Free space: Percentage
Heap0 24 24 1926224 983396616SOH: 0% LOH: 83%
答案 0 :(得分：0)
我建议运行一个！DumpHeap -stat 查找名为“FREE”的对象的总字节值。这些将是LOH中的免费区块可供使用，但是已经通过颠簸大型物体堆而碎片化。如果这个数字很接近，那么你就会用很多短暂的物体击中你的LOH，留下一些空闲的记忆（记住这个堆永远不会压缩）。
答案 1 :(得分：0)
您确定LOH已经提交了多少 - 或者它只是保留地址空间？
我刚刚使用Sysinternal的VM Map查看了PowerShell.exe实例。这显示总GC堆大约为390MB，但保留了两个最大的块（~240MB和~125MB）。提交的内容少于20MB（即分配的物理内存或页面文件空间）。
要重新强制执行此操作，整个进程提交大约为200MB，小于分配给GC堆的地址空间。