是不是可以不处理MemoryStream / StringReader？

Question

我想创建一个返回XmlReader的方法。根据具体情况，可以向XmlReader提供不同类型的流，StringReader或MemoryStream。

通常我将一个StringReader或MemoryStream与一个使用块一起配置，但由于我想要返回一个XmlReader，如果我想使用这个设计，我就不能这样做。 我不希望MemoryStream分配大量的内存，所以我可以稍微延迟资源释放。

在这种情况下让GC配置StringReader和MemoryStream的后果是否可以接受？

我应该澄清这是实用问题而不是最佳实践问题。显然，这个理论要求我应该清理自己的资源分配，但理论上也说我应该选择最简单的设计来实现最大的可维护性。在某些情况下，打破最佳实践可以证明IMHO是合理的，我的问题是这个具体案例是否有理由打破最佳实践。

这也只是关于StringReader和MemoryStream的，而不是一般的流或读者。 我在这种情况下证明它的理由是，StringReader / MemoryStream的实际创建被很好地封装在返回XmlReader的方法中，因此可以控制XmlReader不会被提供有限资源的流。

Answer 1

在这种情况下，没有什么会受到影响，但IMO仍然是非常糟糕的做法。你拥有它们 - 为什么不正确呢？实际上，处理一个MemoryStream仍然无法解除分配等 - 它仍然受GC限制。但是这里有一个明显的代码味道。如果有任何变化，这可能会成为真正的问题，突然间它不是MemoryStream而是其他东西等等。

我们不能使你处理它，但个人：我对我的using

非常挑剔

Answer 2

答案：否。你应该总是处置一次性资源。在从方法返回流的情况下，处理应该由调用者完成。

Answer 3

如果您为类的显式内部使用分配资源，那么您的类负责处理该资源。如果您代表调用者分配资源，则调用者有责任管理所请求资源的生命周期。

虽然CLR最终将释放由任何对象分配的资源，但不会对何时收集（解除分配）特定对象进行任何限制。

因此，如果对象使用相对稀疏的资源（如文件句柄）并且该对象不是由创建它的代码处理的，则文件句柄将保持不可供系统或其他应用程序使用，直到垃圾收集器收集握住手柄的物体。

在单个用户桌面[机器上，您不太可能运行文件句柄，但在繁忙的服务器上，您更有可能接近可用的最大文件句柄数，并且越接近耗尽系统资源的可能性越大，机器性能就会降低，因此及时释放资源成为一个更大的问题。