golang內存對齊原則,golang結構體內存布局

本文目錄一覽：

• 1、Golang 1.14中內存分配、清掃和內存回收
• 2、（十一）golang 內存分析
• 3、golang直接io的使用
• 4、golang 結構體 位元組對齊是怎麼樣的
• 5、沒有類，C語言有結構體，那麼Go的結構體有什麼特別之處？

Golang 1.14中內存分配、清掃和內存回收

Golang的內存分配是由golang runtime完成，其內存分配方案借鑒自tcmalloc。

主要特點就是

本文中的element指一定大小的內存塊是內存分配的概念，並為出現在golang runtime源碼中

本文講述x8664架構下的內存分配

Golang 內存分配有下面幾個主要結構

Tiny對象是指內存尺寸小於16B的對象，這類對象的分配使用mcache的tiny區域進行分配。當tiny區域空間耗盡時刻，它會從mcache.alloc[tinySpanClass]指向的mspan中找到空閑的區域。當然如果mcache中span空間也耗盡，它會觸發從mcentral補充mspan到mcache的流程。

小對象是指對象尺寸在（16B，32KB]之間的對象，這類對象的分配原則是：

1、首先根據對象尺寸將對象歸為某個SpanClass上，這個SpanClass上所有的element都是一個統一的尺寸。

2、從mcache.alloc[SpanClass]找到mspan，看看有無空閑的element，如果有分配成功。如果沒有繼續。

3、從mcentral.allocSpan[SpanClass]的nonempty和emtpy中找到合適的mspan，返回給mcache。如果沒有找到就進入mcentral.grow()—mheap.alloc()分配新的mspan給mcentral。

大對象指尺寸超出32KB的對象，此時直接從mheap中分配，不會走mcache和mcentral，直接走mheap.alloc()分配一個SpanClass==0 的mspan表示這部分分配空間。

對於程序分配常用的tiny和小對象的分配，可以通過無鎖的mcache提升分配性能。mcache不足時刻會拿mcentral的鎖，然後從mcentral中充mspan 給mcache。大對象直接從mheap 中分配。

在x8664環境上，golang管理的有效的程序虛擬地址空間實質上只有48位。在mheap中有一個pages pageAlloc成員用於管理golang堆內存的地址空間。golang從os中申請地址空間給自己管理，地址空間申請下來以後，golang會將地址空間根據實際使用情況標記為free或者alloc。如果地址空間被分配給mspan或大對象後，那麼被標記為alloc，反之就是free。

Golang認為地址空間有以下4種狀態：

Golang同時定義了下面幾個地址空間操作函數：

在mheap結構中，有一個名為pages成員，它用於golang 堆使用虛擬地址空間進行管理。其類型為pageAlloc

pageAlloc 結構表示的golang 堆的所有地址空間。其中最重要的成員有兩個：

在golang的gc流程中會將未使用的對象標記為未使用，但是這些對象所使用的地址空間並未交還給os。地址空間的申請和釋放都是以golang的page為單位（實際以chunk為單位）進行的。sweep的最終結果只是將某個地址空間標記可被分配，並未真正釋放地址空間給os，真正釋放是後文的scavenge過程。

在gc mark結束以後會使用sweep()去嘗試free一個span；在mheap.alloc 申請mspan時刻，也使用sweep去清掃一下。

清掃mspan主要涉及到下面函數

如上節所述，sweep只是將page標記為可分配，但是並未把地址空間釋放；真正的地址空間釋放是scavenge過程。

真正的scavenge是由pageAlloc.scavenge()—sysUnused()將掃描到待釋放的chunk所表示的地址空間釋放掉（使用sysUnused()將地址空間還給os）

golang的scavenge過程有兩種：

（十一）golang 內存分析

編寫過C語言程序的肯定知道通過malloc()方法動態申請內存，其中內存分配器使用的是glibc提供的ptmalloc2。 除了glibc，業界比較出名的內存分配器有Google的tcmalloc和Facebook的jemalloc。二者在避免內存碎片和性能上均比glic有比較大的優勢，在多線程環境中效果更明顯。

