WinDbg - 如何判断对象是否在内存中但正在等待垃圾收集

发布于 2024-10-07 03:48:32 字数 1013 浏览 2 评论 0原文

我是 WinDbg 的新手,本周开始使用它来诊断 ASP.NET 4 应用程序中的内存泄漏。我对活动的 IIS 进程进行了内存转储,并尝试确定哪些项目可以保留在内存中,哪些则不能。例如,我在内存中看到多个 System.Web.UI 对象和一个 ASPX 页面。我得到所有对象及其地址的列表,然后运行以下命令......

!gcroot [addr]

但每次都会得到类似的结果...

0:000> !gcroot 1112f704
Note: Roots found on stacks may be false positives.
Run "!help gcroot" for more info.
Scan Thread 11 OSTHread e14
Scan Thread 29 OSTHread 2590
Scan Thread 31 OSTHread 65c
Scan Thread 32 OSTHread 2180
Scan Thread 33 OSTHread a18
Scan Thread 10 OSTHread 404
Scan Thread 35 OSTHread 12ec
Scan Thread 19 OSTHread a54
Scan Thread 3 OSTHread 251c
Scan Thread 37 OSTHread dfc
Scan Thread 38 OSTHread 1720
Scan Thread 39 OSTHread 24a8
Scan Thread 40 OSTHread 26a8
Scan Thread 41 OSTHread 2784
Scan Thread 42 OSTHread 1a24
Scan Thread 44 OSTHread 1fc8
Scan Thread 45 OSTHread 15f8
Scan Thread 47 OSTHread 2394
Scan Thread 48 OSTHread 1638

这是否表明对象仍在内存中但正在等待 GC ?大多数与我有关的对象(那些在页面呈现并发送到客户端后应处理的 UI 元素)似乎没有我能找到的根。

有什么建议或澄清吗?

I'm new to WinDbg and have started using it this week to diagnose memory leaks in an ASP.NET 4 application. I took a memory dump of an active IIS process and am trying to determine which items are ok to still be in memory and which are not. For example, I see several System.Web.UI objects in memory, and a single ASPX page. I get a list of all the objects and their addresses, then run the following command...

!gcroot [addr]

...but end up with similar results each time...

0:000> !gcroot 1112f704
Note: Roots found on stacks may be false positives.
Run "!help gcroot" for more info.
Scan Thread 11 OSTHread e14
Scan Thread 29 OSTHread 2590
Scan Thread 31 OSTHread 65c
Scan Thread 32 OSTHread 2180
Scan Thread 33 OSTHread a18
Scan Thread 10 OSTHread 404
Scan Thread 35 OSTHread 12ec
Scan Thread 19 OSTHread a54
Scan Thread 3 OSTHread 251c
Scan Thread 37 OSTHread dfc
Scan Thread 38 OSTHread 1720
Scan Thread 39 OSTHread 24a8
Scan Thread 40 OSTHread 26a8
Scan Thread 41 OSTHread 2784
Scan Thread 42 OSTHread 1a24
Scan Thread 44 OSTHread 1fc8
Scan Thread 45 OSTHread 15f8
Scan Thread 47 OSTHread 2394
Scan Thread 48 OSTHread 1638

Is this indicative of an object that is still in memory but waiting to be GCed? Most of the objects that concern me (those UI elements that should be disposed of after the page is rendered and sent to the client) seem to have no root that I can find.

Any suggestions or clarifications?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

对你而言 2024-10-14 03:48:32

是的。如果 !gcroot 命令没有返回对象的根,那么它只是在内存中等待被收集。我相信仍然有可能有一个 WeakReference 仍然保留着该对象,因此它有可能在未来重新扎根。但在 !gcroot 命令处,它就适合收集。

Yes. If the !gcroot command returns no roots for an object then it is simply in memory waiting to be collected. I believe it's possible there is still a WeakReference to still be holding onto the object though so there is the potential it will be re-rooted at a future point. But at the point of the !gcroot command it's elligable for collection.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文