为什么要处理一个肯定很快就会被处理的对象呢？
假设我有一个用于点击按钮的过程。
我创建了一个Graphics对象。
显然我应该把它处理掉。
using(Graphics gr__=this.CreateGraphics()) {
} 或者在try-catch-finally的finally中调用.Dispose()。
但考虑到这个过程很快就会结束。
假设我在过程本地创建它(不是全局的，也不是在使用中创建的)。但对程序来说是局部的。
那么，就像任何其他变量一样，它将在过程完成时自动处理，不是吗？
那么，为什么手动/显式地处理它对我来说很重要？
为什么我不能让它像其他变量一样自动进行垃圾回收呢？
当然，它可能会比'int‘大一点，但它可能仍然很小，不会在内存中呆很长时间，因为这个过程结束得太快了。它甚至可能是在使用结束或调用Dispose()之后，过程结束，因此我认为如果变量是过程的局部变量，它就会被释放。那么，为什么还要为Dispose()/using的显式垃圾收集而烦恼呢？
回答 4
Stack Overflow用户
发布于 2015-12-20 02:46:24
The Microsoft .NET class library provides a managed interface for GDI+ via the System.Drawing namespace. GDI+是基于C++的，并生成对非托管对象的引用。因此，处置System.Drawing命名空间的可处置对象非常重要，因为垃圾回收器不会自动处置非托管对象。这些对象可能包含执行作业的终结器；但是，您无法控制何时执行这些终结器。另外，挂起的终结器使堆变得混乱。因此，最好显式或通过using-statement调用Dispose()。
Stack Overflow用户
发布于 2015-12-20 02:19:41
这里有两个不同的概念。
- Disposing
- Garbage集合
这两个概念之间有很大的区别。
虽然Graphics在被GC收集时会被释放，但为什么要等待GC运行并增加应用程序的内存占用呢？
这是Graphics析构函数的代码。
~Graphics()
{
try
{
this.Dispose(false);
}
finally
{
// ISSUE: explicit finalizer call
// ISSUE: explicit non-virtual call
__nonvirtual (((object) this).Finalize());
}
}阅读更多
Fundamentals of Garbage Collection
Stack Overflow用户
发布于 2015-12-20 02:21:04
那么
肯定会像任何其他变量一样，在过程完成时自动处理掉，不是吗？
不幸的是，并不是所有的System.Drawing类都是这样的(编辑:阅读点数答案)
还有其他一些棘手的类，比如Bitmap，虽然它是“托管”的，但它的大小很小。所以，每当它被延迟处理时，它就会导致内存不足！
在内存泄漏发生之前丢弃一个未使用的对象是一种更好的做法。
不过细节要复杂得多。
您可以在System.Drawing中搜索有关非托管资源的更多信息以了解更多信息。
https://stackoverflow.com/questions/34373828
复制相似问题
腾讯云开发者