Golang中也實現了內存分配器，原理與tcmalloc類似，簡單的說就是維護一塊大的全局內存，每個線程(Golang中為P)維護一塊小的私有內存，私有內存不足再從全局申請。另外，內存分配與GC（垃圾回收）關係密切，所以了解GC前有必要了解內存分配的原理。

為了方便自主管理內存，做法便是先向系統申請一塊內存，然後將內存切割成小塊，通過一定的內存分配算法管理內存。 以64位系統為例，Golang程序啟動時會向系統申請的內存如下圖所示：

預申請的內存劃分為spans、bitmap、arena三部分。其中arena即為所謂的堆區，應用中需要的內存從這裡分配。其中spans和bitmap是為了管理arena區而存在的。

arena的大小為512G，為了方便管理把arena區域劃分成一個個的page，每個page為8KB,一共有512GB/8KB個頁；

spans區域存放span的指針，每個指針對應一個page，所以span區域的大小為(512GB/8KB)乘以指針大小8byte = 512M

bitmap區域大小也是通過arena計算出來，不過主要用於GC。

span是用於管理arena頁的關鍵數據結構，每個span中包含1個或多個連續頁，為了滿足小對象分配，span中的一頁會劃分更小的粒度，而對於大對象比如超過頁大小，則通過多頁實現。

根據對象大小，劃分了一系列class，每個class都代表一個固定大小的對象，以及每個span的大小。如下表所示：

上表中每列含義如下：

class： class ID，每個span結構中都有一個class ID, 表示該span可處理的對象類型

bytes/obj：該class代表對象的位元組數

bytes/span：每個span佔用堆的位元組數，也即頁數乘以頁大小

objects: 每個span可分配的對象個數，也即（bytes/spans）/（bytes/obj）waste

bytes: 每個span產生的內存碎片，也即（bytes/spans）%（bytes/obj）上表可見最大的對象是32K大小，超過32K大小的由特殊的class表示，該class ID為0，每個class只包含一個對象。

span是內存管理的基本單位,每個span用於管理特定的class對象, 跟據對象大小，span將一個或多個頁拆分成多個塊進行管理。src/runtime/mheap.go:mspan定義了其數據結構：

以class 10為例，span和管理的內存如下圖所示：

spanclass為10，參照class表可得出npages=1,nelems=56,elemsize為144。其中startAddr是在span初始化時就指定了某個頁的地址。allocBits指向一個位圖，每位代表一個塊是否被分配，本例中有兩個塊已經被分配，其allocCount也為2。next和prev用於將多個span鏈接起來，這有利於管理多個span，接下來會進行說明。

有了管理內存的基本單位span，還要有個數據結構來管理span，這個數據結構叫mcentral，各線程需要內存時從mcentral管理的span中申請內存，為了避免多線程申請內存時不斷的加鎖，Golang為每個線程分配了span的緩存，這個緩存即是cache。src/runtime/mcache.go:mcache定義了cache的數據結構

alloc為mspan的指針數組，數組大小為class總數的2倍。數組中每個元素代表了一種class類型的span列表，每種class類型都有兩組span列表，第一組列表中所表示的對象中包含了指針，第二組列表中所表示的對象不含有指針，這麼做是為了提高GC掃描性能，對於不包含指針的span列表，沒必要去掃描。根據對象是否包含指針，將對象分為noscan和scan兩類，其中noscan代表沒有指針，而scan則代表有指針，需要GC進行掃描。mcache和span的對應關係如下圖所示：

mchache在初始化時是沒有任何span的，在使用過程中會動態的從central中獲取並緩存下來，跟據使用情況，每種class的span個數也不相同。上圖所示，class 0的span數比class1的要多，說明本線程中分配的小對象要多一些。

cache作為線程的私有資源為單個線程服務，而central則是全局資源，為多個線程服務，當某個線程內存不足時會向central申請，當某個線程釋放內存時又會回收進central。src/runtime/mcentral.go:mcentral定義了central數據結構：

