下面會涉及到一些底層的函數庫以及系統調用，不想看過程的直接跳到最后看結論好了。
一段代碼，通過 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技術專欄
版權所有:易賢網
公眾號
事業單位
當前位置：
公考類
招聘類
各類考試