下面会涉及到一些底层的函数库以及系统调用，不想看过程的直接跳到最后看结论好了。
一段代码，通过 tail -f 看打的 log，发现很长时间都没有输出，然后突然一下子输出了好多条，猜想可能跟 buffer 之类的有关系。这个问题其实很早就遇到过，最初以为是什么 bug，直到看到自己写的代码也出现类似的现象之后才决定看看是怎么回事。
先来看看下面这一小段代码。
$ cat demo1.py
import time, sys
for i in range(50):
sys.stdout.write("test")
time.sleep(0.2)
$ python demo1.py
testtesttesttesttesttes……ttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest$
可以看到，这堆 test 字符串是等了若干秒之后一下子输出的。
如果我们把 sys.stdout.write("test") 改为 sys.stdout.write("testn") 即加上换行符号，或者使用 print 函数来输出，发现现象不一样了:
$ cat demo2.py
import time, sys
for i in range(50):
sys.stdout.write("testn")
time.sleep(0.2)
$ python demo2.py
test
test
test
test
test
…
$ cat demo3.py
import time, sys
for i in range(50):
print "test"
time.sleep(0.2)
发现不管是 demo2 还是 demo3，屏幕上均以平均 0.2s 的频率输出 test 字符。
把 demo3 的 print "test" 换成 print "test",(结尾加一个半角逗号)再看看是什么现象。
再用 python3 的 print("test") 试试，尝试加上 end 参数比如，print("test", end="n"), print("test", end="t")，print("test", end="") 再试试有什么不同的结果。
再来看一个 demo:
$ cat demo4.py
import time, sys
for i in range(50):
sys.stdout.write("test")
sys.stdout.flush()
time.sleep(0.2)
加上 sys.stdout.flush() 看看跟上面的比有什么不同的效果。
最后一个，代码是 demo3.py，但是运行的方式不同:
$ python demo3.py > output
注意实时观察 output 文件的大小，发现并没有随时间而增大，而是 demo3.py 运行结束了之后才变化的。
上面就是之前遇到的一些现象，这里面涉及到其实是 UNIX 下面的 STDIO buffer 问题。下面会深入现象揭开本质，没时间的看最后的结论即可。
IOS C 标准定义了一套叫标准 I/O 的库，也叫 buffered I/O，这套库被包括 UNIX 在内的系统所实现，包括我们日常使用的众多发行版本。而大家熟知的 open, read, write, lseek, close 这些 I/O 系统调用函数则是 POSIX 定义的，他们通常称为 unbuffered I/O，就是为了跟标准 I/O 库作出区分。这些底层的系统调用函数，大多都是围绕 fd 展开，而标准 I/O 则是围绕着 STREAM 展开，标准 I/O 库其实可以理解为对系统 I/O 函数的封装，因为标准 I/O 库最终还是要调用对应的这些系统 I/O 函数，可以通过 fileno(FILE *FP) 获取到 STREAM 对应的 fd。
为什么说标准 I/O 库是 buffered I/O 了，因为他会自动的帮你处理 buffer 分配以及 I/O chunks 的选择，这样就不再需要为选择 block size 而操心了，这个在使用系统 I/O 调用的时候无法避免，比如 read/write 都需要考虑 buffer 地址以及读取写入的 buffer size，通常你需要在调用 read 时候定义一个 buffer size 的宏:
# define BUFFSIZE 4096
buffered I/O 的主要目的就是为了降低 read/write 这类的系统调用以及自动的为程序分配 buffer。但是他分为了下面三种类似的 buffering:
1. full buffer，当标准 I/O buffer 满了时候发生一次 flush 操作，可以调用 fflush() 来完成，他将 buffer 里面的数据 flush 到内核缓冲区中。
2. line buffer，遇到换行符(一般就是 "n") 也就是写完一行的时候发生一次 flush，
3. unbuffered，有多少读写多少。
Linux 一般是这样实现的:
1. stderr 是 unbuffered，这会让错误信息及时的出现。
2. stdin/stdout stream 如果不跟终端相关联，比如 pipe，redirect，fopen 打开的文件，则是 full buffer；如果跟终端相关联，则是 line buffer
上面这两条规则其实就是速度跟系统之间的一个 tradoff，很好理解。
可以通过 setbuf/setvbuf 来修改 buffer 的模式，具体的使用方式 man 2，需要注意的是，这两个函数要在 stream 打开之后其余 I/O 操作之前调用，让然，如果你需要做一些特殊的事情，完全可以在昨晚某些 I/O 操作之后再调用，比如下面要举的第二个 demo。setvbuf 比 setbuf 有更大的优势，比如可以修改 buffer 的大小等等。
关于 STREM 对应的 buffer 类型，其大小可以通过这段代码来做一个验证，比如我的机器的几个 buffer size 都是 8KB。
而 int fflush(FILE *fp) 这个函数就是解决我们上面问题的核心了，该函数会将当前 STREAM 中的数据 flush 到内核缓冲区，如果 fp 是 NULL，则 stdout 流被 flush 一次。准确的说，fflush 只能用于输出流，而不能用于输入流，具体的原因见这里。
这里的一个 demo 很好的解释了 fflush/setvbuf 做的事情，尝试把 setvbuf 中的 size_t size 参数从原先的 1024 调小到 20 试试看。
很明显，通过这种 buffer 的方式，把一部分的写先 buffer 起来然后统一调用一次系统调用，可以大量的减少 user space 跟 kernel space 之间的切换。
可能会有人想到 fsync 这个系统调用，它跟 fflush 做的事情好像是一样的，其实仔细辨别的，二者做的事情根本不在一个平面上。
fflush(FILE *stream) 作用的是 FILE*，对于 stdout 来说，他是将标准 IO 流的 buffer 从用户空间 flush 到内核缓存中。这也是调用 exit 要做的事情。
fsync(int fd) 控制的是何时将 data&metadata 从内核缓冲区 flush 到磁盘中，他的传入参数是一个 fd。对 fsync 来说，FILE* 是透明的也就是所他并不知道 FILE* 的存在，一个是在 user space 一个是在 kernel space。
所以，如果我们不想有 full/line buffer 而是尽可能快的获取到输出流的话，就需要通过调用 fflush(stdout) 指明。
上面解释的仅仅是 C 的，对于 Python 而言，底层调用的东西几乎一样，Python 它自己通过 C 实现了 fflush()，具体的代码可以看这里。其实不单单是 fflush，不少包括 read/write 在内的底层调用 Python 都是用 C 实现的。
对用到 Python 的 fflush 则是 sys.stdout.flush()。
不管是 fflush() 还是 sys.stdout.flush()，都需要对立即返回的 stdout 手动的调用，比较麻烦。所幸的，上面提到的 setvbuf 就可以直接帮我们做这件事，在 stream 打开后调用 setvbuf() 即可，其 mode 参数可以选择下面三种:
1. _IOLBF，line buffer
2. _IOFBF, full buffer
3. _IONBF，no buffer
要完全禁用的话按照下面这种方式调用:
setvbuf(stdout, 0, _INNBF, 0);
对应到 python 的，至少还有下面的几种方式可以避免此类问题:
1. 直接关闭 stdout 的 buffer，类似 setvbuf:
sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
2. 有个比较 ugly 的方式，把输出流改到 stderr 上，这样不管什么时候都能保证尽快的输出。
3. 直接脚本的时候加上 -u 参数。但是需要注意下，xreadlines(), readlines() 包含一个内部 buffer，不受 -u 影响，因此如果通过 stdin 来遍历会出现问题，可以看看这两个连接提供的内容(1, 2)。
4. 将其 stream 关联到 pseudo terminal(pty) 上，script 可以做这事情的:
script -q -c "command1" /dev/null | command2
或者通过 socat 这个工具实现，
再来看个跟 pipe 相关的问题， 这个命令常常回车之后没有反应:
$ tail -f logfile | grep "foo" | awk {print $1}
tail 的 stdout buffer 默认会做 full buffer，由于加上了 -f，表示会调用 fflush() 对输出流进行 flush，所以 tail -f 这部分没什么问题。关键在 grep 的 stdout buffer，因此它存在一个 8KB stdout buffer，要等该 buffer 满了之后 awk 才会接收到数据。awk 的 stdout buffer 跟终端相关联，所有默认是 line buffer。怎么解决这个问题了，其实 grep 提供了 –line-buffered 这个选项来做 line buffer，这会比 full buffer 快的多:
tail -f logfile | grep –line-buffered "foo" | awk {print $1}
除了 grep，sed 有对应的 -u(–unbuffered)，awk(我们默认的是 mawk) 有 -W 选项，tcpdump 有 -l 选项来将 full buffer 变成 line 或者 no buffer。
不仅仅是 stdin/stdout/stderr 有 buffer 问题，pipe 同样有 buffer 的问题，相关的文档可以看这里(1, 2)。
上面的方式都涉及到了具体的函数调用，修改参数的不具有普遍原理，对于普通用户来说，不大可能这么操作。其实 coreutils 已经给我们提供了一个叫 stdbuf 的工具。expect 还提供了一个叫 unbuffer 的工具，通过它可以将输出流的 buffer 给禁止掉，另外，在 pipe 的应用中，可能会出现一些问题，具体的 man 一下。因此，上面的问题可以更具有普遍性:
tail -f logfile | stdbuf -oL grep "foo" | awk {print $1}
看到这里最上面的几个问题现在应该非常容易回答了。
ref:
更多信息请查看IT技术专栏