lock: 線程間互斥鎖，防止多線程讀寫衝突

spanclass : 每個mcentral管理着一組有相同class的span列表

nonempty: 指還有內存可用的span列表

empty: 指沒有內存可用的span列表

nmalloc: 指累計分配的對象個數線程從central獲取span步驟如下：

將span歸還步驟如下：

從mcentral數據結構可見，每個mcentral對象只管理特定的class規格的span。事實上每種class都會對應一個mcentral,這個mcentral的集合存放於mheap數據結構中。src/runtime/mheap.go:mheap定義了heap的數據結構：

lock： 互斥鎖

spans: 指向spans區域，用於映射span和page的關係

bitmap：bitmap的起始地址

arena_start: arena區域首地址

arena_used: 當前arena已使用區域的最大地址

central: 每種class對應的兩個mcentral

從數據結構可見，mheap管理着全部的內存，事實上Golang就是通過一個mheap類型的全局變量進行內存管理的。mheap內存管理示意圖如下：

系統預分配的內存分為spans、bitmap、arean三個區域，通過mheap管理起來。接下來看內存分配過程。

針對待分配對象的大小不同有不同的分配邏輯：

(0, 16B) 且不包含指針的對象： Tiny分配

(0, 16B) 包含指針的對象：正常分配

[16B, 32KB] : 正常分配

(32KB, -) : 大對象分配其中Tiny分配和大對象分配都屬於內存管理的優化範疇，這裡暫時僅關注一般的分配方法。

以申請size為n的內存為例，分配步驟如下：

Golang內存分配是個相當複雜的過程，其中還摻雜了GC的處理，這裡僅僅對其關鍵數據結構進行了說明，了解其原理而又不至於深陷實現細節。1、Golang程序啟動時申請一大塊內存並劃分成spans、bitmap、arena區域

2、arena區域按頁劃分成一個個小塊。

3、span管理一個或多個頁。

4、mcentral管理多個span供線程申請使用

5、mcache作為線程私有資源，資源來源於mcentral。

golang直接io的使用

原文鏈接： ;vid=1688855587348942cst=E9F266277367B28319F39975A546E7810FB56065BDFDF61A124CA07F8C69AF9566D809347DAA8BFB56A5A5BFDAC28DACdeviceid=3f371756-5e39-4325-9fec-0b55bfeb87f5version=4.0.6.6516platform=win

所以，通過以上 AlignedBlock 函數分配出來的內存一定是 512 地址對齊的。

有啥缺點嗎？

浪費空間嘛。 命名需要 4k 內存，實際分配了 4k+512 。

開源庫地址：

golang 結構體 位元組對齊是怎麼樣的

用golang解析二進制協議時，其實沒必要管結構體的字段的對齊規則，何況語言規範也沒有規定如何對齊，也就是沒有規則。用encoding/binary.Read函數直接讀入struct里就行，struct就像c那樣寫

type Data struct {

Size, MsgType uint16

Sequence uint32

// …

}

golang編譯器加不加padding，Read都能正常工作，runtime知道Data的布局的，不像C直接做cast所以要知道怎樣對齊。

用unsafe.Alignof可以知道每個field的對齊長度，但沒必要用到。

package main

/*

#include stdint.h

#pragma pack(push, 1)

typedef struct {

uint16_t size;

uint16_t msgtype;

uint32_t sequnce;

uint8_t data1;

uint32_t data2;

uint16_t data3;

} mydata;

#pragma pack(pop)

mydata foo = {

1, 2, 3, 4, 5, 6,

};

int size() {

return sizeof(mydata);

}

*/

import “C”

import (

“bytes”

“encoding/binary”

“fmt”

“log”

“unsafe”

)

func main() {

bs := C.GoBytes(unsafe.Pointer(C.foo), C.size())

fmt.Printf(“len %d data %v\n”, len(bs), bs)

var data struct {

Size, Msytype uint16

Sequence uint32

Data1 uint8

Data2 uint32

Data3 uint16

}

err := binary.Read(bytes.NewReader(bs), binary.LittleEndian, data)

if err != nil {

log.Fatal(err)

}

fmt.Printf(“%v\n”, data) // {1 2 3 4 5 6}

buf := new(bytes.Buffer)

binary.Write(buf, binary.BigEndian, data)

fmt.Printf(“%d %v\n”, buf.Len(), buf.Bytes()) // 15 [0 1 0 2 0 0 0 3 4 0 0 0 5 0 6]

}

