Go語言在進(jìn)行文件操作的時候，可以有多種方法。最常見的比如直接對文件本身進(jìn)行Read和Write； 除此之外，還可以使用bufio庫的流式處理以及分片式處理；如果文件較小，使用ioutil也不失為一種方法。
面對這么多的文件處理的方式，那么初學(xué)者可能就會有困惑：我到底該用那種？它們之間有什么區(qū)別？筆者試著從文件讀取來對go語言的幾種文件處理方式進(jìn)行分析。
os.File、bufio、ioutil比較
效率測試
文件的讀取效率是所有開發(fā)者都會關(guān)心的話題，尤其是當(dāng)文件特別大的時候。為了盡可能的展示這三者對文件讀取的性能，我準(zhǔn)備了三個文件，分別為small.txt，midium.txt、large.txt，分別對應(yīng)KB級別、MB級別和GB級別。
這三個文件大小分別為4KB、21MB、1GB。其中內(nèi)容是比較常規(guī)的json格式的文本。
測試代碼如下:
//使用File自帶的Read
func read1(filename string) int {
fi, err := os.Open(filename)
if err != nil {
panic(err)
}
defer fi.Close()
buf := make([]byte, 4096)
var nbytes int
for {
n, err := fi.Read(buf)
if err != nil err != io.EOF {
panic(err)
}
if n == 0 {
break
}
nbytes += n
}
return nbytes
}
read1函數(shù)使用的是os庫對文件進(jìn)行直接操作，為了確定確實都到了文件內(nèi)容，并將讀到的大小字節(jié)數(shù)返回。
//使用bufio
func read2(filename string) int {
fi, err := os.Open(filename)
if err != nil {
panic(err)
}
defer fi.Close()
buf := make([]byte, 4096)
var nbytes int
rd := bufio.NewReader(fi)
for {
n, err := rd.Read(buf)
if err != nil err != io.EOF {
panic(err)
}
if n == 0 {
break
}
nbytes += n
}
return nbytes
}
read2函數(shù)使用的是bufio庫，操作NewReader對文件進(jìn)行流式處理，和前面一樣，為了確定確實都到了文件內(nèi)容，并將讀到的大小字節(jié)數(shù)返回。
//使用ioutil
func read3(filename string) int {
fi, err := os.Open(filename)
if err != nil {
panic(err)
}
defer fi.Close()
fd, err := ioutil.ReadAll(fi)
nbytes := len(fd)
return nbytes
}
read3函數(shù)是使用ioutil庫進(jìn)行文件讀取，這種方式比較暴力，直接將文件內(nèi)容一次性全部讀到內(nèi)存中，然后對內(nèi)存中的文件內(nèi)容進(jìn)行相關(guān)的操作。
我們使用如下的測試代碼進(jìn)行測試：
func testfile1(filename string) {
fmt.Printf("============test1 %s ===========\n", filename)
start := time.Now()
size1 := read1(filename)
t1 := time.Now()
fmt.Printf("Read 1 cost: %v, size: %d\n", t1.Sub(start), size1)
size2 := read2(filename)
t2 := time.Now()
fmt.Printf("Read 2 cost: %v, size: %d\n", t2.Sub(t1), size2)
size3 := read3(filename)
t3 := time.Now()
fmt.Printf("Read 3 cost: %v, size: %d\n", t3.Sub(t2), size3)
}
在main函數(shù)中調(diào)用如下：
func main() {
testfile1("small.txt")
testfile1("midium.txt")
testfile1("large.txt")
// testfile2("small.txt")
// testfile2("midium.txt")
// testfile2("large.txt")
}
測試結(jié)果如下所示：
從以上結(jié)果可知：
- 當(dāng)文件較小（KB級別）時，ioutil > bufio > os。
- 當(dāng)文件大小比較常規(guī)（MB級別）時，三者差別不大，但bufio又是已經(jīng)顯現(xiàn)出來。
- 當(dāng)文件較大（GB級別）時，bufio > os > ioutil。
原因分析
為什么會出現(xiàn)上面的不同結(jié)果？
其實ioutil最好理解，當(dāng)文件較小時，ioutil使用ReadAll函數(shù)將文件中所有內(nèi)容直接讀入內(nèi)存，只進(jìn)行了一次io操作，但是os和bufio都是進(jìn)行了多次讀取，才將文件處理完，所以ioutil肯定要快于os和bufio的。
但是隨著文件的增大，達(dá)到接近GB級別時，ioutil直接讀入內(nèi)存的弊端就顯現(xiàn)出來，要將GB級別的文件內(nèi)容全部讀入內(nèi)存，也就意味著要開辟一塊GB大小的內(nèi)存用來存放文件數(shù)據(jù)，這對內(nèi)存的消耗是非常大的，因此效率就慢了下來。
如果文件繼續(xù)增大，達(dá)到3GB甚至以上，ioutil這種讀取方式就完全無能為力了。（一個單獨(dú)的進(jìn)程空間為4GB，真正存放數(shù)據(jù)的堆區(qū)和棧區(qū)更是遠(yuǎn)遠(yuǎn)小于4GB）。
而os為什么在面對大文件時，效率會低于bufio？通過查看bufio的NewReader源碼不難發(fā)現(xiàn)，在NewReader里，默認(rèn)為我們提供了一個大小為4096的緩沖區(qū)，所以系統(tǒng)調(diào)用會每次先讀取4096字節(jié)到緩沖區(qū)，然后rd.Read會從緩沖區(qū)去讀取。
const (
defaultBufSize = 4096
)
func NewReader(rd io.Reader) *Reader {
return NewReaderSize(rd, defaultBufSize)
}
func NewReaderSize(rd io.Reader, size int) *Reader {
// Is it already a Reader?
b, ok := rd.(*Reader)
if ok len(b.buf) >= size {
return b
}
if size minReadBufferSize {
size = minReadBufferSize
}
r := new(Reader)
r.reset(make([]byte, size), rd)
return r
}
而os因為少了這一層緩沖區(qū)，每次讀取，都會執(zhí)行系統(tǒng)調(diào)用，因此內(nèi)核頻繁的在用戶態(tài)和內(nèi)核態(tài)之間切換，而這種切換，也是需要消耗的，故而會慢于bufio的讀取方式。
筆者翻閱網(wǎng)上資料，關(guān)于緩沖，有內(nèi)核中的緩沖和進(jìn)程中的緩沖兩種，其中，內(nèi)核中的緩沖是內(nèi)核提供的，即系統(tǒng)對磁盤提供一個緩沖區(qū)，不管有沒有提供進(jìn)程中的緩沖，內(nèi)核緩沖都是存在的。
而進(jìn)程中的緩沖是對輸入輸出流做了一定的改進(jìn)，提供的一種流緩沖，它在讀寫操作發(fā)生時，先將數(shù)據(jù)存入流緩沖中，只有當(dāng)流緩沖區(qū)滿了或者刷新（如調(diào)用flush函數(shù)）時，才將數(shù)據(jù)取出，送往內(nèi)核緩沖區(qū)，它起到了一定的保護(hù)內(nèi)核的作用。
因此，我們不難發(fā)現(xiàn)，os是典型的內(nèi)核中的緩沖，而bufio和ioutil都屬于進(jìn)程中的緩沖。
總結(jié)
當(dāng)讀取小文件時，使用ioutil效率明顯優(yōu)于os和bufio，但如果是大文件，bufio讀取會更快。
讀取一行數(shù)據(jù)
前面簡要分析了go語言三種不同讀取文件方式之間的區(qū)別。但實際的開發(fā)中，我們對文件的讀取往往是以行為單位的，即每次讀取一行進(jìn)行處理。
go語言并沒有像C語言一樣給我們提供好了類似于fgets這樣的函數(shù)可以正好讀取一行內(nèi)容，因此，需要自己去實現(xiàn)。
從前面的對比分析可以知道，無論是處理大文件還是小文件，bufio始終是最為平滑和高效的，因此我們考慮使用bufio庫進(jìn)行處理。
翻閱bufio庫的源碼，發(fā)現(xiàn)可以使用如下幾種方式進(jìn)行讀取一行文件的處理：
- ReadBytes
- ReadString
- ReadSlice
- ReadLine
效率測試
在討論這四種讀取一行文件操作的函數(shù)之前，仍然做一下效率測試。
測試代碼如下：
func readline1(filename string) {
fi, err := os.Open(filename)
if err != nil {
panic(err)
}
defer fi.Close()
rd := bufio.NewReader(fi)
for {
_, err := rd.ReadBytes('\n')
if err != nil || err == io.EOF {
break
}
}
}
func readline2(filename string) {
fi, err := os.Open(filename)
if err != nil {
panic(err)
}
defer fi.Close()
rd := bufio.NewReader(fi)
for {
_, err := rd.ReadString('\n')
if err != nil || err == io.EOF {
break
}
}
}
func readline3(filename string) {
fi, err := os.Open(filename)
if err != nil {
panic(err)
}
defer fi.Close()
rd := bufio.NewReader(fi)
for {
_, err := rd.ReadSlice('\n')
if err != nil || err == io.EOF {
break
}
}
}
func readline4(filename string) {
fi, err := os.Open(filename)
if err != nil {
panic(err)
}
defer fi.Close()
rd := bufio.NewReader(fi)
for {
_, _, err := rd.ReadLine()
if err != nil || err == io.EOF {
break
}
}
}
可以看到，這四種操作方式，無論是函數(shù)調(diào)用，還是函數(shù)返回值的處理，其實都是大同小異的。但通過測試效率，則可以看出它們之間的區(qū)別。
我們使用下面的測試代碼：
func testfile2(filename string) {
fmt.Printf("============test2 %s ===========\n", filename)
start := time.Now()
readline1(filename)
t1 := time.Now()
fmt.Printf("Readline 1 cost: %v\n", t1.Sub(start))
readline2(filename)
t2 := time.Now()
fmt.Printf("Readline 2 cost: %v\n", t2.Sub(t1))
readline3(filename)
t3 := time.Now()
fmt.Printf("Readline 3 cost: %v\n", t3.Sub(t2))
readline4(filename)
t4 := time.Now()
fmt.Printf("Readline 4 cost: %v\n", t4.Sub(t3))
}
在main函數(shù)中調(diào)用如下：
func main() {
// testfile1("small.txt")
// testfile1("midium.txt")
// testfile1("large.txt")
testfile2("small.txt")
testfile2("midium.txt")
testfile2("large.txt")
}
運(yùn)行結(jié)果如下所示：
通過現(xiàn)象，除了small.txt之外，大致可以分為兩組：
- ReadBytes對小文件處理效率最差
- 在處理大文件時，ReadLine和ReadSlice效率相近，要明顯快于ReadString和ReadBytes。
原因分析
為什么會出現(xiàn)上面的現(xiàn)象，不防從源碼層面進(jìn)行分析。
通過閱讀源碼，我們發(fā)現(xiàn)這四個函數(shù)之間存在這樣一個關(guān)系：
- ReadLine - (調(diào)用) ReadSlice
- ReadString - (調(diào)用)ReadBytes-(調(diào)用)ReadSlice
既然如此，那為什么在處理大文件時，ReadLine效率要明顯高于ReadBytes呢？
首先，我們要知道，ReadSlice是切片式讀取，即根據(jù)分隔符去進(jìn)行切片。
通過源碼發(fā)下，ReadLine只是在切片讀取的基礎(chǔ)上，對換行符\n和\r\n做了一些處理：
func (b *Reader) ReadLine() (line []byte, isPrefix bool, err error) {
line, err = b.ReadSlice('\n')
if err == ErrBufferFull {
// Handle the case where "\r\n" straddles the buffer.
if len(line) > 0 line[len(line)-1] == '\r' {
// Put the '\r' back on buf and drop it from line.
// Let the next call to ReadLine check for "\r\n".
if b.r == 0 {
// should be unreachable
panic("bufio: tried to rewind past start of buffer")
}
b.r--
line = line[:len(line)-1]
}
return line, true, nil
}
if len(line) == 0 {
if err != nil {
line = nil
}
return
}
err = nil
if line[len(line)-1] == '\n' {
drop := 1
if len(line) > 1 line[len(line)-2] == '\r' {
drop = 2
}
line = line[:len(line)-drop]
}
return
}
而ReadBytes則是通過append先將讀取的內(nèi)容暫存到full數(shù)組中，最后再copy出來，append和copy都是要消耗內(nèi)存和io的，因此效率自然就慢了。其源碼如下所示：
func (b *Reader) ReadBytes(delim byte) ([]byte, error) {
// Use ReadSlice to look for array,
// accumulating full buffers.
var frag []byte
var full [][]byte
var err error
n := 0
for {
var e error
frag, e = b.ReadSlice(delim)
if e == nil { // got final fragment
break
}
if e != ErrBufferFull { // unexpected error
err = e
break
}
// Make a copy of the buffer.
buf := make([]byte, len(frag))
copy(buf, frag)
full = append(full, buf)
n += len(buf)
}
n += len(frag)
// Allocate new buffer to hold the full pieces and the fragment.
buf := make([]byte, n)
n = 0
// Copy full pieces and fragment in.
for i := range full {
n += copy(buf[n:], full[i])
}
copy(buf[n:], frag)
return buf, err
}
總結(jié)
讀取文件中一行內(nèi)容時，ReadSlice和ReadLine性能優(yōu)于ReadBytes和ReadString，但由于ReadLine對換行的處理更加全面（兼容\n和\r\n換行），因此，實際開發(fā)過程中，建議使用ReadLine函數(shù)。
到此這篇關(guān)于Go語言文件讀取的一些總結(jié)的文章就介紹到這了,更多相關(guān)Go語言文件讀取內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
您可能感興趣的文章:- GO語言常用的文件讀取方式
- go語言讀取csv文件并輸出的方法
