什么是内存对齐呢
简单说就是程序运行过程中，程序中的变量在内存中的分布情况，为什么要有对齐这个问题呢，是因为不同类型的变量占用内存的大小是不一样的，但是cpu每次读取的内存长度是固定的，为了cpu能高效的读写数据（cpu读取数据不是一个字节一个字节读取的，一次读取的一块内存），所以编译器在编译的时候会通过填充空数据(数据不是连续的)，让一个变量，使cpu能一次操作就能完成读写。还有跨平台的问题，有的平台不支持访问任意地址上的任意数据，必须按照顺序依次按块读取。
一个简单的例子看一下:
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{}))
}
这两个结构体在运行时，占用的内存大小，看起来应该来说是一样大的，毕竟内部的变量是一样的，只是顺序不同而已。
但实际上，占用的内存是不一样的，看一下运行结果：
go run main.go
4
12
为什么会这样呢，画一下内存的示意图就清楚了
One的内存
Two的内存
图中灰色的块是为了对齐而填充的无用区域，可见 One 的 内存利用率比 Two 要高好多，因为cpu一次读取的内存大小是4个字节，也就是32位。为了能让cpu一次就读取完这个变量，所以编译器就做了一些调整，使内存利用率低了，但是却提高了效率。
这里又带来一个问题，cpu一次读取数据的长度是如何确定的，这个叫对齐系数。
go中有一个函数，可以计算出对齐系数，一段代码看一下
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{}))
}
运行结果如下
go run main.go
1
4
8
可以得到，cpu一次读取的数据长度和这结构体中的最大的数据有关。
One 中最大的数据长度是1个字节, Two 中最大的数据长度是4个字节, Three 中最大的数据长度是8个字节
如果我换成 32位操作系统 呢
$env:GOARCH="386"
go run main.go
1
4
4
此时的对齐系数变成了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{}的位置不同，占用的空间也不相同
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{}))
}
运行结果如下:
go run main.go
8
16
One 和 Two 中，只是 struct{}的位置不同，就会导致内存占用不同
之所以这样是因为，当struct{} 作为结构体最后一个字段时，如果struct{}不做填充，就会导致指向 struct{} 的地址指向了 结构体之外了，所以为了出错，就会填充一个数据位置，也就是一个 int的大小。
如何优化内存布局
首先，go的编译器不会做内存对齐的优化，也就是在编译期间，编译器不会调整结构体中字段的顺序。至于为啥不做，我还没想通，有知道的欢迎评论区探讨。
所以内存对齐的优化需要我们自己做。
我自己总结的两点，欢迎补充
- 尽量把相同类型的变量放到一起
- 把小的数据放到前面，大的数据放到后面
好了，常见的go内存对齐的问题 差不多就是这些了。
说实话，我在工作中不是特别注意内存对齐的问题，只有在想到的时候才会做一下。这个东西带来的收益不是特别大，在内存动不动16G起步的时代，这点优化可以忽略不计的，当做知识了解一下就好了。
