go语言字节对齐协议解析 字节对齐规则

golang 结构体 字节对齐是怎么样的

用golang解析二进制协议时，其实没必要管结构体的字段的对齐规则，何况语言规范也没有规定如何对齐，也就是没有规则。用encoding/binary.Read函数直接读入struct里就行，struct就像c那样写

10年积累的成都网站建设、成都做网站经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站制作后付款的网站建设流程，更有临泽免费网站建设让你可以放心的选择与我们合作。

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]

}

内存对齐问题

1.平台原因(移植原因)： 不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能

在某些地址处取某些特定类型的数据，否则抛出硬件异常。

2.性能原因： 数据结构应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。(如果是对齐的，那么CPU不需要跨越两个操作字，不是对齐的则需要访问两个操作字才能拼接出需要的内存地址)

指针的大小一般是一个机器字的大小

通过Go语言的structlayout工具，可以得出下图

这些类型在之前的 slice 、 map 、 interface 已经介绍过了，也特意强调过，makehmap函数返回的是一个指针，因此map的对齐为一个机器字.

回头看看 sync.pool的防止copy的空结构体字段,也是放在第一位，破案了。

计算机结构可能会要求内存地址 进行对齐;也就是说，一个变量的地址是一个因子的倍数，也就是该变量的类型是对齐值。

函数Alignof接受一个表示任何类型变量的表达式作为参数，并以字节为单位返回变量(类型)的对齐值。对于变量x：

这是因为int64在bool之后未对齐。

它是32位对齐的，但不是64位对齐的，因为我们使用的是32位系统，因此实际上只是两个32位值并排在一起。

● 内存对齐是为了cpu更高效访问内存中数据

● 结构体对齐依赖类型的大小保证和对齐保证

● 地址对齐保证是：如果类型 t 的对齐保证是 n，那么类型 t 的每个值的地址在运行时必须是 n 的倍数。

● struct内字段如果填充过多，可以尝试重排，使字段排列更紧密，减少内存浪费

● 零大小字段要避免作为struct最后一个字段，会有内存浪费

● 32位系统上对64位字的原子访问要保证其是8bytes对齐的；当然如果不必要的 话，还是用加锁（mutex）的方式更清晰简单

图解go-内存对齐

doc-pdf

Go语言中恰到好处的内存对齐

在开始之前，希望你计算一下 Part1 共占用的大小是多少呢？

输出结果：

这么一算， Part1 这一个结构体的占用内存大小为 1+4+1+8+1 = 15 个字节。相信有的小伙伴是这么算的，看上去也没什么毛病

真实情况是怎么样的呢？我们实际调用看看，如下：

输出结果：

最终输出为占用 32 个字节。这与前面所预期的结果完全不一样。这充分地说明了先前的计算方式是错误的。为什么呢？

在这里要提到 “内存对齐” 这一概念，才能够用正确的姿势去计算，接下来我们详细的讲讲它是什么

有的小伙伴可能会认为内存读取，就是一个简单的字节数组摆放

上图表示一个坑一个萝卜的内存读取方式。但实际上 CPU 并不会以一个一个字节去读取和写入内存。相反 CPU 读取内存是 一块一块读取 的，块的大小可以为 2、4、6、8、16 字节等大小。块大小我们称其为 内存访问粒度 。如下图：

在样例中，假设访问粒度为 4。 CPU 是以每 4 个字节大小的访问粒度去读取和写入内存的。这才是正确的姿势

另外作为一个工程师，你也很有必要学习这块知识点哦 :)

在上图中，假设从 Index 1 开始读取，将会出现很崩溃的问题。因为它的内存访问边界是不对齐的。因此 CPU 会做一些额外的处理工作。如下：

从上述流程可得出，不做 “内存对齐” 是一件有点 "麻烦" 的事。因为它会增加许多耗费时间的动作

而假设做了内存对齐，从 Index 0 开始读取 4 个字节，只需要读取一次，也不需要额外的运算。这显然高效很多，是标准的 空间换时间 做法

在不同平台上的编译器都有自己默认的 “对齐系数”，可通过预编译命令 #pragma pack(n) 进行变更，n 就是代指 “对齐系数”。一般来讲，我们常用的平台的系数如下：

另外要注意，不同硬件平台占用的大小和对齐值都可能是不一样的。因此本文的值不是唯一的，调试的时候需按本机的实际情况考虑

输出结果：

在 Go 中可以调用 unsafe.Alignof 来返回相应类型的对齐系数。通过观察输出结果，可得知基本都是 2^n ，最大也不会超过 8。这是因为我手提（64 位）编译器默认对齐系数是 8，因此最大值不会超过这个数

在上小节中，提到了结构体中的成员变量要做字节对齐。那么想当然身为最终结果的结构体，也是需要做字节对齐的

接下来我们一起分析一下，“它” 到底经历了些什么，影响了 “预期” 结果

在每个成员变量进行对齐后，根据规则 2，整个结构体本身也要进行字节对齐，因为可发现它可能并不是 2^n ，不是偶数倍。显然不符合对齐的规则

根据规则 2，可得出对齐值为 8。现在的偏移量为 25，不是 8 的整倍数。因此确定偏移量为 32。对结构体进行对齐

Part1 内存布局：axxx|bbbb|cxxx|xxxx|dddd|dddd|exxx|xxxx

通过本节的分析，可得知先前的 “推算” 为什么错误？

是因为实际内存管理并非 “一个萝卜一个坑” 的思想。而是一块一块。通过空间换时间（效率）的思想来完成这块读取、写入。另外也需要兼顾不同平台的内存操作情况

在上一小节，可得知根据成员变量的类型不同，其结构体的内存会产生对齐等动作。那假设字段顺序不同，会不会有什么变化呢？我们一起来试试吧 :-)

输出结果：

通过结果可以惊喜的发现，只是 “简单” 对成员变量的字段顺序进行改变，就改变了结构体占用大小

接下来我们一起剖析一下 Part2 ，看看它的内部到底和上一位之间有什么区别，才导致了这样的结果？

符合规则 2，不需要额外对齐

Part2 内存布局：ecax|bbbb|dddd|dddd

通过对比 Part1 和 Part2 的内存布局，你会发现两者有很大的不同。如下：

仔细一看， Part1 存在许多 Padding。显然它占据了不少空间，那么 Padding 是怎么出现的呢？

通过本文的介绍，可得知是由于不同类型导致需要进行字节对齐，以此保证内存的访问边界

那么也不难理解，为什么 调整结构体内成员变量的字段顺序 就能达到缩小结构体占用大小的疑问了，是因为巧妙地减少了 Padding 的存在。让它们更 “紧凑” 了。这一点对于加深 Go 的内存布局印象和大对象的优化非常有帮