在進行本地 file 文件內(nèi)容讀取，或進行 HTTP 網(wǎng)絡(luò)接口通信的時候，我們經(jīng)常使用 io.ReadAll 來讀取遠(yuǎn)程接口返回的 resp.Body，但接口返回數(shù)據(jù)量有大有小，io.ReadAll 是怎樣完成全部數(shù)據(jù)的讀取的？
帶著此疑問，讓我們走近 io.ReadAll 源碼一探究竟：
1. Demo 讀取文件內(nèi)容
package main
import (
"fmt"
"io"
"os"
)
func main() {
// 讀取文件內(nèi)容
fileInfo, err := os.Open("./abc.go")
if err != nil {
panic(err)
}
contentBytes, err := io.ReadAll(fileInfo)
if err != nil {
panic(err)
}
fmt.Println(string(contentBytes))
}
此時讀取的 io stream 大小并不知道，io.ReadAll 使用什么策略讀取全部數(shù)據(jù)呢？滑動窗口？線性/指數(shù)遞增讀??？Talk is cheap. Show me the code.
2. io.ReadAll Code
go1.16/src/io/io.go#L626
// ReadAll reads from r until an error or EOF and returns the data it read.
// A successful call returns err == nil, not err == EOF. Because ReadAll is
// defined to read from src until EOF, it does not treat an EOF from Read
// as an error to be reported.
func ReadAll(r Reader) ([]byte, error) {
b := make([]byte, 0, 512)
for {
if len(b) == cap(b) {
// Add more capacity (let append pick how much).
b = append(b, 0)[:len(b)]
}
//println(cap(b))
n, err := r.Read(b[len(b):cap(b)])
b = b[:len(b)+n]
if err != nil {
if err == EOF {
err = nil
}
return b, err
}
}
}
源碼解析：
從上面源碼可以看到，使用 make 先默認(rèn)申請 cap = 512 的 []byte，然后進入 for 循環(huán)迭代，直到數(shù)據(jù)全部讀取完成。for 循環(huán)中，首先通過 len(b) == cap(b) 判斷 b 的容量是否滿了，如果已經(jīng)滿了，使用 append(b, 0) 追加一個元素，此時會發(fā)生什么呢？
我們知道，一個 slice 容量不夠了需要擴容，但擴容機制是怎樣的呢？繼續(xù) Show me the code.
3. slice 擴容機制
go1.16/src/runtime/slice.go#L125
// growslice handles slice growth during append.
// It is passed the slice element type, the old slice, and the desired new minimum capacity,
// and it returns a new slice with at least that capacity, with the old data
// copied into it.
// The new slice's length is set to the old slice's length,
// NOT to the new requested capacity.
// This is for codegen convenience. The old slice's length is used immediately
// to calculate where to write new values during an append.
// TODO: When the old backend is gone, reconsider this decision.
// The SSA backend might prefer the new length or to return only ptr/cap and save stack space.
func growslice(et *_type, old slice, cap int) slice {
...
newcap := old.cap
doublecap := newcap + newcap
//println("newcap: ", newcap)
//println("cap: ", cap)
if cap > doublecap {
newcap = cap
} else {
if old.cap < 1024 {
newcap = doublecap
} else {
// Check 0 < newcap to detect overflow
// and prevent an infinite loop.
for 0 < newcap && newcap < cap {
newcap += newcap / 4
}
// Set newcap to the requested cap when
// the newcap calculation overflowed.
if newcap <= 0 {
newcap = cap
}
}
}
...
}
源碼解析：
從上面源碼可以看到，slice 擴容算法為：
1). 當(dāng)需要的容量(cap)超過原切片容量的兩倍(doublecap)時，會使用需要的容量作為新容量(newcap)；
2). 當(dāng)原切片容量 < 1024 時，新切片的容量(newcap)會直接翻倍(doublecap)；
3). 當(dāng)原切片容量 >= 1024 時，會按原切片容量反復(fù)地增加 1/4，直到新容量(newcap)超過所需要的容量；
舉例說明：
在上面 io.ReadAll 源碼中，初始 slice cap = 512，后面擴容將會：
512
1024(doublecap)
1280(1024 + 1024/4)
1600(1280 + 1280/4)
2000(1600 + 1600/4)
...
實際擴容 cap 是這樣的嗎？讓我們驗證一下：
before newcap: 1024
-after newcap: 1024
before newcap: 1280
-after newcap: 1280
before newcap: 1600
-after newcap: 1792
before newcap: 2240
-after newcap: 2304
奇怪？發(fā)現(xiàn) after newcap 并沒有按照上面預(yù)想的值擴容，仔細(xì)挖代碼，發(fā)現(xiàn)除了按照上面 slice cap擴容外，還對內(nèi)存分配進行了“對齊”：
go1.16/src/runtime/slice.go#L198
println("before newcap: ", newcap)
var overflow bool
var lenmem, newlenmem, capmem uintptr
// Specialize for common values of et.size.
// For 1 we don't need any division/multiplication.
// For sys.PtrSize, compiler will optimize division/multiplication into a shift by a constant.
// For powers of 2, use a variable shift.
switch {
...
case isPowerOfTwo(et.size):
var shift uintptr
if sys.PtrSize == 8 {
// Mask shift for better code generation.
shift = uintptr(sys.Ctz64(uint64(et.size))) & 63
} else {
shift = uintptr(sys.Ctz32(uint32(et.size))) & 31
}
lenmem = uintptr(old.len) << shift
newlenmem = uintptr(cap) << shift
capmem = roundupsize(uintptr(newcap) << shift) // 進入到內(nèi)存塊(memory block)分配
overflow = uintptr(newcap) > (maxAlloc >> shift)
newcap = int(capmem >> shift)
...
}
println("after newcap: ", newcap)
進入到內(nèi)存塊(memory block)分配：
go1.16/src/runtime/msize.go#L13
// Returns size of the memory block that mallocgc will allocate if you ask for the size.
func roundupsize(size uintptr) uintptr {
if size < _MaxSmallSize {
if size <= smallSizeMax-8 {
return uintptr(class_to_size[size_to_class8[divRoundUp(size, smallSizeDiv)]])
} else {
return uintptr(class_to_size[size_to_class128[divRoundUp(size-smallSizeMax, largeSizeDiv)]])
}
}
if size+_PageSize < size {
return size
}
return alignUp(size, _PageSize)
}
獲取 spanClass 對應(yīng)的 size：
go1.16/src/runtime/sizeclasses.go#L84
const (
_NumSizeClasses = 68
)
var class_to_size = [_NumSizeClasses]uint16{0, 8, 16, 24, 32, 48, 64, 80, 96, 112, 128,
144, 160, 176, 192, 208, 224, 240, 256, 288, 320, 352, 384, 416, 448, 480, 512, 576, 640,
704, 768, 896, 1024, 1152, 1280, 1408, 1536, 1792, 2048, 2304, 2688, 3072, 3200, 3456,
4096, 4864, 5376, 6144, 6528, 6784, 6912, 8192, 9472, 9728, 10240, 10880, 12288, 13568,
14336, 16384, 18432, 19072, 20480, 21760, 24576, 27264, 28672, 32768}
從上面 68 類 spanClass 可以看到，我們想要分配 1600 被對齊到了 1792，2240 被對齊到了 2304，符合下面的驗證結(jié)果：
before newcap: 1024
-after newcap: 1024
before newcap: 1280
-after newcap: 1280
before newcap: 1600
-after newcap: 1792
before newcap: 2240
-after newcap: 2304
4. 小結(jié)
從上面的源碼分析可以看到，io.ReadAll 通過使用 slice append 自動擴容 + 內(nèi)存對齊機制，使用增加的容量來實現(xiàn)對 io stream 的全部讀取。slice append 擴容算法為：
1). 當(dāng)需要的容量(cap)超過原切片容量的兩倍(doublecap)時，會使用需要的容量作為新容量(newcap)；
2). 當(dāng)原切片容量 < 1024 時，新切片的容量(newcap)會直接翻倍(doublecap)；
3). 當(dāng)原切片容量 >= 1024 時，會按原切片容量反復(fù)地增加 1/4，直到新容量(newcap)超過所需要的容量；
后面將會有更多系列文章，解讀內(nèi)存分配、GC 機制、GPM 調(diào)度、面試系列、K8s 系列、etcd 系列等，如有錯誤懇請指正。最后，祝大家端午節(jié)快樂～
