An Interesting Dependency Issue

The System.IO.FileStream type allows the user to open a file for reading and writing. To improve performance, the type's implementation makes use of a memory buffer. Only when the buffer fills does the type flush the contents of the buffer to the file. A FileStream supports the writing of bytes only. If you want to write characters and strings, you can use a System.IO.StreamWriter, as is demonstrated in the following code:

使用FileStream类和StreamWriter类进行文件操作相比大家都不陌生，直接看代码：

FileStream fs = new FileStream("DataFile.dat", FileMode.Create);

StreamWriter sw = new StreamWriter(fs);

sw.Write("Hi there");

// The following call to Close is what you should do.

sw.Close();

// NOTE: StreamWriter.Close closes the FileStream;

// the FileStream doesn't have to be explicitly closed.

Notice that the StreamWriter's constructor takes a reference to a Stream object as a parameter, allowing a reference to a FileStream object to be passed as an argument. Internally, the StreamWriter object saves the Stream's reference. When you write to a StreamWriter object, it internally buffers the data in its own memory buffer. When the buffer is full, the StreamWriter object writes the data to the Stream. When you're finished writing data via the StreamWriter object, you should call Dispose or Close. (Because the StreamWriter type implements the dispose pattern, you can also use it with C#'s using statement.) Both of these methods do exactly the same thing: cause the StreamWriter object to flush its data to the Stream object and close the Stream object. In my example, when the FileStream object is closed, it flushes its buffer to disk just prior to calling the Win32 CloseHandle function.

注意：当你结束文件操作的时候，必须显式的调用StreamWriter的Dispose或者Close 方法（当然是用Using语句也是一样的）。

Note You don't have to explicitly call Dispose or Close on the FileStream object because the StreamWriter calls it for you. However, if you do call Dispose/Close explicitly, the FileStream will see that the object has already been cleaned up—the methods do nothing and just return.

注意：你不需要显式的调用FileStream对象的Dispose或者Close，因为StreamWriter内部已经替你完成这一步了。当然你也可以显示的去Close, 反正结果是一样的。

What do you think would happen if there were no code to explicitly call Dispose or Close? Well, at some point, the garbage collector would correctly detect that the objects were garbage and finalize them. But the garbage collector doesn't guarantee the order in which the Finalize methods are called. So if the FileStream object were finalized first, it would close the file. Then when the StreamWriter object was finalized, it would attempt to write data to the closed file, throwing an exception. If, on the other hand, the StreamWriter object were finalized first, the data would be safely written to the file.

然后问题就来了，如果你没有显式的去Close其实任何一个对象，会发生什么事情呢？

How was Microsoft to solve this problem? Making the garbage collector finalize objects in a specific order would have been impossible because objects could contain references to each other, and there would be no way for the garbage collector to correctly guess the order in which to finalize these objects.

Here is Microsoft's solution: the StreamWriter type does not implement a Finalize method, missing the opportunity to flush the data in its buffer to the underlying FileStream object. This means that if you forget to explicitly close the StreamWriter object, data is guaranteed to be lost. Microsoft expects developers to see this consistent loss of data and fix the code by inserting an explicit call to Close/Dispose.

好吧，微软是这么干的。微软很稳定保证你无法写入数据，以强制让你回去修改代码保证有Close StreamWriter 。