一、go语言内存布局
想象一下，你有一个如下的结构体。
type MyData struct {
aByte byte
aShort int16
anInt32 int32
aSlice []byte
}
那么这个结构体究竟是什么呢？ 从根本上说，它描述了如何在内存中布局数据。 这是什么意思？编译器又是如何展现出来呢？ 我们来看一下。 首先让我们使用反射来检查结构中的字段。
二、反射之上
下面是一些使用反射来找出字段大小及其偏移量（它们相对于结构的开始位于内存中的位置）的代码。 反射可以告诉我们编译器是怎么看待类型（包括结构）的。
// First ask Go to give us some information about the MyData type
typ := reflect.TypeOf(MyData{})
fmt.Printf("Struct is %d bytes longn", typ.Size())
// We can run through the fields in the structure in order
n := typ.NumField()
for i := 0; i < n; i++ {
field := typ.Field(i)
fmt.Printf("%s at offset %v, size=%d, align=%dn",
field.Name, field.Offset, field.Type.Size(),
field.Type.Align())
}
除了每个字段的偏移和大小，我还打印了每个字段的对齐方式，我稍后会解释。结果如下：
Struct is 32 bytes long
aByte at offset 0, size=1, align=1
aShort at offset 2, size=2, align=2
anInt32 at offset 4, size=4, align=4
aSlice at offset 8, size=24, align=8
aByte是我们结构体中的第一个字段，偏移量为0.它使用1字节的内存。
aShort是第二个字段。它使用2字节的内存。奇怪的是偏移量是2。这是为什么呢？答案是对齐， CPU更好地访问位于2字节（“2字节边界”）的倍数的地址处的2个字节，并访问位于4字节边界上的4个字节，直到CPU的自然整数大小，在现代CPU上是8字节（64位）。
在一些较旧的RISC CPU访问错误对齐的数字引起一个故障：在一些UNIX系统上，这将是一个SIGBUS，它会停止你的程序（或内核）。一些系统能够处理这些错误并修复错误：您的代码将运行，但会缓慢的运行，因为额外的代码将由操作系统运行以修复错误。我相信英特尔和ARM的CPU也只是处理芯片上的任何不对齐：也许我们将在以后的文章中测试这一点，以及任何性能的影响。
无论如何，对齐是Go编译器跳过一个字节放置字段aShort以便它位于2字节边界的原因。因为这样，我们可以将另一个字段放进结构体中，而不使它占用更大内存。这里是我们的结构的新版本，在aByte之后立即有一个新字段anotherByte。
