输出流缓冲的意义何时缓冲 Stdout Buffering

**From : https://eklitzke.org/stdout-buffering **
**译者：李秋豪**

大多数编程语言默认提供了i/o缓冲特性，因为这会使得输出更加有效率。这些缓冲功能大都是默默工作“Just work out of the box”（译者注：参考out of box.）——直到某天他们不在正常工作，“不正常工作”是说该输出的数据不立即显示出来。这些问题大多可以调用fflush函数解决。例如sys.stdout.flush() in Python, fflush(3) in C, or std::flush in C++。

人们经常搞不清楚缓冲的规则，于是他们频繁的使用flush，这正是 cargo-cult programming.（译者注：直译是货物崇拜编程，看看挺有意思的，RMS先使用的）。在这篇文章中我会解释输出流的规则，你看过后就不会再感到困惑了；）

缓冲为什么存在？

正如上面谈到的，缓冲区可能导致输出延迟，那么它为什么存在呢？

在系统底层调用这个层次，数据是用write+文件描述符写入的，这种方法将数据写入到文件描述符对应的一个字节缓冲中。

大多数语言有着非常快的函数调用，在C/C++这种语言中调用一个函数可能只需要几个cpu周期，时间开销几乎可以忽略不计（只有在近端的情况下才会使用inline.）。然而，一个系统调用时间开销是非常可观的。在Linux上的一个系统调用可能会花费几千个cpu周期并掺杂着上下文转化.所以系统调用比用户空间里的函数调用花的时间多得多。

缓冲存在的主要目的就是为用户空间函数抵消调用系统函数的开销。当函数做很多写入操作时这非常重要——否则系统调用的时间会占程序运行时间的主要部分。

让我们考虑一下当你使用 grep在一个文件或者stdin中搜索字段。假设你在nginx日志中找一个IP地址，而在nginx日志里一行大概有100个字符。如果不使用缓冲的话，就意味着只要grep遇到了想要的ip地址，它就会调用write().，而这会接连不断的发生，并且每次写入的字符大概都在100字节。如果使用默认缓冲4096字节的话，grep会等到缓冲区满以后再调用write()清除缓冲，这大概会读入40行才发生一次（译者注：缓冲策略是写入流/文件的充分条件，不是必要的。缓冲区存在的意义就是使用“Stream-level I/O”时从缓冲区进行异步块写入/读出，这样可以在设备堵塞或者大量的写入操作的时候加快效率。如果一次只写入少量数据，内核一看没有堵塞，“干脆”就把缓冲区的内容写入了，反正放着也是放着。满缓冲在gnu library c 中定义为以任意大小的块写入流。），所以会减少大概40倍在系统调用上花的时间。不错！

如果grep程序向标准输出写入大量的数据的话，你可能都不会注意到缓冲区造成的延迟。并且如果grep只是找一个简单的字段，通常它在输出上花的时间会比寻找该字段画的时间更多。但是假如grep匹配字段发生的非常缓慢，例如每十秒钟才发生一次，那么我们可能要等400秒才能得到一个输出！（即便在开始的时候已经匹配到几个字段）

缓冲产生的问题

缓冲可能会在不知觉中造成一些问题，特别是在unix下使用管道的时候，例如，假设我们想要打印出在一个日志文件中匹配到的第一个字段，命令可能是这样的：

# BAD: grep will buffer output before sending it to head

grep RAREPATTERN /var/log/mylog.txt | head -n 1

依据前面举得例子，我们只是想要grep立即输出它第一次匹配到的字段，但是由于缓冲区的存在，grep可能要等缓冲区满后才输出给head，这会花费更多的时间。

在很多情况下，如果输出是间断的，那么缓冲区的存在可能会严重影响程序的性能，更不用说提升效率了。

什么时候程序使用缓冲

There are typically three modes for buffering:一般有三种缓冲策略：

无缓冲（unbuffered），任何读写都会立刻发生（并且会产生阻塞）。
满缓冲（fully-buffered），会使用固定大小的缓冲区，读写都是从缓冲区发生的。缓冲区不会被清除直到它被填满。
行缓冲，缓冲数据直到遇见一个换行符或者达到缓冲区的固定大小。

GNU libc (glibc) 使用以下的缓冲规则:

Stream	Type	Behavior
stdin	input	line-buffered
stdout (TTY)	output	line-buffered
stdout (not a TTY)	output	fully-buffered
stderr	output	unbuffered

正如你所看到的，stdout缓冲的策略有些特别：取决于流是不是一个交互设备（tty)。理由在于，如果stdout是一个终端的话，用户通常希望看着命令运行并等待结果输出，因此及时输出数据是必要的。另一方面，如果输出流不是终端，意味着输出可以后期输出，因此效率更加重要（满缓冲）。

其他的编程语言大多有着相同的规则，要么是因为这些语言是用了libc命令，或者它们遵循了相同的逻辑。

Setbuf

如果你在写C，你可以通过使用setbuf(3)（译者注：推荐setvbuf，参见 C语言流缓冲.）强制改变标准流的缓冲策略，你也可以在磁盘文件上使用这个函数，这样你就可以在使用像fprintf这样的函数的时候自动是行缓冲。

Stdbuf

GNU的源代码包中有一个 stdbuf 程序，这个程序允许你改变那些你无法控制源代码的程序的缓冲策略，但是也有几个限制：这个程序必须使用的是C的文件指针流即FILE* ，并且这个程序不能使用了专门的缓冲策略函数例如上面提到的Stdbuf.

C++ IOStreams

在C++程序里经常会看到另外一个问题，很多C++程序员习惯于使用 std::endl 来输出新的行，例如：

// Two ways to print output with a newline ending.

std::cout << "Hello, world!\n";

std::cout << "Hello, world!" << std::endl;

这两行是不一样的。关键在于std::endl会自动强制清除输出流缓冲，不管之前它采取的是什么缓冲策略。

// Subject to normal buffering rules.

std::cout << "Hello, world!\n";

// These are equivalent and are *always* line-buffered.

std::cout << "Hello, world!\n" << std::flush;

std::cout << "Hello, world!" << std::endl;

因此，如果你大量使用 std::endl ，那么实际上缓冲策略并没有起作用—— std::endl 每次都在强制清除缓冲区！如果你在写一个很注重性能的程序这可能会很重要，因为这会不经意间导致缓冲不起作用。

我的建议是，仅仅在你真的需要清除缓冲区输出数据的时候才使用 std::endl ，如果你不认为必须清除缓冲区，那么就使用正常的输出和一个\n吧。