聊一聊go的内存对齐

什么是内存对齐呢

简单说就是程序运行过程中，程序中的变量在内存中的分布情况，为什么要有对齐这个问题呢，是因为不同类型的变量占用内存的大小是不一样的，但是cpu每次读取的内存长度是固定的，为了cpu能高效的读写数据（cpu读取数据不是一个字节一个字节读取的，一次读取的一块内存），所以编译器在编译的时候会通过填充空数据(数据不是连续的)，让一个变量，使cpu能一次操作就能完成读写。还有跨平台的问题，有的平台不支持访问任意地址上的任意数据，必须按照顺序依次按块读取。

一个简单的例子看一下:

 1package main
 2
 3import (
 4   "fmt"
 5   "unsafe"
 6)
 7
 8type One struct {
 9   a bool
10   b int8
11   c int32
12}
13
14type Two struct {
15   a bool
16   c int32
17   b int8
18}
19
20func main() {
21   fmt.Println(unsafe.Sizeof(One{}))
22   fmt.Println(unsafe.Sizeof(Two{}))
23}

这两个结构体在运行时，占用的内存大小，看起来应该来说是一样大的，毕竟内部的变量是一样的，只是顺序不同而已。

但实际上，占用的内存是不一样的，看一下运行结果：

1go run main.go
24
312

为什么会这样呢，画一下内存的示意图就清楚了

One的内存

Two的内存

图中灰色的块是为了对齐而填充的无用区域，可见 One 的内存利用率比 Two 要高好多，因为cpu一次读取的内存大小是4个字节，也就是32位。为了能让cpu一次就读取完这个变量，所以编译器就做了一些调整，使内存利用率低了，但是却提高了效率。

这里又带来一个问题，cpu一次读取数据的长度是如何确定的，这个叫对齐系数。

go中有一个函数，可以计算出对齐系数，一段代码看一下

 1package main
 2
 3import (
 4   "fmt"
 5   "unsafe"
 6)
 7
 8type One struct {
 9   a bool
10   b int8
11}
12
13type Two struct {
14   a bool
15   c int32
16   b int8
17}
18
19type Three struct {
20   a bool
21   b int8
22   c int64
23}
24
25func main() {
26   fmt.Println(unsafe.Alignof(One{}))
27   fmt.Println(unsafe.Alignof(Two{}))
28   fmt.Println(unsafe.Alignof(Three{}))
29}

运行结果如下

1go run main.go
21
34
48

可以得到，cpu一次读取的数据长度和这结构体中的最大的数据有关。

One 中最大的数据长度是1个字节, Two 中最大的数据长度是4个字节, Three 中最大的数据长度是8个字节

如果我换成 32位操作系统 呢

1$env:GOARCH="386"
2go run main.go
31
44
54

此时的对齐系数变成了4，因为32位的系统一次能处理的数据长度就是 4个字节，说明对齐系数还和操作系统有关。

所以：对齐系数和结构体中最大的的数据有关，同时和操作系统也有关。取这两个条件中的小值

内存对齐的利弊

利

高效. 数据只需要一次就能完成读写，效率肯定比多次读写要高效
数据原子性. 还是数据一次就能完成读写，保证了原子性

弊

那就是内存的利用率变低了，这个可以通过优化来解决一部分

看一下如果没有内存对齐的情况吧，如果在32位的系统上，变量C要经过两次才能读到

不同类型的对齐系数

在64位操作系统中

类型	系数
bool, byte, uint8, int8	1
uint16, int16	2
uint32, int32	4
float32, complex64	4
int, uint, int64, uint64,string,uintptr,float64	8

有个特殊的类型 struct{} 空结构体，这个结构体的空间大小是0，但是计算出的对齐系数是1。

而且 struct{}的位置不同，占用的空间也不相同

 1package main
 2
 3import (
 4   "fmt"
 5   "unsafe"
 6)
 7
 8type One struct {
 9   s struct{}
10   x int
11}
12type Two struct {
13   x int
14   s struct{}
15}
16
17func main() {
18   fmt.Println(unsafe.Sizeof(One{}))
19   fmt.Println(unsafe.Sizeof(Two{}))
20}

运行结果如下:

1go run main.go
28
316

One 和 Two 中，只是 struct{}的位置不同，就会导致内存占用不同

之所以这样是因为，当struct{} 作为结构体最后一个字段时，如果struct{}不做填充，就会导致指向 struct{} 的地址指向了结构体之外了，所以为了出错，就会填充一个数据位置，也就是一个 int的大小。

如何优化内存布局

首先，go的编译器不会做内存对齐的优化，也就是在编译期间，编译器不会调整结构体中字段的顺序。至于为啥不做，我还没想通，有知道的欢迎评论区探讨。

所以内存对齐的优化需要我们自己做。

我自己总结的两点，欢迎补充

尽量把相同类型的变量放到一起
把小的数据放到前面，大的数据放到后面

好了，常见的go内存对齐的问题差不多就是这些了。

说实话，我在工作中不是特别注意内存对齐的问题，只有在想到的时候才会做一下。这个东西带来的收益不是特别大，在内存动不动16G起步的时代，这点优化可以忽略不计的，当做知识了解一下就好了。