避免处置系统定义的 Pen 和 Brush 实例

Question

我知道最好的做法是在 Pen 的实例上调用 Dispose() 和 画笔，除非它们'已设置为系统预定义值（例如 System.Drawing .画笔，System.Drawing.Pens 或 System.Drawing.SystemBrushes)

尝试处置系统定义的资源会导致抛出异常。

如何检测（除了将 Dispose() 调用包装在 try/catch 中之外）这些资源之一是否引用系统定义的值或用户定义的值似乎并不明显。

Answer 1

这是我知道的一个老问题，但我一直在对涉及 GDI 对象的资源泄漏进行一些研究，并且接受的答案中几乎每个陈述都是错误的。为了让后来的读者像我一样通过搜索找到这个问题的准确性：

不需要调用 Dispose。

这种说法具有误导性。虽然从技术上讲，您可以不调用 Dispose，但使用完您拥有的画笔或笔后不将其丢弃是一种非常糟糕的做法。

原因是：进程中可以突出显示的 GDI 对象的数量存在硬性限制（默认设置为一万，但可以通过注册表破解来增加）——注意，不是应用程序域——并且垃圾收集器可能无法比资源泄漏的速度更快地完成资源的完成。托管内存分配会产生收集压力，但没有相应的最终化压力。

垃圾收集的目的就是消除这些类型的要求。

它不是。垃圾收集的目的是模拟具有任意多内存的环境。

IDisposable 的主要目的之一是允许类在资源有限的环境中清理非托管资源。

这是正确的。

如果不调用Dispose()方法，则一旦对象在垃圾收集期间完成并释放，该类的非托管资源就会被清除。

这有时是正确的；对于 GDI 对象来说这是正确的。对于持有非托管资源的类来说，实现终结语义作为后盾是一种很好的做法；为遵循已接受答案中给出的不良建议的人提供额外的保护。 您不应该依赖终结器来避免错误；你应该处置你的资源。

你应该只依靠终结器来处理疯狂的异常情况。例如，

Brush myBrush = MakeMeABrush();
DoSomethingWithBrush(myBrush);
myBrush.Dispose();

假设在分配画笔之后但在分配给 myBrush 之前抛出线程中止异常。 try-catch-finally 的任何组合都无法让您通过 Dispose 清理该画笔；你必须依赖终结器。这就是终结器的作用：在完全疯狂的情况下，你无法处置自己。 这不是马虎的借口。

如果您“必须”调用 dispose 并且您不知道画笔实例是“系统”还是“普通”画笔，那么您将不得不使用 try...catch 块。

尽管这在技术上也是正确的，但它完全没有抓住重点。 如果您不知道自己是否拥有画笔，那么您的程序设计中存在错误。不要用 try-catch 块来掩盖错误！修复错误！

这种情况对于所有显式管理的资源来说都是常见的：提供资源的实体和消耗资源的实体负责清楚地记录两者中哪一个拥有清理资源。如果您不知道您是否拥有所提供的刷子，那么某人就没有完成他们本应负责的任务，即防止这种情况发生产生。

如果您决定的合同是提供资源的实体负责稍后清理它，那么您的消费者根本不应该处置刷子，因为这违反了合同；如果需要的话，生产者会清理它。

如果您决定的合同是生产者和消费者都将释放资源，那么消费者必须对传入的每个画笔调用“Clone”，以确保它们已安全可处置的资源，并且生产者也继续拥有有效的资源。

如果您决定的合同很可能是消耗资源的实体负责稍后清理资源，那么提供商需要始终为您提供可以安全处置的刷子，并且被要求不处置资源本身。由于提供者知道他们是自己制作画笔还是从系统获取画笔，因此提供者必须对系统画笔调用Clone()以获得可以安全处置的画笔，然后将那个传递给消费者。

但“没有人清理它，我们希望得到最好的结果”的合同是一份相当糟糕的合同。

不需要在 SystemBrushes 和 SystemPens 上调用 Dispose()，因为 GDI+ 库将处理这些资源。 p>

这个解释只是一个解释，实际上并没有解释任何事情。处置这些画笔之一是非法的，因为画笔的生命周期等于应用程序域的生命周期。

类的备注部分将记录是否需要调用 Dispose 方法。

这种说法是错误的。您应该假设始终需要Dispose IDisposable 资源，除非您有充分的理由不这么认为。文档中没有一行并不表明不需要进行处理。

以积极的方式结束：

如果我有一个图形密集型应用程序或类，那么我将缓存我需要的笔和画笔的实例。我在应用程序或类的整个生命周期中使用它们。

