[0]byte
在golang中不应占用任何内存空间。但是这两个结构具有不同的大小。
type bar2 struct {
A int
_ [0]byte
}
type bar3 struct {
_ [0]byte
A int
}
那么,为什么[0]byte
事情在这里重要呢?
顺便说一下,我使用unsafe.Sizeof()
method检查结构大小。请参阅完整示例。
这是由于棘手的填充。
首先,请允许我稍微重命名结构和字段,以便于讨论它们:
type bar1 struct {
A [0]byte
I int
}
type bar2 struct {
I int
A [0]byte
}
当然,这不会更改大小和偏移量,可以在Go Playground上进行验证:
bar1 size: 4
bar1.A offset: 0
bar1.I offset: 0
bar2 size: 8
bar2.I offset: 0
bar2.A offset: 4
类型值的大小[0]byte
为零,因此完全bar1
不为第一个字段(bar1.A
)保留任何空间,并bar1.I
以0偏移量布置该字段是完全有效的。
问题是:为什么编译器在第二种情况下(用bar2
)不能做同样的事情?
一个字段的地址必须位于为前一个字段保留的存储区之后。在第一种情况下,第一个字段的bar1.A
大小为0,因此第二个字段的偏移量可能为0,因此不会与第一个字段“重叠”。
在的情况下bar2
,第二个字段的地址(和偏移量)不能与第一个字段重叠,因此int
在32位架构的情况下,其偏移量不能小于4个字节的大小(在第一个字段中为8个字节) 64位拱形)。
看来还是可以的。但是由于bar2.A
大小为零,为什么结构的大小bar2
不能仅是:4个字节(在64位arch中为8个字节)?
这是因为采用大小为0的字段(和变量)的地址是完全有效的。好吧那又怎样
在这种情况下bar2
,编译器必须插入4(或8)字节的填充,否则获取bar2.A
字段的地址将指向为type值保留的存储区域之外bar2
。
例如,不填充的值bar2
可能具有0x100
大小为4 的地址,因此为结构值保留的内存具有地址范围0x100 .. 0x103
。地址bar2.A
是0x104
,那是外面的结构体的内存中。对于此结构的数组(例如x [5]bar2
),如果数组从处开始0x100
,则地址of x[0]
将为0x100
,地址of x[0].A
将为0x104
,随后元素的地址x[1]
也将为,0x104
但这就是另一个结构值的地址!不酷
为避免这种情况,编译器将插入一个填充(根据拱形为4或8个字节),因此采用地址bar2.A
不会导致地址超出结构的内存,否则可能引发问题并引起问题关于垃圾回收(例如,如果仅bar2.A
保留的地址,但不保留struct或指向它的其他指针或其其他字段,则不应对整个struct进行垃圾回收,但是由于没有指针指向其内存区域,因此它似乎是有效的这样做)。插入的填充将为4(或8)个字节,因为Spec:Size和alignment保证:
对于
x
结构类型的变量:unsafe.Alignof(x)
是的unsafe.Alignof(x.f)
每个字段f
的所有值中的最大值x
,但至少是1
。
如果是这样,则添加一个附加int
字段将使两个结构的大小相等:
type bar1 struct {
I int
A [0]byte
X int
}
type bar2 struct {
A [0]byte
I int
X int
}
确实,它们在32位架构上都有8个字节(在64位架构上都有16个字节)(在Go Playground上尝试一下):
bar1 size: 8
bar1.I offset: 0
bar1.A offset: 4
bar1.X offset: 4
bar2 size: 8
bar2.A offset: 0
bar2.I offset: 0
bar2.X offset: 4
请参阅相关问题:如果字段顺序不同,结构的大小也将不同
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句