深入解析Java中Flushable接口的flush方法

今天写这篇文章是为了纪念同事讲得两句话：1、调用flush方法等于在后面对OutputStream使劲的抽一鞭子，并命令“赶紧给我写入，我的水桶太满了”；2、写入数据量不大时，可以考虑不用。

先来说说flush方法为了解决什么问题。我们都知道在Linux中，可写的句柄都是”文件“，并且，不管是Windows还是Linux都有提供相同名字的flush系统调用，而且操作系统在写文件时，先把要写的内容从用户缓冲区复制到内核缓冲区等待真正的写入到“文件”。java中的Flushable.flush()方法显然也是调用操作系统提供的接口。不管怎么调用，他们的原理都是一样的，比如要写4K大小的文件，操作系统有几种策略把字节写入到”文件“中：1、应用程序每写一个字节，操作系统马上把这个字节写入”文件“。2、应用程序写入字节后，操作系统不马上写入，而是先把它缓存起来，到达一定数量时才写入”文件“。3、应用程序写入字节后，没有到达可写的字节数量时，操作系统不写入，而是由应用程序控制。

我们先来看第一种策略，这种策略对操作系统来讲，显然效率太低，不可取。第二种策略，为了弥补第一种策略的不足，达到一定数量时才写入，可以提高系统利用率，现代大部分操作系统也都这样实现的。那么问题来了，当写入一定数量的字节后，虽然还没有达到操作系统可写入的数量，但是应用程序有这个需求说，我得马上写入。那怎么办？为了应对这种策略，操作系统提供了flush系统调用，让应用程序可以控制何时马上写入文件。这也是第三种策略。

说到这里，有的人可能有疑问，那应用程序写入字节数不足以达到操作系统要写入的数量，而且没有调用flush方法，那这些字节是不是就丢失了？答案是否定的，当打开一个文件句柄，不管写入多少字节的内容，在调用close方法时，系统会自动写入未写的内容，很多操作系统的close方法实现中就有调用flush方法的部分。

此时我们再回过头来看看同事讲的两句话。第一句话的前半句是对的，至于“我的水桶太满了”，同事的意思是说，调用flush方法就是为了水桶太满，这显然违背事实的。水桶达到一定高度时操作系统会排光水而空出桶的空间以备继续接收水。至于第二句话，如果数据量不大，而急需把内容写到“文件”中，此时，必须调用flush方法，除非close掉文件句柄。

最后要注意一点，当操作系统内核缓冲区中还有未写入的字节，而此时系统奔溃或者断电等情况，那么这部分内容也就丢失了。所以要不要调用flush方法，要看具体的需求，笔者认为大部分时候没有必要调用flush方法。频繁的调用flush方法会降低系统性能，举个极端的例子，每写入一个字节就调用一次，这显然就退化到了上面提到的第一种策略。