处置StreamResourceInfo.Stream [英] Dispose StreamResourceInfo.Stream

问题描述

我使用StreamResourceInfo.Stream从资源中获取BitmapImage.使用后在Close和Dispose流中正确吗? 我问是因为在内存探查器中，如果执行此操作会出现错误.内存探查器表示尚未处理已处置的实例.

I use StreamResourceInfo.Stream to get BitmapImages from resources. Is it correct to Close and Dispose the stream after using it? I ask because in memory profiler, I get an error if I do so. Memory profiler says that a disposed instance has not been GCed.

如果在网上浏览，我只能找到

If I look on the web, I only can find this post to this topic. In this post, the responding person says, that it is meaninfull to dispose. However if I look at the circumstances and on the effect, I don't think that this is right. Does someone know what is the right action?
Additional information: In the msdn examples I have seen, they don't Dispose or Close.

修改
感谢Rick Sladkeys的回答，我找到了解决方案: 我将StreamResourceInfo.Stream分配给BitmapImage的StreamSource属性.在 msdn 中写道:

Edit
Thanks to Rick Sladkeys answer, I found the solution: I assign StreamResourceInfo.Stream to the StreamSource-property of the BitmapImage. In msdn is written:

如果要在创建BitmapImage之后关闭流，请将CacheOption属性设置为BitmapCacheOption.OnLoad.默认的OnDemand缓存选项将保留对流的访问，直到需要位图为止，并且清理由垃圾收集器处理.

这意味着，BitmapImage获取流的所有权.这就是为什么如果我手动关闭/处置流，内存事件探查器会显示错误的原因:位图将保留对该流的引用(BitmapCacheOption OnDemand)，因此，只要BitmapImage有效，GC便不会释放它，但是该流已经明确地处置.在此特定示例中，处置是一个不好的主意.
为了完整起见，我还在msdn中寻找了上述链接的示例，其中TextRange.Load被调用.对于Load，相反，Load不拥有所有权，因此必须在完成后关闭/处置流.

This means, BitmapImage takes the ownership of the stream. And that's why memory profiler shows an error if I Close/Dispose the stream manually: Bitmap will hold a reference to the stream (BitmapCacheOption OnDemand) and therefore GC will not release it as long as the BitmapImage is valid, but the stream is already explicitely disposed. In this specific example, disposing is a bad idead.
For completness, I have also looked in msdn for the example of the above link where TextRange.Load was called. For Load, it is the opposite, Load does not take the ownership and therefore the stream must be closed/disposed after finishing.

推荐答案

混乱(我同意这是令人困惑的)来自流的所有权的微妙但至关重要的概念.在MSDN示例中，您可以将其视为看，没有Dispose，没有Close，所以我不应该这样做吗?"

The confusion, and I agree it is confusing, comes from the subtle but critical concept of ownership of the stream. In the MSDN examples you can look at them as say "Look, no Dispose, no Close, so I'm not supposed to do that?"

但是简单的答案是，必须由某人负责关闭流.您可能正在调用的API:

But the simple answer is that somebody has to be responsible for closing the stream. The API you are probably calling:

• Application.GetResourceStream

返回StreamResourceInfo，它是流和URL的原始容器.显然，StreamResourceInfo不拥有该流.因此，当您呼叫Application.GetResourceStream 时，您现在拥有该StreamResourceInfo中包含的流，并且，如果您对它没有做任何其他事情，您将负责关闭它. Application API通过将流的值作为值返回给我们，将流的所有权从其自身转移给了我们.

returns a StreamResourceInfo that is a primitive container for a stream and an URL. Clearly the StreamResourceInfo does not own the stream. So when you call Application.GetResourceStream you now own the stream that is contained in that StreamResourceInfo and, if you did nothing else with it, you would be responsible for closing it. The Application API transfered ownership of the stream from itself to us by returning it as a value to us.

现在，当您将流传递到另一个实体时，就会出现令人困惑的部分.让我们以MSDN为例:

Now the confusing part comes in when you pass the stream to another entity. Let's take an MSDN example:

// Navigate to xaml page
Uri uri = new Uri("/PageResourceFile.xaml", UriKind.Relative);
StreamResourceInfo info = Application.GetResourceStream(uri);
System.Windows.Markup.XamlReader reader = new System.Windows.Markup.XamlReader();
Page page = (Page)reader.LoadAsync(info.Stream);
this.pageFrame.Content = page;

在此示例中，现在没有Dispose和Close.但是，有 从我们(调用方)到XamlReader实例的流的所有权转移.流已不再是我们的责任；它不再是我们的责任.我们已将所有权转让给其他人.实际上，XamlReader在处理流时确实会调用Close.一个谜解决了.

Now in this example there is no Dispose and no Close. But there is a transfer of ownership of the stream from us (the caller) to the XamlReader instance. The stream is no longer our responsibility; we have passed ownership over to someone else. In fact, XamlReader does call Close when it is done with the stream. One mystery solved.

之所以如此有问题，是因为所有权所有权的概念通常在文档中隐含，我们应该弄清楚".希望只是重新讨论所有权的概念及其可转让性，这将使在新所有者具有安全性的情况下更轻松地不打电话给Close将.即使他们不这样做，也不再是我们的问题！

The reason this is so problematic is that the concept of ownership is usually implicit in the documentation and we are supposed to "just figure it out." Hopefully just revisiting th concept of ownership and the fact that it is transferable will make it easier to feel comfortable not calling Close with the security that the new owner will. And even if they don't, it's not our problem anymore!

这篇关于处置StreamResourceInfo.Stream的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！