沒有類，C語言有結構體，那麼Go的結構體有什麼特別之處？

Go語言中沒有「類」的概念，也不支持「類」的繼承等面向對象的概念。Go語言中通過結構體的內嵌再配合接口比面向對象具有更高的擴展性和靈活性。

自定義類型

在Go語言中有一些基本的數據類型，如string、整型、浮點型、布爾等數據類型， Go語言中可以使用type關鍵字來定義自定義類型。

自定義類型是定義了一個全新的類型。我們可以基於內置的基本類型定義，也可以通過struct定義。例如：

通過Type關鍵字的定義，MyInt就是一種新的類型，它具有int的特性。

類型別名

類型別名是Go1.9版本添加的新功能。

類型別名規定：TypeAlias只是Type的別名，本質上TypeAlias與Type是同一個類型。就像一個孩子小時候有小名、乳名，上學後用學名，英語老師又會給他起英文名，但這些名字都指的是他本人。

type TypeAlias = Type

我們之前見過的rune和byte就是類型別名，他們的定義如下：

類型定義和類型別名的區別

類型別名與類型定義表面上看只有一個等號的差異，我們通過下面的這段代碼來理解它們之間的區別。

結果顯示a的類型是main.NewInt，表示main包下定義的NewInt類型。b的類型是int。MyInt類型只會在代碼中存在，編譯完成時並不會有MyInt類型。

Go語言中的基礎數據類型可以表示一些事物的基本屬性，但是當我們想表達一個事物的全部或部分屬性時，這時候再用單一的基本數據類型明顯就無法滿足需求了，Go語言提供了一種自定義數據類型，可以封裝多個基本數據類型，這種數據類型叫結構體，英文名稱struct。 也就是我們可以通過struct來定義自己的類型了。

Go語言中通過struct來實現面向對象。

結構體的定義

使用type和struct關鍵字來定義結構體，具體代碼格式如下：

其中：

舉個例子，我們定義一個Person（人）結構體，代碼如下：

同樣類型的字段也可以寫在一行，

這樣我們就擁有了一個person的自定義類型，它有name、city、age三個字段，分別表示姓名、城市和年齡。這樣我們使用這個person結構體就能夠很方便的在程序中表示和存儲人信息了。

語言內置的基礎數據類型是用來描述一個值的，而結構體是用來描述一組值的。比如一個人有名字、年齡和居住城市等，本質上是一種聚合型的數據類型

結構體實例化

只有當結構體實例化時，才會真正地分配內存。也就是必須實例化後才能使用結構體的字段。

基本實例化

舉個例子：

我們通過.來訪問結構體的字段（成員變量）,例如p1.name和p1.age等。

匿名結構體

在定義一些臨時數據結構等場景下還可以使用匿名結構體。

創建指針類型結構體

我們還可以通過使用new關鍵字對結構體進行實例化，得到的是結構體的地址。 格式如下：

從打印的結果中我們可以看出p2是一個結構體指針。

需要注意的是在Go語言中支持對結構體指針直接使用.來訪問結構體的成員。

取結構體的地址實例化

使用對結構體進行取地址操作相當於對該結構體類型進行了一次new實例化操作。

p3.name = “七米”其實在底層是(*p3).name = “七米”，這是Go語言幫我們實現的語法糖。

結構體初始化

沒有初始化的結構體，其成員變量都是對應其類型的零值。

使用鍵值對初始化

使用鍵值對對結構體進行初始化時，鍵對應結構體的字段，值對應該字段的初始值。

也可以對結構體指針進行鍵值對初始化，例如：

當某些字段沒有初始值的時候，該字段可以不寫。此時，沒有指定初始值的字段的值就是該字段類型的零值。

