Go语言同类型int变量间地址间隔异常问题解析

我发现在部分Go版本中，第一个与第二个int变量之间的地址间隔有时会增大，相关测试代码如下：

package main

import (
    "fmt"
    "unsafe"
)

func main() {
    a := 7
    b := 8
    c := 9
    d := 10
    fmt.Printf("a's address is %v\n", &a)
    fmt.Printf("b's address is %v\n", &b)
    fmt.Printf("c's address is %v\n", &c)
    fmt.Printf("d's address is %v\n", &d)

    baSpan := uintptr(unsafe.Pointer(&b)) - uintptr(unsafe.Pointer(&a))
    cbSpan := uintptr(unsafe.Pointer(&c)) - uintptr(unsafe.Pointer(&b))
    dcSpan := uintptr(unsafe.Pointer(&d)) - uintptr(unsafe.Pointer(&c))

    // Go playground, Go 1.20 - Prints 8.
    // Go playground, Go dev branch - Sometimes prints 8, sometimes 24.
    // My machine, go1.20.4 windows/amd64 - Always prints 24.
    fmt.Printf("b-a span is %v\n", baSpan)

    fmt.Printf("c-b span is %v\n", cbSpan) // Prints 8
    fmt.Printf("d-c span is %v\n", dcSpan) // Prints 8
}

测试环境及结果 #

• Go playground（Go 1.20版本）：b-a间隔为8
• Go playground（Go开发分支）：b-a间隔有时为8，有时为24
• 本地环境（go1.20.4 windows/amd64）：b-a间隔始终为24，而c-b、d-c间隔始终为8

技术问题及解答 #

1. 为何b-a的地址间隔会显示为24？剩余16字节被什么占用？ #

在64位Go环境中，局部变量分配在栈上，但栈帧布局会受编译器安全特性、函数调用元数据影响。当间隔为24时，额外的16字节主要是这两部分：

• 栈金丝雀（Stack Canary）：编译器插入的随机8字节值，用于检测栈溢出攻击；
• 栈帧元数据：另外8字节可能是函数的返回地址，用于维护函数调用的上下文。
  第一个变量a紧邻这些栈帧头部的额外数据，所以和b之间多出16字节间隔；而b、c、d是连续的普通局部变量，间隔保持int类型的8字节。

2. 为何在Go playground中该间隔会出现随机变化？ #

Go playground的开发分支（gotip）会启用实验性编译特性，且playground的执行环境可能随机开启/关闭部分编译选项（比如是否启用栈金丝雀、是否开启调试模式）。加上Go栈布局本身会随编译条件变化，导致每次运行时栈帧的额外数据插入情况不同，因此b-a间隔会随机波动。

3. 除了查看汇编代码外，还有哪些方法可以确定剩余16字节的占用内容？ #

有这些实用方法：

• 用unsafe包直接读取内存：计算a地址后的16字节位置，通过*uint64(unsafe.Pointer(uintptr(unsafe.Pointer(&a)) + 8))这类代码读取内容，若为随机值则大概率是栈金丝雀，若符合函数返回地址特征则是元数据；
• 禁用优化+调试工具调试：用go build -gcflags="-N -l"禁用编译优化，再用gdb或dlv调试程序，直接查看栈帧的内存布局，定位a和b之间的内存内容；
• 调整编译选项反向验证：尝试关闭栈金丝雀（部分版本可通过-gcflags="-d=ssa/checkstack=0"等选项），重新运行后若间隔变回8字节，就能验证额外字节是栈金丝雀及元数据；
• 查阅Go编译器实现：参考cmd/compile模块中关于栈帧构建的源码，明确栈帧中额外数据的分配规则。

内容的提问来源于stack exchange，提问作者bolt