是否可以实现 GC.GetAliveInstancesOf() （用于调试）？
我知道这是之前回答过，但我想提出一个有些不同的问题。
是否有任何可行的方法来实现 GC.GetAliveInstancesOf()，可以在 Visual Studio 调试监视窗口中进行评估？ Sasha Goldstein 在 本文，但它要求您要查询的每个类都继承自特定的类基类。
我要强调的是，我只想在调试期间使用此方法，因此我不关心 GC 可能会在运行时更改对象在内存中的地址。
一种想法可能是以某种方式利用 SOS 的 !dumpheap –type 命令，并执行一些魔术来创建一个临时变量并让它指向 SOS 打印的内存地址。
有人有有效的解决方案吗？
I know this was answered before, but I'd like to pose a somewhat different question.
Is there any conceivable way to implement GC.GetAliveInstancesOf(), that can be evaluated in Visual Studio Debug Watch window? Sasha Goldstein shows one solution in this article, but it requires every class you want to query inherit from a specific base class.
I'll emphasize that I only want to use this method during debugging, so I don't care that the GC may change an object's address in memory during runtime.
One idea might be to somehow harness the !dumpheap –type command of SOS, and do some magic trick to create a temporary variable and have it point out to the memory address printed by SOS.
Does anyone have a solution that works?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看起来与此非常相似的东西是由 Alois Kraus 实现的在WMemoryProfiler 项目中。
It looks like something very similar to this was implemented by Alois Kraus in the WMemoryProfiler project.
没有什么比垃圾收集器不得不事后猜测某种用户代码可能有兴趣寻找它不拥有的根更能拖累垃圾收集器的了。尽可能保持敏捷是至关重要的。就此而言，您能够以某种信心看到正在引用的内容的唯一方法是冻结可能从垃圾收集堆中分配内存的所有线程。
嗯，这是可能的，调试器就是这样做的。您已经了解 Windbg 的工作方式。然而，它并不是被设计为一个经过优化以跟踪托管对象的工具。还有其他工具：内存分析器。有很多可供选择，不要尝试构建自己的。从免费软件（并且浪费时间）CLR Profiler，到像 Ants 和 dotTrace 等第三方产品以及许多其他产品。几百块钱就能解决你的问题，你自己不可能用更少的钱做得更好。
There is just about nothing that could drag down the garbage collector more than it having to second-guess that some kind of user code could be interested in finding roots that it doesn't own. Keeping it as snappy as possible is crucial. For that matter, the only way you could ever see what is being referenced with some kind of confidence is to freeze all threads that might be allocating memory from the garbage collected heap.
Well, that's possible, debuggers do that. You already know the way Windbg does it. It however wasn't designed to be a tool that was optimized to track managed objects. There are other tools that were: memory profilers. Plenty to choose from, don't try to build your own. From the freeware (and time-wasting) CLR Profiler, to the 3rd party offerings like Ants and dotTrace and many others. A couple of hundred bucks to solve your problem, there is no way you can do better by yourself for less.