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