File.Create 查询答案

【问题标题】：File.Create queriesFile.Create 查询
【发布时间】：2015-04-15 09:43:07
【问题描述】：

我最近遇到了this post，其中标记的答案是 Jon Skeet。他在其中解释了创建空文件的不同方法，例如：

using (File.Create(filename)) ;

using (File.Create(filename)) {}

File.Create(filename).Dispose();

然后还有另一种人们推荐使用的方法：

File.Create(filename).Close();

现在，Jon 的回答详细说明了使用哪一个以及为什么等。但是答案已经过时/过时，并且没有像我想要的那样详细说明哪一个更适合确保文件已关闭，为什么。

【问题讨论】：

我有点喜欢其他答案之一，使用带有空字符串的File.WriteAllText。它在底层的效率可能略低，但它将处理留给框架代码，而不是需要显式调用或通过任何类型的诡计。（如果我在生产代码中看到 using 块方法，它可能需要双重处理才能完全理解它。可能会稍微更有效率，但这种双重处理可能会导致对代码行为和未来错误的误解。）
是的，这是问这个问题的主要原因，因为我在遗留项目中找到了该代码并正在研究它。但是我自己发现此实例中的 WriteAllText 方法更令人困惑。
Jon 的最佳建议是将整个事情包装在一个恰当命名的方法中。事后运行性能测试、竞争条件测试等，根据需要调整到字节（如果需要的话）。但只要功能存在于一个具有好名字的抽象位置，那么使用它的其余生产代码将是清晰易懂的。
我想，但主要是想知道每个方法的实际功能，因为在方法中使用它很好。但如果每次我们回到原点时都失败了，只需更改更少的代码。

标签： c# file io

【解决方案1】：

答案绝对不会过时。您可以通过对公开参考source code 中FileStream.Dispose 方法的实际实现的一些研究来检查FileStream 的Dispose 方法将执行对handle.Dispose 的调用，并执行一个其他操作的数量。

FileStream 类不会覆盖在其基类中实现的虚拟Stream.Close() 方法的实现。这个基类目前只会调用虚拟Dispose(true)，因此会导致相同的路径。

如Close 方法的文档中所述：

该方法调用Dispose，指定true释放所有资源。您不必专门调用 Close 方法。相反，确保每个 Stream 对象都被正确处理。您可以声明 Stream using 块（或 Visual Basic 中的 Using 块）中的对象确保处理流及其所有资源，或者您可以显式调用 Dispose 方法。

尽管如此，当您使用 IDisposable 实例时，您始终应该调用 Dispose¹，因为它可以（现在或将来某个时间） ) 持有除文件句柄之外的其他内部资源，如果您仅在 FileStream 实例上调用 Close，这些资源将不会被释放。

话虽如此，确保正确处理的静态文件创建方法（例如 File.WriteAllBytes 或 File.WriteAllText）也可以使用。但是 - 在我看来 - 这些感觉很尴尬并且不能很好地表达意图。

按照原始答案中的建议，将其包装在名为 CreateEmptyFile 的静态方法或带有单个方法 Create 的静态类 EmptyFile 中，可以明确您的意图。

¹ 这应该理解为直接调用Dispose 或（最好）将资源包装在using 块中。

【讨论】：

我明白这一点，但是 Dispose 调用是否总是不会被调用？那么在这种情况下应该总是使用 using 吗？不管它看起来多么奇怪？
在我看来，如果您通过调用某个类的方法来请求一次性实例，则您有责任在其上调用Dispose。
负责任是的，但是被称为 dispose 的 self 没有机会实际上不会被调用吗？比如说在线程情况下？
任何与线程相关的东西怎么会干扰像using(File.Create("abc.ext"));这样的调用？
这就是我的意思，你会不会这样做而不是 .Dispose？还是我误解了你的意思？