Golang 备忘录
{Back to Index}  Expand All Details on Page

ch1 := make(chan string)        // without buffer
ch1 := make(chan string, 5)     // with buffer

只有一个缓冲区的管道，写入数据类似于加锁，读出数据类似于释放锁，比如：

var counter int = 0
var ch = make(chan int, 1)
func Worker() {
    ch <- 1
    counter++
    <-ch
}

管道双向可读写，管道在函数间传递时也可以使用操作符限制管道的读写：

func ChanParamRW(ch chan int) {
    // 管道可读写
}

func ChanParamR(ch <-chan int) {
    // 只能从管道读取数据
}

func ChanParamW(ch chan<- int) {
    // 只能向管道写入数据
}

协程读取管道时，阻塞的条件有:

• 管道无缓冲区
• 管道的缓冲区中无数据
• 管道的值为 nil

协程写入管道时，阻塞的条件有:

• 管道无缓冲区
• 管道的缓冲区已满
• 管道的值为 nil

表示关闭 channel ：

• 关闭 channel 后，send 操作将导致 painc
• 关闭 channel 后，recv 操作将返回对应类型的 0 值以及一个状态码 false
• close 并非强制需要使用 close(ch) 来关闭 channel ，在某些时候可以自动被关闭
• 如果使用 close() ，建议条件允许的情况下加上 defer
• 只在 sender 端上显式使用 close() 关闭 channel ，因为关闭通道意味着没有数据再需要发送

普通函数在编译时确定，本质就是一个代码入口地址：

func add(a, b int) int {
    return a + b
}

f := add  // f 是一个函数值

f (函数变量)
┌───────────────┐
│ *funcval ptr ─┼──────► funcval
└───────────────┘       ┌───────────────┐
                        │ fn: 0x10a0b0 ─┼──► add 函数的机器码
                        └───────────────┘

// runtime/runtime2.go
type funcval struct {
    fn uintptr  // 函数代码的入口地址
    // 闭包捕获的变量紧跟其后...
}

函数变量实际是 *funcval（指向 funcval 的指针）。

闭包会捕获外部变量， funcval 后面紧跟捕获的变量：

func makeCounter() func() int {
    count := 0
    return func() int {
        count++
        return count
    }
}

f := makeCounter()

f (函数变量)
┌───────────────┐
│ *funcval ptr ─┼──────► funcval (堆上分配)
└───────────────┘        ┌──────────────────┐
                         │ fn: 0x10b0c0     │ ← 匿名函数代码地址
                         │ &count: 0xc00001 │ ← 捕获的变量（指针）
                         └──────────────────┘
                                │
                                ▼
                          ┌──────────┐
                          │ count: 0 │ （逃逸到堆上）
                          └──────────┘

方法只是第一个参数为 receiver 的函数：

type Dog struct{ Name string }

func (d Dog) Bark() string {
    return d.Name + ": woof!"
}

// 编译器实际生成的等价函数：
// func Dog_Bark(d Dog) string { ... }

// 以下两种调用等价
dog := Dog{"Buddy"}
dog.Bark()                    // 方法调用
Dog.Bark(dog)                 // 函数调用（方法表达式）

接口的方法通过 itab 分发：

var s Speaker = Dog{"Buddy"}

┌─────────────────┐
│ iface           │
│ ├─ itab ────────┼──► ┌───────────────────────┐
│ └─ data ───┐    │    │ itab                  │
└────────────┼────┘    │ ├─ inter (interface)  │
             │         │ ├─ _type (real type)  │
             ▼         │ └─ fun[0] ────────────┼──► Dog.Bark 代码
        ┌────────┐     └───────────────────────┘
        │ "Buddy"│
        └────────┘

var x float64 = 3.14

t := reflect.TypeOf(x)   // 提取 eface 中的 _type 指针 → 得到类型元数据
v := reflect.ValueOf(x)  // 提取 eface 中的 data 指针  → 得到值的副本

调用 reflect.TypeOf(x) 时：

• x 被隐式装箱为 interface{} （即构造一个 eface）
• TypeOf 读取 eface._type ，返回 reflect.Type

调用 reflect.ValueOf(x) 时：

• 同样装箱为 interface{}
• ValueOf 同时读取 _type 和 data ，返回 reflect.Value

源代码变量          interface{} 装箱            反射拆解

var x MyStruct  →  eface{                  →  reflect.TypeOf:  读 _type
                     _type: *MyStruct元数据       → Name(), Field(), Method()...
                     data:  *x的副本           reflect.ValueOf: 读 _type + data
                   }                             → Int(), String(), Set()...