使用值的列表初始化

初始化結構體的時候可以簡寫，也就是初始化的時候不寫鍵，直接寫值：

使用這種格式初始化時，需要注意：

結構體內存布局

結構體佔用一塊連續的內存。

輸出：

【進階知識點】關於Go語言中的內存對齊推薦閱讀:在 Go 中恰到好處的內存對齊

面試題

請問下面代碼的執行結果是什麼？

構造函數

Go語言的結構體沒有構造函數，我們可以自己實現。 例如，下方的代碼就實現了一個person的構造函數。 因為struct是值類型，如果結構體比較複雜的話，值拷貝性能開銷會比較大，所以該構造函數返回的是結構體指針類型。

調用構造函數

方法和接收者

Go語言中的方法（Method）是一種作用於特定類型變量的函數。這種特定類型變量叫做接收者（Receiver）。接收者的概念就類似於其他語言中的this或者 self。

方法的定義格式如下：

其中，

舉個例子：

方法與函數的區別是，函數不屬於任何類型，方法屬於特定的類型。

指針類型的接收者

指針類型的接收者由一個結構體的指針組成，由於指針的特性，調用方法時修改接收者指針的任意成員變量，在方法結束後，修改都是有效的。這種方式就十分接近於其他語言中面向對象中的this或者self。 例如我們為Person添加一個SetAge方法，來修改實例變量的年齡。

調用該方法：

值類型的接收者

當方法作用於值類型接收者時，Go語言會在代碼運行時將接收者的值複製一份。在值類型接收者的方法中可以獲取接收者的成員值，但修改操作只是針對副本，無法修改接收者變量本身。

什麼時候應該使用指針類型接收者

任意類型添加方法

在Go語言中，接收者的類型可以是任何類型，不僅僅是結構體，任何類型都可以擁有方法。 舉個例子，我們基於內置的int類型使用type關鍵字可以定義新的自定義類型，然後為我們的自定義類型添加方法。

注意事項： 非本地類型不能定義方法，也就是說我們不能給別的包的類型定義方法。

結構體的匿名字段

匿名字段默認採用類型名作為字段名，結構體要求字段名稱必須唯一，因此一個結構體中同種類型的匿名字段只能有一個。

嵌套結構體

一個結構體中可以嵌套包含另一個結構體或結構體指針。

嵌套匿名結構體

當訪問結構體成員時會先在結構體中查找該字段，找不到再去匿名結構體中查找。

嵌套結構體的字段名衝突

嵌套結構體內部可能存在相同的字段名。這個時候為了避免歧義需要指定具體的內嵌結構體的字段。

結構體的「繼承」

Go語言中使用結構體也可以實現其他編程語言中面向對象的繼承。

結構體字段的可見性

結構體中字段大寫開頭表示可公開訪問，小寫表示私有（僅在定義當前結構體的包中可訪問）。

結構體與JSON序列化

JSON(JavaScript Object Notation) 是一種輕量級的數據交換格式。易於人閱讀和編寫。同時也易於機器解析和生成。JSON鍵值對是用來保存JS對象的一種方式，鍵/值對組合中的鍵名寫在前面並用雙引號””包裹，使用冒號:分隔，然後緊接着值；多個鍵值之間使用英文,分隔。

結構體標籤（Tag）

Tag是結構體的元信息，可以在運行的時候通過反射的機制讀取出來。 Tag在結構體字段的後方定義，由一對反引號包裹起來，具體的格式如下：

`key1:”value1″ key2:”value2″`

結構體標籤由一個或多個鍵值對組成。鍵與值使用冒號分隔，值用雙引號括起來。鍵值對之間使用一個空格分隔。 注意事項： 為結構體編寫Tag時，必須嚴格遵守鍵值對的規則。結構體標籤的解析代碼的容錯能力很差，一旦格式寫錯，編譯和運行時都不會提示任何錯誤，通過反射也無法正確取值。例如不要在key和value之間添加空格。

例如我們為Student結構體的每個字段定義json序列化時使用的Tag：