如果处理完所有方法,垃圾收集器仍然可以工作吗? [英] If all the methods are disposed, still the garbage collector will work?

查看:79
本文介绍了如果处理完所有方法,垃圾收集器仍然可以工作吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

什么是Destructor,Finalize Method和Disposed Method之间的基本区别。

解决方案

处理与垃圾收集无关,除非开发人员使用处理与GC有关的目的。如果你的意思是 System.IDispose 及其在不同类型中的实现,它只不过是一个可以用于任何事情的抽象接口。其中一个用途是处理不受GC影响的非托管资源,但这只是其中一个目的。此外,您不应该忘记一些名为 Dispose 但与 System.IDisposable 无关的方法。使用 System.IDisposable 的技巧之一是使用语句(不要与<$ c $混淆) c>使用 指令):

http://msdn.microsoft.com/en-us/library/yh598w02.aspx [ ^ ]。



一般来说, Dispose 是由应用程序代码控制的东西,无论它做什么。垃圾收集和相关的析构函数以及 Finalize 方法以一种非常不同的方式工作:它的行为不是由应用程序直接控制的。相反,GC跟踪无法访问的对象并最终回收内存,破坏它之前的对象,这会调用构造函数。 可达性的概念并不像看起来那么简单:如果3个对象在循环中相互引用,如果没有其他引用,它们仍然被检测为无法访问。请参阅:

http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science %29 [ ^ ]。



换句话说,您的应用程序API上没有免费管理内存的此类操作。回收托管内存的时刻由GC选择,从应用程序的角度来看是不可预测的。由于这两个原因,.NET应用程序中很少需要析构函数,因此应谨慎编写。使用它们的技术与非托管面向对象系统中的技术有很大不同,其中析构函数释放内存并按严格定义的顺序执行。



请参阅我过去的回答:当CLR执行自动内存管理和GC? [ ^ ]。



通常,应用程序开发人员应该主要忘记回收托管堆内存的问题,而不是试图影响对象的破坏。但是,这并不意味着在.NET中不可能出现内存泄漏。它们很有可能,但却是糟糕的通用代码设计的结果。您可以在我过去的答案中找到一些解释:

WPF DataBinding中的内存泄漏 [ ^ ],

MDI表单中的内存管理 [ ^ ],

最佳获取方式摆脱导致内存不足的公共静态列表 [ ^ ],

推迟循环中的变量会导致内存泄漏吗? [ ^ ],

Garbage collectotion负责所有内存管理 [ ^ ]。



最后,如何解释析构函数与的Finalize 。这个想法是这样的:析构函数是一些OOP语言的方法,对于OOP来说是传统的,析构函数可能会也可能不会出现在每种.NET语言中。方法 Finalize 是实际存在于 System.Object 中的方法,由于存在于较低级别CLI设计。您无法直接在C#中访问它,您应该使用析构函数语法。这在此解释:

http://msdn.microsoft.com/en -us / library / 0s71x931.aspx [ ^ ]。



有关记录:即使在C#中,您实际上也可以达到 Finalize 使用反射的方法。你可以尝试一下。



祝你好运,

-SA


< blockquote>查看此链接



析构函数vs Dispose vs Finalize? [ ^ ]



问候......


Whats is the basic difference between Destructor, Finalize Method & Disposed Method.

解决方案

Disposing has nothing to do with garbage collection, unless the developer uses disposing for some purpose related to GC. If you mean System.IDispose and its implementation in different types, it is nothing but an abstract interface which can be used for anything at all. One of the uses is disposing of unmanaged resources which cannot be affected by GC, but this is just one of the purposes. Also, you should not forget some methods which are called Dispose but are unrelated to System.IDisposable. One of the technique of using System.IDisposable is the using statement (not to be mixed up with using directive):
http://msdn.microsoft.com/en-us/library/yh598w02.aspx[^].

Generally, Dispose is something which is controlled by the application code, no matter what it does. Garbage collection and related destructor and Finalize methods work in a very different way: its behavior is not directly controlled by the application. Instead, GC tracks the unreachable objects and eventually reclaims the memory, destructing the objects before it, which calls the constructor. The concept of reachability is not as simple as it may seem: if, say, 3 objects reference each other in cycle, they are still detected as unreachable if there are no other references. Please see:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29[^].

In other words, there are no such operations on your application API which "free" managed memory. The moment of time when the managed memory is reclaimed is chosen by the GC and is unpredictable from the application perspective. By these two reasons, destructors are rarely needed in a .NET application and should be written with care. The techniques of using them are very different from the techniques in unmanaged object-oriented systems, where the destructors free memory and do it in a strictly defined order.

Please see my past answer: When CLR Do Automatic Memory Management and GC?[^].

Generally, an application developer should mainly forget the problem of reclaiming the memory of the managed heap, not trying to affect destruction of objects. However, it does not mean that memory leaks are impossible in .NET. They are quite possible, but are rather the result of bad general code design. You can find some explanations in my past answers:
Memory leak in WPF DataBinding[^],
Memory management in MDI forms[^],
Best way to get rid of a public static List Causing an Out of Memory[^],
deferring varirable inside the loop can cuase memory leak?[^],
Garbage collectotion takes care of all the memory management[^].

And finally, how to explain the destructors vs. Finalize. The idea is this: "destructor" is a method of some OOP languages, something traditional for OOP, by destructors may or may not present in each and every .NET language. The method Finalize is the method which actually exists in System.Object, something which exist on a lower level due to the CLI design. You cannot access it directly in C#, where you should use destructor syntax. This is explained here:
http://msdn.microsoft.com/en-us/library/0s71x931.aspx[^].

For a record: even in C#, you can actually reach the Finalize method using reflection. You can try it.

Good luck,
—SA


See this link

Destructor vs Dispose vs Finalize?[^]

Regards...


这篇关于如果处理完所有方法,垃圾收集器仍然可以工作吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