GC.Collect可以信任吗？ [英] GC.Collect can be trusted?
问题描述
我想知道GC.Collect方法是否真的收集了所有对象
可能的对象？或者这仍然是聪明的。进程有时保持
对象活着，即使它们可以被垃圾收集？
我需要知道，因为我正在寻找应用程序中的内存泄漏。
能够确定手动调用GC.Collect后的对象是否只能保持活动状态，因为它仍然是
被其他活着物体引用而不是活着
因为GC.Collect没有发现有必要收集物品，
甚至当被明确询问时。
问候，
Ward
< blockquote> 4月19日，11：37，Ward Bekker< wDotbekker @ RemoveThisequanimityDotnl>
写道：
我想知道GC.Collect方法是否真的收集了所有对象
可能的对象？或者这仍然是聪明的。进程有时保持
对象活着，即使它们可以被垃圾收集？
我需要知道，因为我正在寻找应用程序中的内存泄漏。
能够确定手动调用GC.Collect后的对象是否只能保持活动状态，因为它仍然是
被其他活着物体引用而不是活着
因为GC.Collect没有发现有必要收集物品，
甚至当被明确询问时。
问候，
Ward
我相信它试图收回所有对象。如果你有一个记忆
泄漏虽然你可能想看看CLR分析器
http://www.microsoft.com/downloads/d .. .displaylang = zh
那是1.1，底部是2.0的链接..
Ward，
使用GC.Collect来尝试识别内存泄漏并不是一个现实的解决方案。内存泄漏通常是由开发人员引起的。特别是当他们没有处理需要处理的物品时，或者如果他们不能在必要时在他们自己的物体上实施类似的模式，他们就不会处理它们。
您可以使用多种内存分析器来追踪此类型
的问题。同样，FXCop可以帮助您识别错误的编码模式。
彼得
-
网站： http://www.eggheadcafe.com
UnBlog： http://petesbloggerama.blogspot.com
短网址&更多： http://ittyurl.net
Ward Bekker写道：
我想知道GC.Collect方法是否真的收集了所有对象
可能的对象？或者这仍然是聪明的。进程有时保持
对象活着，即使它们可以被垃圾收集？
我需要知道，因为我正在寻找应用程序中的内存泄漏。
能够确定手动调用GC.Collect后的对象是否只能保持活动状态，因为它仍然是
被其他活着物体引用而不是活着
因为GC.Collect没有发现有必要收集物品，
甚至当被明确询问时。
问候，
Ward
让我解释一下。我正在使用内存分析器，看到几个
的活动对象应该在我创建内存时收集
快照。
我需要确定它们是_really_ live对象，因为我们自己的代码中有一个
错误，或者它们只是活着因为GC.Collect
可以不值得信任。
Peter Bromberg [C＃MVP]写道：
Ward，
使用GC 。收集尝试识别内存泄漏是不现实的b
解决方案。内存泄漏通常是由开发人员引起的。特别是当他们没有处理需要处理的物品时，或者如果他们不能在必要时在他们自己的物体上实施类似的模式，他们就不会处理它们。
您可以使用多种内存分析器来追踪此类型
的问题。同样，FXCop可以帮助您识别错误的编码模式。
Peter
Hi,
I''m wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?
I need to know because I''m looking for memory leaks in an application.
It would be really helpful to be able to determine if an object after
manually invoking the GC.Collect is only kept alive because it still
being referenced by other alive objects in contrast to being alive
because the GC.Collect didn''t found it necessary to collect the object,
even when asked explicitly.
Regards,
Ward
On 19 Apr, 11:37, Ward Bekker <wDotbekker@RemoveThisequanimityDotnl>
wrote:Hi,
I''m wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?
I need to know because I''m looking for memory leaks in an application.
It would be really helpful to be able to determine if an object after
manually invoking the GC.Collect is only kept alive because it still
being referenced by other alive objects in contrast to being alive
because the GC.Collect didn''t found it necessary to collect the object,
even when asked explicitly.
Regards,
WardI believe it attempts to reclaim all objects. If you''ve got a memory
leak though you might want to take a look at the CLR profiler
http://www.microsoft.com/downloads/d...displaylang=en
thats for 1.1, there''s a link for 2.0 at the bottom..
Ward,
Using GC.Collect to attempt to identify memory leaks is not a realistic
solution. Memory Leaks are generally caused by developers. Especially when
they fail to dispose of objects that need to be disposed, or if they fail to
implement similar patterns on their own objects where necessary.
There are a number of memory profilers you can use to track down this type
of issue. As well, FXCop can help you to identify bad coding patterns.
Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net
"Ward Bekker" wrote:
Hi,
I''m wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?
I need to know because I''m looking for memory leaks in an application.
It would be really helpful to be able to determine if an object after
manually invoking the GC.Collect is only kept alive because it still
being referenced by other alive objects in contrast to being alive
because the GC.Collect didn''t found it necessary to collect the object,
even when asked explicitly.
Regards,
Ward
Let me explain a bit more. I am using a memory profiler, and see several
live objects that should be collected at the time I created a memory
snapshot.
I need to be sure that they are _really_ live objects because of a
mistake in our own code, or that they just alive because the GC.Collect
can''t be trusted.
Peter Bromberg [C# MVP] wrote:Ward,
Using GC.Collect to attempt to identify memory leaks is not a realistic
solution. Memory Leaks are generally caused by developers. Especially when
they fail to dispose of objects that need to be disposed, or if they fail to
implement similar patterns on their own objects where necessary.
There are a number of memory profilers you can use to track down this type
of issue. As well, FXCop can help you to identify bad coding patterns.
Peter
这篇关于GC.Collect可以信任吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
