IO.File 一个有有趣的依赖问题

前端之家收集整理的这篇文章主要介绍了IO.File 一个有有趣的依赖问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

  System.IO.FileStream类型允许用户打开文件进行读写操作。为了提高性能,该类型的实现使用了内存缓冲区。只有在内存缓冲区充满时,System.IO.FileStream类型才会将缓冲区中的数据刷新到文件中。FileStream类型只支持字节的读写操作。如果我们希望支持字符或者字符串的读写操作,可以使用System.IO.BinaryWriter类型,下面的代码对此进行了演示:

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

StreamWriter sw = new StreamWriter(fs);

sw.Write("Hi there");

//下面对Close的调用是我们应该做的

sw.Close();

//注意:调用BinaryWriter.Close会同时关闭其使用的FileStream对象

//而FileStream对象不需要显式地关闭

  注意StreamWriter的构造器接受一个Stream对象的引用作为参数,允许FileStream对象的引用作为参数进行传递。BinaryWriter对象内部会保持Stream对象的引用。当我们向一个StreamWriter对象写入数据时,它会将数据缓存在自己的内存缓冲区中。当StreamWriter对象的内存缓冲区充满时,StreamWriter对象才会将数据写入Stream对象。

  通过StreamWriter对象进行数据写入的操作执行完毕时,应该调用其上的Dispose方法或Close方法。(由于StreamWriter实现了释放模式,所以我们也可以使用C#的using语句。)这两个方法的行为相同,都会导致StreamWriter对象将其内存缓冲区中的数据填充到Stream对象中,同时关闭Stream对象。当Stream对象被关闭时,它会首先将自己缓冲区中的内容填充到磁盘文件中,然后才会调用CloseHandle函数

注意:不必显式地调用FileStream对象的Dipose方法或Close方法,因为StreamWriter已经为我们做了这件事。如果显式调用Dispose或者Close方法,FileStream会发现对象已经执行了资源清理,Dispose或Close方法将不再执行任何操作而直接返回。


  如果不是显式调用Dispose或Close方法会出现什么情况呢?我们知道,在某些时刻,垃圾收集齐能够正确地检测出对象是否已经成为可收集的垃圾,如果是,垃圾收集齐将对他们执行终结操作。但是垃圾收集器并不能保证多个对象上的Finalize方法的执行顺序,所以如果FileStream对象首先被执行终结操作,它将关闭文件。然后,当StreamWriter对象被执行终结操作时。它将试图向一个已关闭文件中写入数据,这自然会抛出异常。但是,从另一个方面来说,如果是StreamWriter对象首先被执行终结,其中的数据会被安全地写入到文件中。

  Microsoft如果解决这个问题的呢?使垃圾收集器以特定的顺序来执行对象终结操作显然不可能,因为对象之间可能包含着对彼此的引用,垃圾收集器根本无法正确的推断出对它们执行终结的顺序。Microsoft的解决方法是不让StreamWriter类实现Finalize方法,从而无法将缓冲区中的数据刷新到FileStream对象。这意味着如果我们忘记了显式关闭StreamWriter对象,其内存缓冲区中的数据必然会丢失。Microsoft希望开发人员能够认识到这一点,并在自己的代码中显式地调用Dispose方法或Close方法

原文链接:https://www.f2er.com/javaschema/287049.html

猜你在找的设计模式相关文章