.net - .NET CLR 如何区分托管指针和非托管指针？

Question

一切最终都会被 JIT 到 native 机器代码中，因此最终，我们在 .NET 中有一个 native 堆栈，GC 每当进行垃圾收集时都需要扫描对象指针。

现在的问题是:.NET 垃圾收集器如何确定指向 GC 堆内对象的指针实际上是托管指针还是恰好具有值的随机整数对应于有效地址？

显然，如果它无法区分两者，那么可能会出现内存泄漏，所以我想知道它是如何工作的。或者——我敢说——.NET 有可能泄漏内存吗？ :O

Answer 1

正如其他人所指出的，GC 准确地知道堆栈和堆上每个 block 的哪些字段是托管引用，因为 GC 和抖动知道所有内容的类型。

但是，您的观点很好。想象一个完全假设的世界，其中同一进程中进行两种内存管理。例如，假设您有一个完全假设的程序，名为“InterMothra Chro-Nagava-Sploranator”，用 C++ 编写，它使用传统的 COM 样式引用计数内存管理，其中所有内容都只是指向进程内存的指针，并且通过调用释放方法正确的次数。假设 Sploranator 假设有一种脚本语言 JabbaScript，它维护一个垃圾收集对象池。

当 JabbaScript 对象引用非托管 Sploranator 对象，并且该 Sploranator 对象也有引用时，就会出现问题。这是 JabbaScript 垃圾收集器无法破坏的循环引用，因为它不知道 Sploranator 对象的内存布局。因此这里存在内存泄漏的可能性。

解决此问题的一种方法是重写 Sploranator 内存管理器，以便它从托管 GC 池中分配其对象。

另一种方法是使用启发式； GC 可以专门使用处理器的线程来扫描所有内存，查找恰好是指向其对象的指针的整数。这听起来很多，但它可以省略未提交的页面、其自己的托管堆中的页面、已知仅包含代码的页面等等。 GC 可以猜测，如果它认为某个对象可能已死亡，并且在其控制之外的任何内存中找不到任何指向该对象的指针，则该对象几乎肯定已死亡。

这种启发式的缺点当然是它可能是错误的。您可能有一个意外与指针匹配的整数(尽管在 64 位环境中这种情况不太可能发生)。这将延长对象的生命周期。但谁在乎？我们已经处于循环引用可以延长对象生命周期的情况。我们正在努力让这种情况变得更好，而这种启发式方法就是这样做的。它不完美并不重要；它并不完美。总比没有好。

另一种可能出错的方式是 Sploranator 可能对指针进行编码，例如在存储值时翻转其所有位，然后仅在调用之前将其翻转回来。如果 Sploranator 对这种 GC 启发式策略积极敌视，那么它就不起作用。

此处概述的垃圾收集策略与任何产品的实际 GC 策略之间的相似之处几乎完全是巧合。 Eric 对假设的不存在产品的垃圾收集器的实现细节的思考仅供娱乐。