• 反射的入口必须是 interface{} ，因为只有 interface 在运行时同时携带 type 和 value。
• 反射比直接访问慢–需要通过指针间接查表，无法被编译器内联优化。
• reflect.Value.Set() 要求可寻址（ addressable ）–因为它需要真正修改原始内存，而不是 interface 中的值副本。

每个 goroutine 的 g 结构记录栈的地址范围 =[stack.lo, stack.hi)=。Go 支持的常见架构上，栈从高地址向低地址增长：

高地址  stack.hi
┌────────────────────────┐
│ 最早的调用帧            │
│ ...                    │
│ 当前函数调用帧          │  ← SP
├────────────────────────┤
│ 尚未使用的空间          │
├────────────────────────┤  ← stackguard0
│ NOSPLIT/扩栈路径预留区   │
│ OS 特殊处理预留区        │  ← stackSystem（部分平台）
└────────────────────────┘
低地址  stack.lo

栈帧通常包含：

• 未逃逸的局部变量；
• 返回地址、保存的寄存器和寄存器溢出区；
• 部分参数和返回值，具体取决于寄存器 ABI 和编译优化；
• defer、panic、栈对象等运行时需要的信息。

函数栈帧的大小基本在编译期确定。函数调用和返回主要通过移动 SP 完成，不需要像堆对象一样逐个申请、释放。

局部变量是否放在栈上由逃逸分析决定。编译器不能证明其生命周期受当前调用约束时，变量通常逃逸到堆：

func value() *int {
    x := 10
    return &x // x 通常逃逸到堆
}

使用以下命令查看逃逸分析结果：

go build -gcflags="-m=2" ./...

GC 会使用编译器生成的 stack map 精确识别活动栈帧中的指针槽。栈本身由 runtime 专门管理，但栈里的指针是 GC 根集合的一部分。

go f() 会被编译器转换为调用 =runtime.newproc=。其主要流程是：

go f()
  ↓
runtime.newproc / runtime.newproc1
  ↓
从当前 P 的 gFree 获取可复用的 g
  ├─ 有：复用 g，以及尺寸合适的栈
  └─ 无：创建新的 g，并分配最小栈
  ↓
初始化 SP、PC 和 goexit 返回路径
  ↓
放入 P 的 runnable 队列

Go 1.26 中 =stackMin = 2048=，表示 Go 代码所需的最小栈为 2 KiB。实际最小分配值是 =fixedStack=，还要加入部分平台的 =stackSystem=，然后向上取到 2 的幂。

“每个 goroutine 永远从 2 KiB 开始”并不完全准确。runtime 还维护 =startingStackSize=：

上一轮 GC 扫描到的栈使用量平均值
  + stackGuard
  ↓
限制在 fixedStack 与 maxstacksize 之间
  ↓
向上取到 2 的幂
  ↓
作为后续 goroutine 的初始栈目标

这是避免 goroutine 在生命周期早期频繁扩栈的启发式策略。全新创建 g 且没有可复用项时，源码路径仍由 malg(stackMin) 分配最小栈；复用的 g 如果没有合适栈，则按当前 startingStackSize 重新分配。

编译器会在大多数函数入口插入栈检查。概念上类似：

if SP-frameSize < stackguard0 {
    runtime.morestack()
}

stackguard0 是逻辑检查边界，不等同于操作系统的不可访问 guard page。带 //go:nosplit 的函数不执行普通栈检查，因此 runtime 会为一串 NOSPLIT 调用以及扩栈路径预留空间。

发现空间不足后：

1. morestack 保存当前 goroutine 的执行现场；
2. 切换到当前 M 的 g0 系统栈，避免在已经不足的用户栈上分配内存；
3. newstack 通常把容量扩大为原来的 2 倍；
4. 如果即将进入的栈帧很大，则继续翻倍直到能够容纳；
5. copystack 分配新的连续栈，只复制当前实际使用的部分；
6. 修正栈帧、defer、panic、channel 等结构中指向旧栈的指针；
7. 切换到新栈，释放旧栈并恢复执行。

2 KiB → 4 KiB → 8 KiB → 16 KiB → 32 KiB → ...

单次扩容需要复制当前活动栈，成本约为 =O(已使用栈大小)=；由于容量按倍数增长，总体具有较低的摊销成本。当前默认最大栈限制在 64 位平台约为 1 GB、32 位平台约为 250 MB，超过限制会触发不可恢复的 stack overflow。

现代 gc 工具链使用的是连续、可搬迁栈。Go 1.3 起已经不再使用早期的 segmented stack 模型。

函数返回只会恢复 SP，不会立即缩小底层栈。GC 扫描 goroutine 时，如果能够安全搬迁，并且满足：

已使用空间 + stackNosplit < 当前栈容量 / 4

