0%

聊一聊go的内存对齐

什么是内存对齐呢

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

一个简单的例子看一下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package main

import (
"fmt"
"unsafe"
)

type One struct {
a bool
b int8
c int32
}

type Two struct {
a bool
c int32
b int8
}

func main() {
fmt.Println(unsafe.Sizeof(One{}))
fmt.Println(unsafe.Sizeof(Two{}))
}

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

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

1
2
3
go run main.go
4
12

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

One的内存

Two的内存

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package main

import (
"fmt"
"unsafe"
)

type One struct {
a bool
b int8
}

type Two struct {
a bool
c int32
b int8
}

type Three struct {
a bool
b int8
c int64
}

func main() {
fmt.Println(unsafe.Alignof(One{}))
fmt.Println(unsafe.Alignof(Two{}))
fmt.Println(unsafe.Alignof(Three{}))
}

运行结果如下

1
2
3
4
go run main.go
1
4
8

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

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

如果我换成 32位操作系统

1
2
3
4
5
$env:GOARCH="386"
go run main.go
1
4
4

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

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

内存对齐的利弊

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

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

看一下如果没有内存对齐的情况吧,如果在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{}的位置不同,占用的空间也不相同

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package main

import (
"fmt"
"unsafe"
)

type One struct {
s struct{}
x int
}
type Two struct {
x int
s struct{}
}

func main() {
fmt.Println(unsafe.Sizeof(One{}))
fmt.Println(unsafe.Sizeof(Two{}))
}

运行结果如下:

1
2
3
go run main.go
8
16

OneTwo 中,只是 struct{}的位置不同,就会导致内存占用不同

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

如何优化内存布局

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

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

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

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

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

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