这是一个很好的做法。如果创建的画笔和笔的数量相对较少，并且一遍又一遍地使用相同的画笔和笔，那么永久缓存它们是很有意义的。由于它们的生命周期已到程序结束，因此无需处置它们。在这种情况下，我们不会处理垃圾，因为它不是垃圾；这很有用。当然，未缓存的 GDI 对象仍应被释放。再次强调，追求缓存策略并不是采取不良做法的借口。

Answer 2

当您完成创建的 Graphics 对象后，必须通过调用其 Dispose 方法来处理它。 （这条规则对于许多不同的 GDI+ 对象都是正确的。）不要保留它以备不时之需，因为它以后将不再有效。当你用完它后，你必须、必须、必须把它处理掉。如果不这样做，可能会导致图像损坏、内存使用问题，或更糟糕的是，导致国际武装冲突。因此，请正确处理所有 Graphics 对象。

如果您在事件中创建 Graphics 对象，则确实需要在退出该事件处理程序之前处理它。无法保证 Graphics 对象在以后的事件中仍然有效。此外，随时可以轻松地重新创建另一个 Graphics 对象。

从这里得到
http://msdn.microsoft.com/en-us /library/orm-9780596518431-01-18.aspx

Answer 3

首先，您始终应该尽可能丢弃刷子，而不是将其交给垃圾收集器。虽然 GDI 最终会抽出时间来处理这些事情（假设库被正确关闭），但不知道什么时候会发生。事实上，我的理解是刷柄会长期存在。在长时间运行的应用程序过程中，您会看到事实上的内存泄漏。当然，在一个不会运行很长时间的小型应用程序中，或者在一个很少创建画笔的应用程序中，您可以让系统处理它，但这让我觉得很草率。

作为一般规则，每当我创建画笔时，我都会在 using 语句中进行操作。这会自动调用画笔的处理，而不必担心它。作为额外的好处，由于您在语句内创建画笔，因此您知道它不是预定义的画笔。任何时候您创建和使用非预定义的画笔时，将块包装在 using 中，您根本不必担心它。事实上，您甚至不需要显式调用 Dispose，因为即使出现异常，块也会这样做。

Answer 4

简短的回答是，..如果您创建它，要么委派清理责任，要么自己清理对象。通过让垃圾收集器挂起，您可能会造成 GDI 资源“泄漏”。它们最终可能会被清理干净，但挂在那里并没有任何好处。即，如果您不对打开的文件调用“close”或 Dispose，则该文件将保持锁定状态，直到 GC“处理它”

Answer 5

我可能是错的，但我认为您可以假设预定义画笔和笔的生命周期（和处理）不是您的应用程序的责任，并将由系统处理。

简而言之：不要对预定义的内容调用 Dispose。 :)

Answer 6

唯一要记住的是不要使用系统笔/画笔作为方法的参数。

Answer 7

为了完整起见，使用 Reflector 我看到 System.Drawing.Pen 和 System.Drawing.SolidBrush 类有一个名为“immutable”的私有字段。

当对象引用系统定义的资源时，该字段似乎设置为 true，因此您可以使用反射仔细检查该字段的值，以决定是否对其调用 Dispose()。

Answer 8

不需要调用 Dispose。垃圾收集的目的就是消除这些要求。

IDisposable 的主要目的之一是允许类在资源有限的环境中清理非托管资源。如果不调用 dispose 方法，则一旦对象在垃圾收集期间完成并释放，该类的非托管资源将被清除。

如果您“必须”调用 dispose 并且您不知道画笔实例是“系统”还是“普通”画笔，那么您将不得不使用 try...catch 块。

• 不需要对 SystemBrushes 和 SystemPens 调用 dispose，因为 GDI+ 库将处理这些资源。
• 可以处理 SystemFonts 和 SystemIcons。

类的备注部分将记录是否需要调用Dispose方法。 如果备注部分建议调用 Dispose 方法，那么我会这样做。

一般来说，我不会对笔和画笔调用 dispose。如果我有一个图形密集型应用程序或类，那么我将缓存我需要的笔和画笔的实例。我在应用程序或类的整个生命周期中使用它们。如果我不这样做，那么尝试多次且频繁地创建和处理所有这些对象时，图形绘制性能将会受到影响。 （嗯……现在我想了一下，性能可能就是为什么我们不能处理SystemBrushes和SystemPens，但却可以处理SystemFonts和SystemIcons。甚至框架也缓存了SystemBrushes和SystemPens。）