runtime 会尝试把栈缩小为当前容量的一半，但不会低于 =fixedStack=。一次 GC 最多缩小一级；后续 GC 仍满足条件时可以继续缩小。

处于 syscall、异步安全点或某些 channel parking 临界状态时，栈不能立即搬迁，runtime 会把缩容延迟到后续同步安全点。

goroutine 结束后：

• g 进入当前 P 或全局的空闲列表；
• 尺寸等于当前 startingStackSize 的栈可以随 g 保留，供后续 goroutine 复用；
• 其他尺寸的栈归还给栈缓存、全局池或 runtime 页分配器。

stackalloc 必须运行在 g0 系统栈上，要求分配大小为 2 的幂。goroutine 栈不是普通 GC 堆对象，但通常复用 runtime 的页分配器和 manual =mspan=：

• 小栈优先从当前 P 的 mcache.stackcache 获取；
• 本地缓存为空时，从全局 stackpool 批量补充；
• 较大的栈使用专用 manual span，并可通过大栈缓存复用；
• 完全空闲的 stack span 会重新归还给通用 heap 页分配器。

在典型 64 位 Unix 平台的 Go 1.26 中，2、4、8、16 KiB 栈走小栈缓存，32 KiB 及以上通常使用专用 span。该阈值属于 runtime 实现细节。

stackSystem 是 runtime 在每个 goroutine 栈底，为部分操作系统的信号、异常等特殊处理路径额外预留的空间。它不是另一块栈，也不是普通 Go 函数可以自由使用的额外容量。

多数 Unix 系统可以通过 sigaltstack 使用独立的信号栈。Windows、Plan 9 和 iOS 的相关路径不使用独立栈，因此即使 goroutine 已接近栈底，也必须保证信号或异常处理代码有空间执行，不能依赖此时再进行普通扩栈。

Go 1.26 中的定义为：

stackSystem = goos.IsWindows*4096 +
    goos.IsPlan9*512 +
    goos.IsIos*goarch.IsArm64*1024

它同时参与最小栈和 guard 边界的计算：

fixedStack = roundUpToPowerOfTwo(stackMin + stackSystem)
stackGuard = stackNosplit + stackSystem + abi.StackSmall

例如：

因此 stackSystem 会增加最小栈分配，并把 stackguard0 向高地址移动，使普通函数更早触发扩栈，从而保留栈底空间给 OS 特殊处理路径。

两者当前的关系可以概括为：

StackInuse = runtime 保留作栈用途的 stack span 容量

StackSys   = StackInuse
             + runtime 能统计到的、直接由 OS 分配的线程栈

StackInuse 不是所有 goroutine 当前活动栈帧字节数之和。例如 goroutine 已分配 16 KiB 栈、当前只使用 3 KiB，统计口径仍按分配容量；小栈 span 内的碎片和缓存也可能计入。

纯 Go、非 cgo 程序中，当前通常有：

StackSys == StackInuse

某些 cgo、=c-shared= 或 c-archive 场景中，直接由 OS 提供的线程栈会让 StackSys > StackInuse=。但目前 cgo 栈统计并不完整，C 代码自行创建的线程栈通常不会全部计入，所以 =StackSys 不能作为进程全部线程栈的真实总量。

例如：

StackInuse = 64 MiB  // runtime 管理并保留作栈用途的内存
StackSys   = 72 MiB  // 再加 8 MiB 可统计到的 OS 线程栈

这不表示当前调用帧实际占用了 64 MiB，也不表示进程有 72 MiB 常驻物理内存。

没有 StackIdle 字段。stack span 完全不再用于栈之后，会归还给通用 heap 页分配器，内存分类可能从 StackInuse 转移到 =HeapIdle=：

GC/栈收缩前：StackInuse 较高
GC/栈释放后：StackInuse 下降，HeapIdle 可能上升

这种分类变化不代表内存已经归还操作系统，因此进程 RSS 不一定同步下降。

对应的 runtime/metrics 指标为：

不要使用 StackInuse / runtime.NumGoroutine() 推导单个 goroutine 的精确栈用量，因为其中包含 runtime goroutine、不同栈容量、栈缓存和 span 粒度带来的开销。

• goroutine 很轻量，但不是零成本；goroutine 泄漏会保留栈以及栈引用的堆对象；
• 深递归会持续扩栈，达到上限后导致不可恢复的 stack overflow；
• 栈会搬迁，不要把由栈地址转换得到的 uintptr 长期保存；隐藏在 uintptr 中的地址不会随栈搬迁自动修正；
• StackInuse=、=StackSys 都是 runtime 内存分类指标，不等同于实际活动栈大小或进程 RSS。

