Visual内存快照中的Node<Object>源

Question

我正在使用Visual诊断工具为我的应用程序做内存分析。我发现Node占用了很多内存(基于包含的大小差异)。(字节)。(见下文#1)。当我单击Node的第一个实例'Referenced‘时，我看到Node正在引用其他节点。我在属性中看到了类似于“重叠数据”的东西。

我如何才能找到这些节点是在哪里创建的，因为它们来自mscorlib.ni.dll。

​

​

​

​

Answer 1

当您在这些.NET框架对象中生根时，选择的武器是一个很好的反编译器。我用反光镜，还有其他的。

您可以看到一个不透明的Node<T>对象返回。只要在搜索框中键入它，就会弹出，但是会有几种类型使用它。大多数都在System.Collections.Concurrent命名空间中。好吧，别再看了，侧写师已经告诉你了。显然，存储节点的是System.Collections.Concurrent命名空间中的System.Collections.Concurrent类。

您的分析器告诉您，只有一个 Stack<>类对象拥有这些对象。很好，这就把它缩小到了一个单一的对象。它恰好有208个元素。嗯，嗯，没那么多，是吗？

这不是您必须停止的地方，Stack<>类是一个非常无用的类，没有人在代码中实际使用它。继续使用反编译器，让它搜索该类的用法。

啊，很好，这也是一个很短的名单。您可以看到System.Data.ProviderBase多次出现，嗯，这个问题可能与查询数据库无关。只有其他一组引用是System.PinnableBufferCache。

“针状缓冲器”，哇，这是匹配的。当您要求本机代码完成一项工作以填充托管数组时，固定缓冲区非常重要。使用BeginRead()，通用的异步I/O调用。驱动程序在处理异步I/O请求时需要对数组进行稳定的引用。获得一个稳定的缓冲区需要固定在.NET中。在分析器数据中有一个大宾果，您可以看到OverlappedData，即OverlappedData中的核心数据结构来执行异步I/O。

长话短说，你找到了这家伙的计划。程序员注意到了，但并不经常。

知道何时停止分析非常重要。您不能更改由其他程序员编写的代码。微软没有人认为那家伙做错了什么。他没有，藏起来是好事。

您绝对是done。祝贺你。