image

原文地址：Go Slice 最大容量大小是怎么來的

前言

在《深入理解 Go Slice》中，我們提到了 “根據(jù)其類型大小去獲取能夠申請的最大容量大小” 的處理邏輯。今天我們將更深入地去探究一下，底層到底做了什么東西，涉及什么知識點(diǎn)？

Go Slice 對應(yīng)代碼如下：

func makeslice(et *_type, len, cap int) slice {
    maxElements := maxSliceCap(et.size)
    if len < 0 || uintptr(len) > maxElements {
        ...
    }

    if cap < len || uintptr(cap) > maxElements {
        ...
    }

    p := mallocgc(et.size*uintptr(cap), et, true)
    return slice{p, len, cap}
}

根據(jù)想要追尋的邏輯，定位到了 maxSliceCap 方法，它會根據(jù)當(dāng)前類型的大小獲取到了所允許的最大容量大小來進(jìn)行閾值判斷，也就是安全檢查。這是淺層的了解，我們繼續(xù)追下去看看還做了些什么？

maxSliceCap

func maxSliceCap(elemsize uintptr) uintptr {
    if elemsize < uintptr(len(maxElems)) {
        return maxElems[elemsize]
    }
    return maxAlloc / elemsize
}

maxElems

var maxElems = [...]uintptr{
    ^uintptr(0),
    maxAlloc / 1, maxAlloc / 2, maxAlloc / 3, maxAlloc / 4,
    maxAlloc / 5, maxAlloc / 6, maxAlloc / 7, maxAlloc / 8,
    maxAlloc / 9, maxAlloc / 10, maxAlloc / 11, maxAlloc / 12,
    maxAlloc / 13, maxAlloc / 14, maxAlloc / 15, maxAlloc / 16,
    maxAlloc / 17, maxAlloc / 18, maxAlloc / 19, maxAlloc / 20,
    maxAlloc / 21, maxAlloc / 22, maxAlloc / 23, maxAlloc / 24,
    maxAlloc / 25, maxAlloc / 26, maxAlloc / 27, maxAlloc / 28,
    maxAlloc / 29, maxAlloc / 30, maxAlloc / 31, maxAlloc / 32,
}

maxElems 是包含一些預(yù)定義的切片最大容量值的查找表，索引是切片元素的類型大小。而值看起來 “奇奇怪怪” 不大眼熟，都是些什么呢。主要是以下三個(gè)核心點(diǎn)：

• ^uintptr(0)
• maxAlloc
• maxAlloc / typeSize

^uintptr(0)

func main() {
    log.Printf("uintptr: %v\n", uintptr(0))
    log.Printf("^uintptr: %v\n", ^uintptr(0))
}

輸出結(jié)果：

2019/01/05 17:51:52 uintptr: 0
2019/01/05 17:51:52 ^uintptr: 18446744073709551615

我們留意一下輸出結(jié)果，比較神奇。取反之后為什么是 18446744073709551615 呢？

uintptr 是什么

在分析之前，我們要知道 uintptr 的本質(zhì)（真面目），也就是它的類型是什么，如下：

type uintptr uintptr

uintptr 的類型是自定義類型，接著找它的真面目，如下：

#ifdef _64BIT
typedef uint64      uintptr;
#else
typedef uint32      uintptr;
#endif

通過對以上代碼的分析，可得出以下結(jié)論：

• 在 32 位系統(tǒng)下，uintptr 為 uint32 類型，占用大小為 4 個(gè)字節(jié)
• 在 64 位系統(tǒng)下，uintptr 為 uint64 類型，占用大小為 8 個(gè)字節(jié)

^uintptr 做了什么事

^ 位運(yùn)算符的作用是按位異或，如下：

func main() {
    log.Println(^1)
    log.Println(^uint64(0))
}

輸出結(jié)果：

2019/01/05 20:44:49 -2
2019/01/05 20:44:49 18446744073709551615

接下來我們分析一下，這兩段代碼都做了什么事情呢

^1

二進(jìn)制：0001

按位取反：1110

該數(shù)為有符號整數(shù)，最高位為符號位。低三位為表示數(shù)值。按位取反后為 1110，根據(jù)先前的說明，最高位為 1，因此表示為 -。取反后 110 對應(yīng)十進(jìn)制 -2

^uint64(0)

二進(jìn)制：0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

按位取反：1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111

該數(shù)為無符號整數(shù)，該位取反后得到十進(jìn)制值為：18446744073709551615

這個(gè)值是不是看起來很眼熟呢？沒錯(cuò)，就是 ^uintptr(0) 的值。也印證了其底層數(shù)據(jù)類型為 uint64 的事實(shí) （本機(jī)為 64 位）。同時(shí)它又代表如下：

• math.MaxUint64
• 2 的 64 次方減 1

maxAlloc

const GoarchMips = 0
const GoarchMipsle = 0
const GoarchWasm = 0

...

_64bit = 1 << (^uintptr(0) >> 63) / 2

heapAddrBits = (_64bit*(1-sys.GoarchWasm))*48 + (1-_64bit+sys.GoarchWasm)*(32-(sys.GoarchMips+sys.GoarchMipsle))

maxAlloc = (1 << heapAddrBits) - (1-_64bit)*1

maxAlloc 是允許用戶分配的最大虛擬內(nèi)存空間。在 64 位，理論上可分配最大 1 << heapAddrBits 字節(jié)。在 32 位，最大可分配小于 1 << 32 字節(jié)

在本文，僅需了解它承載的是什么就好了。具體的在以后內(nèi)存管理的文章再講述

注：該變量在 go 10.1 為 _MaxMem，go 11.4 已改為 maxAlloc。相關(guān)的 heapAddrBits 計(jì)算方式也有所改變

maxAlloc / typeSize

我們再次回顧 maxSliceCap 的邏輯代碼，這次重點(diǎn)放在控制邏輯，如下：

// func makeslice
maxElements := maxSliceCap(et.size)

...

// func maxSliceCap
if elemsize < uintptr(len(maxElems)) {
    return maxElems[elemsize]
}
return maxAlloc / elemsize

通過這段代碼和 Slice 上下文邏輯，可得知在想得到該類型的最大容量大小時(shí)。會根據(jù)對應(yīng)的類型大小去查找表查找索引（索引為類型大小，擺放順序是有考慮原因的）。“迫不得已的情況下” 才會手動的計(jì)算它的值，最終計(jì)算得到的內(nèi)存字節(jié)大小都為該類型大小的整數(shù)倍

查找表的設(shè)置，更像是一個(gè)優(yōu)化邏輯。減少常用的計(jì)算開銷 :)

總結(jié)

通過本文的分析，可得出 Slice 所允許申請的最大容量大小，與當(dāng)前值類型和當(dāng)前平臺位數(shù)有直接關(guān)系

最后

本文與《有點(diǎn)不安全卻又一亮的 Go unsafe.Pointer》一同屬于《深入理解 Go Slice》的關(guān)聯(lián)章節(jié)。如果你在閱讀源碼時(shí)，對這些片段有疑惑。記得想盡辦法深究下去，搞懂它

短短的一句話其實(shí)蘊(yùn)含著不少知識點(diǎn)，希望這篇文章恰恰好可以幫你解惑

注：本文 Go 代碼基于版本 11.4