输出流缓冲的意义 何时缓冲 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命令,或者它们遵循了相同的逻辑。
更多关于grep的例子
Grep对于缓冲来说是一个特殊的例子,因为它能够将一个大量数据转化为缓慢并且小规模的输出。因此grep对于缓冲非常敏感。
****正如上面所说,如果grep的输出是一个交互设备(例如tty),那么输出流将会是行缓冲,如果输出到一个文件或者一个管道,那么将会是满缓冲的。
下面这个grep命令的输出将会是行缓冲,因为输出是一个交互设备(终端):
# line-buffered
grep RAREPATTERN /var/log/mylog.txt
如果stdout被重定向到一个文件而非交互设备,那么输出将会是满缓冲的。通常情况下这都是可行的:
# fully-buffered
grep RAREPATTERN /var/log/mylog.txt >output.txt
在一种情况下前面的例子不会显得理想:如果你在另一个终端输出中尝试使用tail -f
检测输出文件。
假设我们想要逆序通过管道+grep匹配子段,因为grep是最后一个命令,所以它的输出还是一个交互设备:
(译者注:tac - concatenate and print files in reverse
)
# line-buffered
tac /var/log/mylog.txt | grep RAREPATTERN
但是如果我们想要过滤grep的输出会怎样?如果我们使用一个管道,这会使得grep输出变为满缓冲。例如:
# fully-buffered
grep RAREPATTERN /var/log/mylog.txt | cut -f1
在这种情况下,grep的输出将变为pipe的文件描述符。管道不是ttys, 所以输出将变为满缓冲。
For the grep command the solution is to use the --line-buffered
option to force line-buffering:
# forced line-buffering
grep --line-buffered RAREPATTERN /var/log/mylog.txt | cut -f1
如前面提到的,你可能需要使用line-buffered参数当你重定向grep到一个文件并在另一个会话使用 tail -f
的时候。
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
吧。