• runtime/stack.go：栈布局、分配、复制、扩缩容及 =stackSystem=；
• runtime/proc.go：goroutine 创建、=g= 与栈复用；
• runtime/mgcmark.go：GC 栈扫描与缩容；
• runtime.MemStats：=StackInuse=、=StackSys= 定义；
• runtime/metrics：栈相关运行时指标；
• Go 1.3 Release Notes：从 segmented stack 切换到连续、可搬迁栈。

Go 没有继承，用嵌入实现"is-a"或"has-a"关系：

type Animal struct {
    Name string
    Age  int
}

func (a Animal) Speak() string {
    return a.Name + " makes a sound"
}

type Dog struct {
    Animal        // 嵌入，Dog "继承"了 Animal 的字段和方法
    Breed string
}

d := Dog{Animal{"Buddy", 3}, "Labrador"}
d.Name              // ✅ 直接访问，不用 d.Animal.Name
d.Speak()           // ✅ 直接调用，不用 d.Animal.Speak()

给已有类型"附加"能力：

// 给任何结构体加锁能力
type SafeCounter struct {
    sync.Mutex             // 嵌入锁
    count int
}

func (c *SafeCounter) Inc() {
    c.Lock()               // 直接调用，不用 c.Mutex.Lock()
    defer c.Unlock()
    c.count++
}

嵌入一个已实现接口的类型，自动满足接口：

type Reader interface {
    Read(p []byte) (n int, err error)
}

type MyReader struct {
    io.Reader              // 嵌入，自动实现 io.Reader 接口
    readCount int
}

// 可以直接传给需要 io.Reader 的地方
func process(r io.Reader) { ... }

f, _ := os.Open("file.txt")
mr := MyReader{Reader: f}
process(mr)                // ✅ MyReader 实现了 io.Reader

嵌入后可以覆盖方法：

type Base struct{}
func (b Base) String() string { return "base" }

type Extended struct {
    Base
}
func (e Extended) String() string { return "extended" }  // 覆盖

e := Extended{}
e.String()        // "extended"（调用 Extended 的方法）
e.Base.String()   // "base"（仍可访问原始方法）

// 嵌入值 - 拷贝语义
type A struct {
    Inner       // Outer 包含 Inner 的完整拷贝
}

// 嵌入指针 - 共享语义（更常用于大结构体）
type B struct {
    *Inner      // Outer 只包含指针，多个实例可共享
}

例子：

type Config struct {
    Debug bool
    Port  int
}

type ServerB struct {
    *Config  // 嵌入指针
    Name string
}

func TestEmbedPointer(t *testing.T) {
    cfg := &Config{true, 8080}

    s1 := ServerB{cfg, "server1"}
    s2 := ServerB{cfg, "server2"}  // 共享同一个 Config

    s2.Debug = false  // 修改 s2

    fmt.Println(s1.Debug)  // false  ← s1 也变了！
    fmt.Println(s2.Debug)  // false
}

嵌入字段的方法可以提升到外层结构体，因此可以省略中间的字段选择器。方法提升并不等于继承，它仍然受 Go 方法集规则的约束。

type T1 struct{}

func (T1) T1M1()   {}
func (T1) T1M2()   {}
func (*T1) PT1M3() {}

type T2 struct{}

func (T2) T2M1()   {}
func (T2) T2M2()   {}
func (*T2) PT2M3() {}

type T struct {
    T1
    *T2
}

在这个例子中， T1 是值类型嵌入， *T2 是指针类型嵌入。提升后的方法集如下 ：

*T 比 T 多出一个 PT1M3 。一般规则是 ：

• 如果 S 嵌入值类型 U ，那么 S 和 *S 的方法集都包含接收者为 U 的提升方法；只有 *S 的方法集还包含接收者为 *U 的提升方法。
• 如果 S 嵌入指针类型 *U ，那么 S 和 *S 的方法集都包含接收者为 U 或 *U 的提升方法。

// runtime/runtime2.go
type eface struct {
    _type *_type          // 指向类型信息
    data  unsafe.Pointer  // 指向实际数据
}

var i interface{} = 42

i (eface, 16字节)
┌─────────────────────┐
│ _type ──────────────┼──► type info (int)
│ data  ──────────────┼──► 42
└─────────────────────┘

// runtime/runtime2.go
type iface struct {
    tab  *itab            // 类型信息 + 方法表
    data unsafe.Pointer   // 指向实际数据
}

var w io.Writer = os.Stdout

w (iface, 16字节)
┌─────────────────────┐
│ tab  ───────────────┼──► itab
│ data ───────────────┼──► os.Stdout 实例
└─────────────────────┘