由于建议对大型物体使用IDisposal模式，我想知道为什么似乎没有可靠的方法来确定限制，从哪个对象被认为是“大”？
内部存在这样的区别：在LOH上分配的对象的下限。每当它以85k公开通信时，同时会阻止一个人依赖该号码。
特别是对于处理大量“较大”阵列的应用程序，为了实现适当的内存管理和防止LOH碎片，必然需要该限制。另一方面，对于“较小”的阵列，从内存消耗的角度来看，IDisposal没有意义。压缩GC在这方面做得更好。
为什么没有这样的东西
GC.GetLOHLimit()
甚至更好：
bool GC.ArrayTargetForManualDisposal(Type type, int length);
编辑：我知道，IDisposable模式只是建议正确处理特殊对象（例如“大”或非托管对象）。我的问题不是假设，运行时会对这些对象进行任何特殊处理。我宁愿要求对模式的实现者（也可能是其他人）提供运行时支持，以便知道对象何时应该遵循特殊的内存管理。
答案 0 :(得分：4)
IDisposable与托管内存管理无关。处理对象是用户约定\ pattern，运行时不在内部使用它，并且对内存管理没有影响。运行时不了解IDisposable。 IDisposable的唯一特殊处理\识别是与using关键字一起使用时，但编译器（至少是C＃编译器）会识别它，而不是运行时。
对于LOH，LOH算法没有公开保证 - 这就是为什么没有API来获取诸如最大对象大小等参数。在CLR的未来版本中，对于LOH考虑的对象大小确实是动态的是非常可行的。 CLR设计者不希望用户将自己耦合到内存管理的内部细节，因为这会使他们更难或不可能在不破坏大量现有程序的情况下更改它。
如果您关注CLR内存管理，我首先会建议您了解IDisposable没有参与其中。
答案 1 :(得分：3)
据Chibacity说，IDisposable与LOH管理无关。这是一篇关于LOH的好文章：Large Object Heap Uncovered。
话虽如此，据我所知，没有任何公共API来确定LOH大小。您可以在SSCLI“转子”中找到对85000字节限制的引用（此处提供的来源：Shared Source Common Language Infrastructure 2.0 Release Download）：
在clr / src / vm / gc.h中：
#define LARGE_OBJECT_SIZE 85000
虽然这个源是CLR 2.0等效源，而不是CLR 4，但我认为它们没有改变它，因为它肯定会对现有代码产生深远的影响。
因此，如果你想用这个值做一些聪明的事情，你可能可以安全地将它放在一个常量中，或者使它可配置，但它肯定不会在运行过程中动态地改变。