Go Slice 最大容量大小是怎么來的

maybe_009 發布于2019-07-01 11:09 / 1261人閱讀

摘要：會根據對應的類型大小去查找表查找索引索引為類型大小，擺放順序是有考慮原因的。

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

前言

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

Go Slice 對應代碼如下：

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}
}

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

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 是包含一些預定義的切片最大容量值的查找表，索引是切片元素的類型大小。而值看起來 “奇奇怪怪” 不大眼熟，都是些什么呢。主要是以下三個核心點：

^uintptr(0)

maxAlloc

maxAlloc / typeSize

^uintptr(0)

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

輸出結果：

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

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

uintptr 是什么

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

type uintptr uintptr

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

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

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

在 32 位系統下，uintptr 為 uint32 類型，占用大小為 4 個字節

在 64 位系統下，uintptr 為 uint64 類型，占用大小為 8 個字節

^uintptr 做了什么事

^ 位運算符的作用是按位異或，如下：

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

輸出結果：

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

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

二進制：0001

按位取反：1110

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

^uint64(0)

二進制：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

該數為無符號整數，該位取反后得到十進制值為：18446744073709551615

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

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 是允許用戶分配的最大虛擬內存空間。在 64 位，理論上可分配最大 1 << heapAddrBits 字節。在 32 位，最大可分配小于 1 << 32 字節

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

注：該變量在 go 10.1 為 _MaxMem，go 11.4 已改為 maxAlloc。相關的 heapAddrBits 計算方式也有所改變

maxAlloc / typeSize

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

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

...

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

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

查找表的設置，更像是一個優化邏輯。減少常用的計算開銷 :)

總結

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

最后

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

短短的一句話其實蘊含著不少知識點，希望這篇文章恰恰好可以幫你解惑

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

云服務器 GPU云服務器超融合分布式存儲最大容量是多少? 大數據是怎么來的數據分析的數據是怎么來的 go 讀取linux硬盤容量

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/29895.html

golang學習筆記（一）——golang基礎和相關數據結構

摘要：小白前端一枚，最近在研究，記錄自己學習過程中的一些筆記，以及自己的理解。此外，結構體也支持嵌套。在函數聲明時，在函數名前放上一個變量，這個變量稱為方法的接收器，一般是結構體類型的。小白前端一枚，最近在研究golang，記錄自己學習過程中的一些筆記，以及自己的理解。 go中包的依賴管理 go中的切片 byte 和 string go中的Map go中的struct結構體 go中的方...

lyning 2019-08-26 13:27 評論0 收藏0
PHP轉Go系列：數組與切片

摘要：以上是數組在語言中的定義方法，代表數組長度為，是數組中元素的類型，花括號中的是數組元素，切記元素個數與類型一定要與前面聲明的相符，否則會報錯。數組元素的刪除在中刪除數組元素非常簡單，直接即可，以下代碼是刪除第二個元素。數組的定義用過PHP的同學應該很清楚，無論多么復雜的數據格式都可以用數組來表達，什么類型的數據都可以往里塞，它是工作必備的一部分，使用很簡單，易用程度簡直變態。 $a...

yuxue 2019-07-01 13:57 評論0 收藏0
深入理解 Go map：賦值和擴容遷移

摘要：我相信這樣你能更好的讀懂這篇文章原文地址深入理解賦值和擴容遷移哈希函數哈希函數，又稱散列算法散列函數。而一個好的哈希函數，應當盡量少的出現哈希沖突，以此保證操作哈希表的時間復雜度但是哈希沖突在目前來講，是無法避免的。概要在上一章節中，數據結構小節里講解了大量基礎字段，可能你會疑惑需要 #&（！……#（！￥！來干嘛？接下來我們一起簡單了解一下基礎概念。再開始研討今天文章的重點內...

wudengzan 2019-07-01 12:36 評論0 收藏0
go實現LRU cache

摘要：簡介概述緩存資源通常比較昂貴通常數據量較大時會竟可能從較少的緩存滿足盡可能多訪問這里有一種假設通常最近被訪問的數據那么它就有可能會被后續繼續訪問基于這種假設將所有的數據按訪問時間進行排序并按驅逐出舊數據那么存在緩存的數據就為熱點數據這樣既節 1. LRU簡介 1.1 概述緩存資源通常比較昂貴,通常數據量較大時,會竟可能從較少的緩存滿足盡可能多訪問,這里有一種假設,通常最近被訪問的數據...

Jackwoo 2019-08-06 13:31 評論0 收藏0
Netty ByteBuf

摘要：主要用來檢測對象是否泄漏。子類實現相關的方法是否支持數組，判斷緩沖區的實現是否基于字節數組如果緩沖區的實現基于字節數組，返回字節數組 ByteBuf ByteBuf需要提供JDK ByteBuffer的功能(包含且不限于)，主要有以下幾類基本功能： 7種Java基礎類型、byte[]、ByteBuffer(ByteBuf)的等的讀寫緩沖區自身的copy和slice 設置網絡字節序 ...

meislzhua 2019-08-16 13:48 評論0 收藏0