深入理解go语言-第5章并发编程——Go的灵魂

第5章并发编程------Go的灵魂

"Don't communicate by sharing memory; share memory by communicating." ------ Go proverb

并发是Go语言最核心的设计理念之一。Go通过goroutine和Channel，将CSP（Communicating Sequential Processes）模型优雅地融入语言本身，使并发编程变得简单而高效。本章将从基础用法到调度器原理，全面剖析Go的并发体系。

5.1 goroutine：轻量级并发

5.1.1 并发与并行的本质区别

在深入goroutine之前，我们必须厘清一个根本性的概念------并发（Concurrency）与并行（Parallelism）是两个不同的概念。

并发是指同时管理 多个任务的能力，关注的是结构------如何将程序分解为多个可独立执行的单元。并发程序可以在单核CPU上运行，通过快速切换（时间片轮转）让多个任务"看起来"在同时进行。
并行是指同时执行 多个任务的能力，关注的是执行------需要多核或多处理器硬件的支持，真正在同一时刻有多个任务在物理上同时运行。

Rob Pike的经典论断："Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once." 并发是关于处理，并行是关于执行。

💡 关键洞察：并发是程序的结构属性，并行是硬件的执行属性。一个好的并发设计在单核上也能提升程序的响应性和结构清晰度，而在多核上则能自然获得并行加速。

goroutine与OS线程的多对多（M:N）关系

Go运行时采用了M:N调度模型，即M个goroutine被映射到N个操作系统线程上执行。这与两种传统模型形成鲜明对比：

模型	示例	优势	劣势
1:1	Java线程、C++ std::thread	真正并行，调度由OS负责	创建成本高（1-8MB栈），上下文切换需进入内核态
N:1	早期Green Thread	创建快，用户态调度	无法利用多核，阻塞操作会冻住整个线程
M:N	Go goroutine	兼顾创建效率和并行能力	运行时调度器实现复杂

M:N模型的精妙之处在于：goroutine在用户态创建和切换（极低成本），Go运行时负责将它们智能地分配到OS线程上（真正并行），而OS线程由内核调度到不同的CPU核心上。当某个goroutine进行阻塞式系统调用时，运行时会将对应的M与P解绑，让P绑定新的M继续执行其他goroutine，避免整个调度器停滞。

5.1.2 goroutine的本质

goroutine是Go运行时管理的轻量级执行单元，它比操作系统线程轻量得多：

特性	goroutine	OS Thread
初始栈大小	2KB（可动态扩缩）	1-8MB（固定）
创建成本	~0.3μs	~10μs
上下文切换	~100ns	~1-10μs
调度方式	用户态协作+抢占	内核态抢占
数量上限	轻松百万级	通常千级

goroutine与线程是多对多关系：N个goroutine被调度到M个操作系统线程上执行，而线程由P（逻辑处理器）管理。

5.1.3 goroutine的创建与基本用法

示例1：使用go关键字启动goroutine

go 复制代码

package main

import (
    "fmt"
    "time"
)

func sayHello(name string) {
    for i := 0; i < 3; i++ {
        fmt.Printf("Hello, %s! (iteration %d)\n", name, i)
        time.Sleep(100 * time.Millisecond)
    }
}

func main() {
    // 使用 go 关键字启动 goroutine
    go sayHello("Alice")
    go sayHello("Bob")

    // 匿名函数形式
    go func(msg string) {
        fmt.Println(msg)
    }("I'm an anonymous goroutine")

    // 主goroutine需要等待，否则程序直接退出
    time.Sleep(1 * time.Second)
    fmt.Println("Main goroutine exiting")
}

⚠️ 注意：主goroutine退出时，所有其他goroutine也会立即终止。上面的time.Sleep只是演示用，生产环境中应使用sync.WaitGroup或Channel来同步。

示例2：使用sync.WaitGroup等待goroutine完成

go 复制代码

package main

import (
    "fmt"
    "sync"
)

func worker(id int, wg *sync.WaitGroup) {
    // 在函数退出时通知WaitGroup完成
    defer wg.Done()

    fmt.Printf("Worker %d starting\n", id)
    // 模拟工作
    for i := 0; i < 3; i++ {
        fmt.Printf("Worker %d working on task %d\n", id, i)
    }
    fmt.Printf("Worker %d done\n", id)
}

func main() {
    var wg sync.WaitGroup

    // 启动5个goroutine
    for i := 1; i <= 5; i++ {
        wg.Add(1) // 在启动goroutine之前调用Add
        go worker(i, &wg)
    }

    wg.Wait() // 阻塞等待所有goroutine完成
    fmt.Println("All workers completed")
}

示例3：goroutine的栈扩容

go 复制代码

package main

import (
    "fmt"
    "runtime"
)

// 递归函数演示栈的动态扩容
func deepRecurse(n int) int {
    if n <= 0 {
        // 打印当前goroutine的栈大小
        var memStats runtime.MemStats
        runtime.ReadMemStats(&memStats)
        fmt.Printf("Current goroutine stack size hint: goroutine count = %d\n",
            runtime.NumGoroutine())
        return 0
    }
    // 每层分配一些局部变量，促使栈扩容
    buf := make([]byte, 1024) // 1KB局部变量
    buf[0] = byte(n)
    return deepRecurse(n-1) + int(buf[0])
}

func main() {
    fmt.Printf("Initial goroutines: %d\n", runtime.NumGoroutine())

    go func() {
        result := deepRecurse(10000)
        fmt.Printf("Deep recurse result: %d\n", result)
    }()

    // 等待goroutine完成（简化演示）
    runtime.Gosched()
    fmt.Printf("After goroutines: %d\n", runtime.NumGoroutine())
}

示例4：goroutine泄漏与避免

go 复制代码

package main

import (
    "fmt"
    "runtime"
    "time"
)

// ❌ 错误示范：goroutine泄漏
func leakyFunction(ch chan int) {
    // 如果无人往ch写数据，这个goroutine将永远阻塞
    val := <-ch
    fmt.Println("Received:", val)
}

// ✅ 正确做法：使用select + context控制退出
func safeFunction(ch chan int, done <-chan struct{}) {
    select {
    case val := <-ch:
        fmt.Println("Received:", val)
    case <-done:
        fmt.Println("Received exit signal, exiting gracefully")
        return
    case <-time.After(5 * time.Second):
        fmt.Println("Timeout, exiting")
        return
    }
}

func main() {
    ch := make(chan int)
    done := make(chan struct{})

    // 启动安全版本的goroutine
    go safeFunction(ch, done)

    fmt.Printf("Goroutines before close: %d\n", runtime.NumGoroutine())

    // 通知退出
    close(done)

    time.Sleep(100 * time.Millisecond)
    fmt.Printf("Goroutines after close: %d\n", runtime.NumGoroutine())
}

5.1.4 goroutine的关键特性

动态栈扩缩：初始2KB，按需翻倍增长（最大默认1GB，Go 1.4后采用连续栈复制技术），缩容在GC时触发
协作式抢占：Go 1.14前基于栈标志的协作式抢占；Go 1.14+引入基于信号的异步抢占，解决密集循环无法调度的问题
GMP调度：多对多映射到OS线程，由Go运行时调度（详见5.6节）

💡 连续栈复制技术（Contiguous Stack）：Go 1.4之前使用分段栈（Segmented Stack），当栈扩容时分配新段并用链表连接。这导致了"热分裂"（hot split）问题------当函数调用在栈边界附近反复横跳时，会频繁分配和释放栈段，造成严重性能抖动。Go 1.4改为连续栈：扩容时分配一块2倍大小的新栈，将旧栈数据整体复制过去，并更新所有指向旧栈的指针。虽然指针更新成本较高，但避免了热分裂，实际性能更优。

5.2 Channel：通信与同步

Channel是Go并发编程的一等公民，是实现CSP模型的核心机制。通过Channel，goroutine之间可以安全地传递数据，天然提供同步保证。

5.2.0 Channel底层原理

无缓冲Channel的同步机制

无缓冲channel的本质是一个同步原语 ------发送操作必须阻塞，直到有接收者就绪；接收操作同样必须阻塞，直到有发送者就绪。这种"汇合点"（rendezvous）语义意味着：发送和接收同时发生，数据不经过任何中间缓冲，直接从发送方的栈复制到接收方的栈。

从底层实现来看，当goroutine A向无缓冲channel发送数据时：

如果没有接收者，A被挂起，将自己（连同数据）放入channel的sendq等待队列
当goroutine B执行接收时，运行时从sendq中取出A，直接将数据复制到B的栈上，然后唤醒A
如果B先执行接收、A后发送，则对称处理（B放入recvq）

💡 核心洞察 ：无缓冲channel的"无缓冲"不只是容量为零------它是零延迟传输的保证。发送者确认数据被接收者拿到后才继续执行，这提供了最强的同步保证。相比之下，带缓冲channel将"发送"和"接收"在时间上解耦了。

带缓冲Channel的异步特性

带缓冲channel内部维护一个环形队列（circular queue）作为缓冲区。当缓冲区未满时，发送操作将数据放入队列后立即返回，不阻塞；当缓冲区非空时，接收操作从队列取出数据后立即返回。只有在缓冲区满时发送才阻塞，缓冲区空时接收才阻塞。

这意味着带缓冲channel将生产者和消费者在时间上解耦------生产者可以"先生产、后交付"，消费者可以"先交付、后消费"。这是一种异步的、松耦合的通信模式。

⚠️ 重要区别：无缓冲channel保证发送者知道数据已被接收（强同步），带缓冲channel只保证数据已放入缓冲区（弱同步）。选择哪种取决于业务语义：需要确认"对方已收到"用无缓冲，只需"发出去了"用带缓冲。

关闭Channel的语义

close(ch)的本质是通知而非释放资源。关闭channel会做两件事：

将channel的closed标志设为true
释放所有等待在recvq中的goroutine------它们会收到channel的零值

关闭channel的语义是"没有更多数据了"，它是一种广播通知机制。关键规则：

向已关闭的channel发送会panic------这是有意为之的设计，防止向已声明"结束"的通道意外写入
从已关闭的channel接收会返回零值和false------这允许接收者优雅地检测结束信号
关闭已关闭的channel也会panic
由发送方关闭，不由接收方关闭------因为只有发送方知道何时没有更多数据

💡 关闭channel ≠ 释放资源：关闭channel不会释放channel本身占用的内存，也不会释放缓冲区中的数据。它只是一个状态标记。channel的内存回收由GC在没有任何goroutine引用时自动完成。

nil Channel的永久阻塞特性及动态禁用select分支

nil channel（未初始化的channel或显式设为nil的channel）有一个独特且有用的行为：

向nil channel发送：永久阻塞
从nil channel接收：永久阻塞
关闭nil channel：panic

这看似是陷阱，实际上是一个强大的动态禁用技巧。在select语句中，一个被置为nil的case永远不会被选中（因为操作会阻塞），相当于动态地将该分支从select中"移除"：

go 复制代码

// 动态禁用select分支的惯用法
for {
    select {
    case v, ok := <-ch1:
        if !ok {
            ch1 = nil // ch1已关闭，置为nil后该分支永久阻塞，不再被选中
            continue
        }
        process(v)
    case v, ok := <-ch2:
        if !ok {
            ch2 = nil // ch2已关闭，同理禁用
            continue
        }
        process(v)
    }
    // 当ch1和ch2都为nil时，如果没有default，select会永久阻塞
    // 因此通常需要加退出条件
}

💡 设计哲学：Go没有提供"从select中删除case"的语法，nil channel的永久阻塞特性巧妙地填补了这一空白，使得可以在运行时动态改变select的行为。

5.2.1 Channel的惯用法理论

Channel不仅是一个数据传递管道，它还能表达丰富的并发语义。以下是四种核心惯用法：

1. 信号传递（Signaling）

Channel最基础的用法是传递事件信号而非数据：

1对1通知 ：一个goroutine通知另一个goroutine某事件已发生。通常使用chan struct{}（零大小通道），因为信号本身不携带数据，只关心"发生了"这个事实。

go 复制代码

done := make(chan struct{})
go func() {
    defer close(done) // close作为广播信号
    doWork()
}()
<-done // 阻塞等待完成信号

1对N广播 ：close(ch)是一种广播机制------所有等待在该channel上的接收者都会被同时唤醒。这比逐个发送信号高效得多，因为close只需一次操作即可通知所有等待者。

2. 替代锁机制（通信共享内存 vs 共享内存通信）

Go的核心哲学是"不要通过共享内存来通信，而要通过通信来共享内存"。这两种方式的根本区别：

方式	机制	心智模型
共享内存通信	共享变量 + 锁保护	多人共写一块白板，需轮流使用
通信共享内存	Channel传递数据所有权	传递接力棒，同一时刻只有一人持有

用Channel替代锁的关键思路：将共享状态限制在单个goroutine内部，其他goroutine通过Channel请求和获取状态，从而将并发安全问题转化为Channel通信问题。这就是CSP模型的精髓。

3. 消息队列（带缓冲Channel的FIFO特性）

带缓冲channel天然实现了FIFO（先进先出）队列。生产者发送的数据按顺序排列在缓冲区中，消费者按相同顺序取出。这种模式非常适合生产者-消费者场景：

缓冲区大小决定了生产者领先消费者的最大距离
当缓冲区满时，生产者被背压（backpressure），自然实现流控

4. 计数信号量（缓冲容量 = 最大并发数）

利用带缓冲channel的容量限制，可以实现计数信号量------控制同时执行某操作的goroutine数量：

go 复制代码

sem := make(chan struct{}, maxConcurrent) // 缓冲容量=最大并发数
sem <- struct{}{} // 获取信号量（占位），缓冲区满时阻塞
doWork()
<-sem // 释放信号量（腾位）

💡 原理：每次sem <- struct{}{}尝试向缓冲区放入一个元素，当缓冲区已有maxConcurrent个元素时，新的发送被阻塞------这意味着已有maxConcurrent个goroutine在并发执行。当某个goroutine完成工作后执行<-sem释放一个位置，等待的goroutine才能进入。

5.2.2 Channel的声明与初始化

示例1：Channel的基本操作

go 复制代码

package main

import "fmt"

func main() {
    // === 声明与初始化 ===
    // 无缓冲通道（同步通道）：发送和接收必须同时就绪
    unbuffered := make(chan int)

    // 有缓冲通道：缓冲区满前发送不阻塞，缓冲区空前接收不阻塞
    buffered := make(chan int, 3)

    // === 读写数据 ===
    // 启动goroutine往无缓冲通道写数据
    go func() {
        unbuffered <- 42 // 发送数据
    }()

    val := <-unbuffered // 接收数据
    fmt.Println("Received from unbuffered:", val)

    // 有缓冲通道可以直接在主goroutine中操作
    buffered <- 1
    buffered <- 2
    buffered <- 3
    // buffered <- 4  // 缓冲区满，会阻塞！

    fmt.Println("Received from buffered:", <-buffered) // 1
    fmt.Println("Received from buffered:", <-buffered) // 2
    fmt.Println("Received from buffered:", <-buffered) // 3

    // === 关闭通道 ===
    close(buffered)

    // 从已关闭的通道读取，返回零值
    val, ok := <-buffered
    fmt.Printf("Closed channel read: val=%d, ok=%v\n", val, ok) // val=0, ok=false

    // 遍历已关闭的通道
    ch := make(chan int, 5)
    for i := 1; i <= 5; i++ {
        ch <- i
    }
    close(ch)

    fmt.Print("Range over closed channel: ")
    for v := range ch {
        fmt.Print(v, " ")
    }
    fmt.Println()
}

示例2：Channel作为函数参数和返回值

go 复制代码

package main

import "fmt"

// Channel作为参数：指定方向，增强类型安全
func producer(out chan<- int) { // 只写通道
    for i := 0; i < 5; i++ {
        out <- i * 10
    }
    close(out)
}

func consumer(in <-chan int) { // 只读通道
    for val := range in {
        fmt.Println("Consumed:", val)
    }
}

// Channel作为返回值
func fibonacci(n int) <-chan int {
    ch := make(chan int)
    go func() {
        defer close(ch)
        a, b := 0, 1
        for i := 0; i < n; i++ {
            ch <- a
            a, b = b, a+b
        }
    }()
    return ch // 返回只读通道，防止外部写入
}

func main() {
    ch := make(chan int)
    go producer(ch)
    consumer(ch)

    fmt.Println("--- Fibonacci ---")
    for val := range fibonacci(10) {
        fmt.Print(val, " ")
    }
    fmt.Println()
}

示例3：单向通道与通道方向约束

go 复制代码

package main

import "fmt"

// 单向通道在编译期提供安全保证
// 试图在只读通道上写入，或在只写通道上读取，编译器会报错

type Pipeline struct {
    data chan int
}

func (p *Pipeline) Source() <-chan int { // 返回只读通道
    out := make(chan int)
    go func() {
        defer close(out)
        for i := 0; i < 10; i++ {
            out <- i
        }
    }()
    return out
}

func (p *Pipeline) Process(in <-chan int) <-chan int { // 接收只读，返回只读
    out := make(chan int)
    go func() {
        defer close(out)
        for val := range in {
            out <- val * val // 处理：求平方
        }
    }()
    return out
}

func (p *Pipeline) Sink(in <-chan int) { // 接收只读通道
    for val := range in {
        fmt.Println("Result:", val)
    }
}

func main() {
    pipe := &Pipeline{}
    source := pipe.Source()
    processed := pipe.Process(source)
    pipe.Sink(processed)
}

示例4：缓冲通道与非缓冲通道的行为差异

go 复制代码

package main

import (
    "fmt"
    "time"
)

func main() {
    // 非缓冲通道：发送和接收必须"同时"发生（同步）
    unbuf := make(chan string)

    go func() {
        fmt.Println("Sender: about to send on unbuffered channel...")
        unbuf <- "hello" // 阻塞直到有人接收
        fmt.Println("Sender: message received by receiver!")
    }()

    time.Sleep(100 * time.Millisecond) // 确保sender先执行到发送
    fmt.Println("Receiver: about to receive...")
    msg := <-unbuf
    fmt.Println("Receiver: got", msg)

    // 缓冲通道：缓冲区未满时发送不阻塞
    buf := make(chan string, 2)

    buf <- "first"  // 不阻塞
    buf <- "second" // 不阻塞
    // buf <- "third"  // 会阻塞，缓冲区已满

    fmt.Println("Buffered channel sent 2 messages without blocking")
    fmt.Println("Read:", <-buf)
    fmt.Println("Read:", <-buf)
}

示例5：使用Channel实现信号量模式（限流）

go 复制代码

package main

import (
    "fmt"
    "sync"
    "time"
)

// 使用缓冲通道实现并发限制
func main() {
    const maxConcurrent = 3
    const totalTasks = 10

    // 信号量：缓冲大小即为最大并发数
    semaphore := make(chan struct{}, maxConcurrent)
    var wg sync.WaitGroup

    for i := 1; i <= totalTasks; i++ {
        wg.Add(1)
        go func(taskID int) {
            defer wg.Done()

            // 获取信号量（占位）
            semaphore <- struct{}{}
            fmt.Printf("Task %d started at %s\n", taskID, time.Now().Format("15:04:05.000"))

            // 模拟工作
            time.Sleep(500 * time.Millisecond)

            fmt.Printf("Task %d finished at %s\n", taskID, time.Now().Format("15:04:05.000"))
            // 释放信号量
            <-semaphore
        }(i)
    }

    wg.Wait()
    fmt.Println("All tasks completed")
}

5.2.3 Channel的核心规则

操作	未缓冲通道	缓冲通道（未满/未空）	缓冲通道（满/空）	已关闭通道
发送	阻塞直到接收	正常发送	阻塞	panic
接收	阻塞直到发送	正常接收	阻塞	返回零值+false
关闭	成功	成功	成功	panic

💡 最佳实践：由发送方关闭通道，不要在接收方关闭。关闭通道的意义在于通知接收方"没有更多数据了"。

5.3 select多路复用

select是Go中处理多个Channel操作的控制结构，类似于switch但专门用于Channel通信。

5.3.0 select底层实现原理

select的底层实现远比表面看起来复杂。Go编译器将select语句转换为对runtime.selectgo函数的调用，其核心流程如下：

1. case排序（随机化）

selectgo首先将所有case按随机顺序排列。这就是为什么当多个case同时就绪时，Go能保证随机选择------它不是在运行时做随机决策，而是在编译期就打乱了case的检查顺序。这种设计从根本上避免了某个channel饥饿的问题。

2. 轮询检查

按随机化后的顺序，依次检查每个case的channel操作是否可以立即完成（无阻塞）：

对于发送case：检查目标channel的缓冲区是否有空间或是否有接收者等待
对于接收case：检查源channel的缓冲区是否有数据或是否有发送者等待

如果找到就绪的case，立即执行并返回。

3. 注册等待

如果没有case就绪（且没有default），selectgo会将当前goroutine注册到所有case涉及的channel的等待队列上，然后挂起当前goroutine。

4. 唤醒与清理

当某个channel操作就绪时（例如有数据到达），goroutine被唤醒。此时需要从其他所有channel的等待队列中移除当前goroutine的注册，然后执行就绪的case。

⚠️ 性能考量 ：当select包含大量case时，注册和清理操作的开销为O(n)------需要遍历所有channel的等待队列。因此，select不适合处理数百个channel的场景，此时应考虑使用反射（reflect.Select）或重新设计架构。
💡 设计哲学：select的随机化选择与Go的"不偏袒"哲学一致------没有隐式优先级，所有channel平等竞争。如果你需要优先级，必须通过嵌套select或额外逻辑显式实现。

5.3.2 select的基本行为

示例1：select多路监听

go 复制代码

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(time.Duration(rand.Intn(500)) * time.Millisecond)
        ch1 <- "from channel 1"
    }()

    go func() {
        time.Sleep(time.Duration(rand.Intn(500)) * time.Millisecond)
        ch2 <- "from channel 2"
    }()

    // select 等待多个通道操作，哪个先就绪就执行哪个
    select {
    case msg1 := <-ch1:
        fmt.Println("Received:", msg1)
    case msg2 := <-ch2:
        fmt.Println("Received:", msg2)
    }
}

示例2：select实现超时控制

go 复制代码

package main

import (
    "fmt"
    "time"
)

func slowOperation() <-chan string {
    ch := make(chan string)
    go func() {
        time.Sleep(3 * time.Second) // 模拟耗时操作
        ch <- "operation result"
    }()
    return ch
}

func main() {
    resultCh := slowOperation()

    select {
    case result := <-resultCh:
        fmt.Println("Got result:", result)
    case <-time.After(2 * time.Second):
        // time.After 返回一个在指定时间后发送当前时间的通道
        fmt.Println("Operation timed out after 2 seconds!")
    }
}

示例3：select实现非阻塞读写

go 复制代码

package main

import "fmt"

func main() {
    ch := make(chan int, 1)

    // 非阻塞发送
    select {
    case ch <- 42:
        fmt.Println("Sent 42 to channel")
    default:
        fmt.Println("Channel is full, cannot send")
    }

    // 非阻塞接收
    select {
    case val := <-ch:
        fmt.Println("Received:", val)
    default:
        fmt.Println("Channel is empty, cannot receive")
    }

    // 再次非阻塞接收（此时通道为空）
    select {
    case val := <-ch:
        fmt.Println("Received:", val)
    default:
        fmt.Println("Channel is empty, nothing to receive")
    }
}

示例4：select循环实现事件循环

go 复制代码

package main

import (
    "fmt"
    "math/rand"
    "time"
)

func generator(name string) <-chan int {
    ch := make(chan int)
    go func() {
        for i := 0; ; i++ {
            ch <- i
            time.Sleep(time.Duration(rand.Intn(500)+100) * time.Millisecond)
        }
    }()
    return ch
}

func main() {
    gen1 := generator("Generator-1")
    gen2 := generator("Generator-2")

    // 使用 for-select 循环持续处理
    timeout := time.After(3 * time.Second)

Loop:
    for {
        select {
        case v := <-gen1:
            fmt.Printf("From gen1: %d\n", v)
        case v := <-gen2:
            fmt.Printf("From gen2: %d\n", v)
        case <-timeout:
            fmt.Println("Time's up, exiting event loop")
            break LOOP // 使用标签跳出外层for循环
        }
    }

    fmt.Println("Event loop ended")
}

示例5：select实现定时器（Ticker）

go 复制代码

package main

import (
    "fmt"
    "time"
)

func main() {
    ticker := time.NewTicker(500 * time.Millisecond)
    done := make(chan bool)

    go func() {
        time.Sleep(3 * time.Second)
        done <- true
    }()

    count := 0
    for {
        select {
        case t := <-ticker.C:
            count++
            fmt.Printf("Tick #%d at %s\n", count, t.Format("15:04:05.000"))
        case <-done:
            ticker.Stop()
            fmt.Println("Ticker stopped")
            return
        }
    }
}

5.3.3 select的关键特性

随机选择：当多个case同时就绪时，Go会随机选择一个执行，避免饥饿
阻塞等待：没有case就绪且没有default时，select会阻塞
空select永久阻塞 ：select{}会永远阻塞当前goroutine
只操作Channel：select的case只能是Channel操作，不能是普通条件

5.4 sync包全家桶

sync包提供了低级别的同步原语，适用于不需要通过Channel通信、只需简单同步的场景。

5.4.0 sync包各组件的设计原理

Mutex的饥饿模式与正常模式

Go 1.9为Mutex引入了两种模式，解决了公平性问题：

正常模式（Normal Mode）：当一个goroutine尝试获取锁时，它首先尝试几次CAS（自旋），如果失败就进入等待队列。当锁释放时，唤醒队列头部的等待者，但此时新来的goroutine也可以竞争锁------由于新来的goroutine正在CPU上运行，它通常比刚被唤醒的等待者更快获得锁（这就是"窃取"现象）。正常模式吞吐量高，但可能导致队列尾部的等待者长时间拿不到锁。
饥饿模式（Starvation Mode）：当某个等待者等待时间超过1ms时，Mutex切换到饥饿模式。在饥饿模式下，锁的所有权直接从释放者移交给队列头部的等待者，新来的goroutine不再竞争，只能排到队列尾部。饥饿模式保证了公平性，但吞吐量降低。当队列中最后一个等待者获取锁，或者等待者的等待时间小于1ms时，Mutex切回正常模式。

💡 设计哲学：Mutex的两种模式是吞吐量与公平性之间的精妙平衡。正常模式优先吞吐量（让正在运行的goroutine先拿锁，避免上下文切换），饥饿模式兜底公平性（防止极端情况下某些goroutine永远等不到锁）。

RWMutex的读写分离

RWMutex将锁分为读锁和写锁，核心思想是读操作可以并发，写操作必须独占。底层实现中，RWMutex内部包含一个Mutex和一个信号量：

获取读锁：原子增加reader计数器，如果此时有写锁，则阻塞等待
获取写锁：先获取内部Mutex，然后等待所有读者释放读锁
写者饥饿问题：Go的RWMutex设计上倾向于写者------当写者等待时，新的读者也会被阻塞，防止写者被无限涌入的读者饿死

⚠️ 注意事项 ：RWMutex只在读多写少的场景下才有优势。如果读写比例接近1:1，RWMutex的额外开销（维护reader计数器、区分读写路径）反而会使性能不如普通Mutex。

sync.Pool的GC清理机制和伪共享优化

sync.Pool的设计目标是减少GC压力，而不是做持久化的对象池。它的两个关键机制：

GC清理机制 ：每次GC时，Pool中所有对象会被清除。这是有意为之------Pool只缓存短期存活的对象，避免Pool成为"隐式全局变量"导致内存泄漏。注册GC回调的时机是在首次Put时，通过runtime_registerPoolCleanup实现。
伪共享（False Sharing）优化 ：Pool为每个P（逻辑处理器）维护一个本地池（poolLocal），访问本地池无需加锁。每个poolLocal的大小被填充至128字节（一个缓存行大小），避免两个P的本地池共享同一缓存行导致的伪共享问题------即两个CPU核心因修改同一缓存行的不同变量而频繁使对方缓存失效。

⚠️ 不适合持久化：由于GC清理机制，sync.Pool不适合用作连接池（如数据库连接池）。连接池应使用独立的数据结构管理。

sync.Map的读多写少优化

sync.Map针对两种典型场景做了优化：

key稳定，value频繁更新：使用read map（原子读）+ dirty map（加锁写）的双层结构
并发读多写少：读操作优先走read map，无锁路径；只有read miss时才加锁查dirty map

核心数据结构：

read：一个原子指向的readOnly结构，包含一个map和amended标志
dirty：一个需要加锁访问的map，包含read中不存在的新条目

查找路径：先查read（无锁，原子操作）→ miss → 加锁查dirty → 将dirty提升为read

💡 为什么不用map+RWMutex？ 对于读多写少的场景，sync.Map的read map提供了完全无锁的读路径，而map+RWMutex即使是读操作也需要获取读锁（原子操作+可能的自旋等待），性能差距显著。但对于写多的场景，sync.Map的dirty map提升（从dirty到read的拷贝）开销很大，反而不如map+RWMutex。

5.4.1 sync.Mutex与sync.RWMutex

示例1：互斥锁保护共享资源

go 复制代码

package main

import (
    "fmt"
    "sync"
)

// ❌ 不加锁的并发写入存在数据争用
type UnsafeCounter struct {
    value int
}

func (c *UnsafeCounter) Increment() {
    c.value++ // 非原子操作：读取-修改-写入
}

// ✅ 使用互斥锁保护
type SafeCounter struct {
    mu    sync.Mutex
    value int
}

func (c *SafeCounter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++
}

func (c *SafeCounter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.value
}

func main() {
    var counter SafeCounter
    var wg sync.WaitGroup

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter.Increment()
        }()
    }

    wg.Wait()
    fmt.Printf("Counter value: %d\n", counter.Value()) // 正确输出1000
}

示例2：读写锁优化读多写少场景

go 复制代码

package main

import (
    "fmt"
    "sync"
    "time"
)

type SafeMap struct {
    mu   sync.RWMutex
    data map[string]string
}

func (m *SafeMap) Get(key string) (string, bool) {
    m.mu.RLock()         // 读锁：允许多个读者并发
    defer m.mu.RUnlock()
    val, ok := m.data[key]
    return val, ok
}

func (m *SafeMap) Set(key, value string) {
    m.mu.Lock()          // 写锁：独占访问
    defer m.mu.Unlock()
    m.data[key] = value
}

func main() {
    sm := &SafeMap{data: make(map[string]string)}
    var wg sync.WaitGroup

    // 先写入一些数据
    sm.Set("name", "Go")
    sm.Set("version", "1.22")

    // 大量并发读
    for i := 0; i < 100; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            val, ok := sm.Get("name")
            if ok {
                _ = val // 使用值
            }
        }(i)
    }

    // 少量并发写
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            sm.Set(fmt.Sprintf("key-%d", id), fmt.Sprintf("value-%d", id))
        }(i)
    }

    wg.Wait()
    fmt.Println("All reads and writes completed")
}

示例3：避免死锁------锁的嵌套

go 复制代码

package main

import (
    "fmt"
    "sync"
    "time"
)

// ❌ 死锁示范：交叉持锁
func deadlockDemo() {
    var mu1, mu2 sync.Mutex

    go func() {
        mu1.Lock()
        time.Sleep(100 * time.Millisecond)
        mu2.Lock() // 等待mu2，但main goroutine持有mu2
        mu2.Unlock()
        mu1.Unlock()
    }()

    mu2.Lock()
    time.Sleep(100 * time.Millisecond)
    mu1.Lock() // 等待mu1，但上面的goroutine持有mu1 → 死锁！
    mu1.Unlock()
    mu2.Unlock()
}

// ✅ 解决方案：统一锁的获取顺序
func safeLockDemo() {
    var mu1, mu2 sync.Mutex
    var wg sync.WaitGroup

    // 始终按 mu1 → mu2 的顺序加锁
    acquireBoth := func() {
        mu1.Lock()
        defer mu1.Unlock()
        mu2.Lock()
        defer mu2.Unlock()
        fmt.Println("Acquired both locks safely")
    }

    wg.Add(2)
    go func() {
        defer wg.Done()
        acquireBoth()
    }()
    go func() {
        defer wg.Done()
        acquireBoth()
    }()
    wg.Wait()
}

func main() {
    safeLockDemo()
    // deadlockDemo() // 取消注释将导致死锁
}

5.4.2 sync.Once

示例4：单次初始化

go 复制代码

package main

import (
    "fmt"
    "sync"
)

type Singleton struct {
    value string
}

var (
    instance *Singleton
    once     sync.Once
)

func GetInstance() *Singleton {
    once.Do(func() {
        fmt.Println("Initializing Singleton (only once)")
        instance = &Singleton{value: "I am the only instance"}
    })
    return instance
}

func main() {
    var wg sync.WaitGroup

    // 多个goroutine并发获取实例，但初始化只执行一次
    for i := 0; i < 10; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            inst := GetInstance()
            fmt.Printf("Goroutine %d got instance: %s (%p)\n",
                id, inst.value, inst)
        }(i)
    }

    wg.Wait()
}

💡 sync.Once的实现原理 ：Once内部使用一个原子计数器和Mutex。快速路径是原子检查计数器是否为0（无锁），如果为1则直接返回。慢速路径获取Mutex，再次检查后执行函数。Double-check确保了即使在并发场景下，函数也只执行一次。但注意：如果f()panic，Once认为它没有成功执行，后续调用会再次尝试执行f()。

5.4.3 sync.Cond

示例5：条件变量------生产者消费者模式

go 复制代码

package main

import (
    "fmt"
    "sync"
    "time"
)

type Queue struct {
    items []int
    cap   int
    cond  *sync.Cond
}

func NewQueue(cap int) *Queue {
    q := &Queue{
        items: make([]int, 0),
        cap:   cap,
    }
    q.cond = sync.NewCond(&sync.Mutex{})
    return q
}

func (q *Queue) Put(item int) {
    q.cond.L.Lock()
    defer q.cond.L.Unlock()

    // 队列满时等待
    for len(q.items) >= q.cap {
        q.cond.Wait() // 释放锁并等待，被唤醒时重新获取锁
    }

    q.items = append(q.items, item)
    q.cond.Signal() // 通知一个等待的消费者
}

func (q *Queue) Get() int {
    q.cond.L.Lock()
    defer q.cond.L.Unlock()

    // 队列空时等待
    for len(q.items) == 0 {
        q.cond.Wait()
    }

    item := q.items[0]
    q.items = q.items[1:]
    q.cond.Signal() // 通知一个等待的生产者
    return item
}

func main() {
    q := NewQueue(3)
    var wg sync.WaitGroup

    // 生产者
    wg.Add(1)
    go func() {
        defer wg.Done()
        for i := 1; i <= 10; i++ {
            q.Put(i)
            fmt.Printf("Produced: %d\n", i)
            time.Sleep(100 * time.Millisecond)
        }
    }()

    // 消费者
    wg.Add(1)
    go func() {
        defer wg.Done()
        for i := 1; i <= 10; i++ {
            item := q.Get()
            fmt.Printf("  Consumed: %d\n", item)
            time.Sleep(200 * time.Millisecond)
        }
    }()

    wg.Wait()
}

💡 为什么Wait必须在循环中调用？ 这就是"Haskell条件变量法则"------Wait()被唤醒不代表条件满足，可能有以下原因：(1) 虚假唤醒（Spurious Wakeup），操作系统层面可能无故唤醒；(2) 多个等待者被Broadcast同时唤醒，但只有一个能获取资源。因此必须在循环中重新检查条件。

5.4.4 sync.Pool

示例6：对象池减少GC压力

go 复制代码

package main

import (
    "fmt"
    "sync"
)

type Buffer struct {
    Data []byte
}

var bufferPool = sync.Pool{
    New: func() interface{} {
        // 当池为空时创建新对象
        fmt.Println("  Creating new buffer")
        return &Buffer{Data: make([]byte, 1024)}
    },
}

func processBuffer(id int) {
    // 从池中获取
    buf := bufferPool.Get().(*Buffer)
    fmt.Printf("Worker %d got buffer (len=%d)\n", id, len(buf.Data))

    // 使用buffer...
    buf.Data[0] = byte(id)

    // 重置状态后放回池中
    for i := range buf.Data {
        buf.Data[i] = 0
    }
    bufferPool.Put(buf)
}

func main() {
    // 第一次获取：池为空，创建新对象
    processBuffer(1)
    processBuffer(2) // 可能复用之前的对象

    // 注意：Pool中的对象可能在任意时刻被GC回收
    // Pool不适合做持久化的连接池，适合做临时对象的缓存
    fmt.Println("\n--- After GC ---")
    // 手动触发GC，Pool中的对象可能被清除
    // runtime.GC()
    processBuffer(3) // GC后可能需要重新创建
}

5.4.5 sync.Map

示例7：并发安全的Map

go 复制代码

package main

import (
    "fmt"
    "sync"
)

func main() {
    var m sync.Map

    // 写入
    m.Store("name", "Go")
    m.Store("version", 1.22)
    m.Store("features", []string{"goroutine", "channel", "interface"})

    // 读取
    if val, ok := m.Load("name"); ok {
        fmt.Println("name:", val)
    }

    // 读取不存在的key
    if _, ok := m.Load("nonexistent"); !ok {
        fmt.Println("Key 'nonexistent' not found")
    }

    // LoadOrStore：存在则读取，不存在则存储
    actual, loaded := m.LoadOrStore("name", "Rust")
    fmt.Printf("LoadOrStore 'name': actual=%v, loaded=%v\n", actual, loaded)

    // Range遍历
    fmt.Println("All entries:")
    m.Range(func(key, value interface{}) bool {
        fmt.Printf("  %v = %v\n", key, value)
        return true // 返回false停止遍历
    })

    // Delete
    m.Delete("version")
    fmt.Println("After deleting 'version':")
    m.Range(func(key, value interface{}) bool {
        fmt.Printf("  %v = %v\n", key, value)
        return true
    })
}

💡 sync.Map vs map+Mutex ：sync.Map针对以下两种场景优化：(1) key稳定，value频繁更新；(2) 并发读多写少。其他场景使用map + sync.RWMutex可能更高效。

5.4.6 atomic原子操作

示例8：原子操作

go 复制代码

package main

import (
    "fmt"
    "sync"
    "sync/atomic"
)

func main() {
    var counter int64
    var wg sync.WaitGroup

    // atomic.Add：原子加法
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            atomic.AddInt64(&counter, 1) // 原子递增
        }()
    }
    wg.Wait()
    fmt.Printf("Atomic counter: %d\n", atomic.LoadInt64(&counter))

    // atomic.CompareAndSwap：比较并交换（CAS）
    var value int64 = 100
    swapped := atomic.CompareAndSwapInt64(&value, 100, 200)
    fmt.Printf("CAS (100→200): swapped=%v, value=%d\n", swapped, value)

    swapped = atomic.CompareAndSwapInt64(&value, 100, 300)
    fmt.Printf("CAS (100→300): swapped=%v, value=%d\n", swapped, value)

    // atomic.Value：存储任意类型的值
    var config atomic.Value
    config.Store(map[string]string{"env": "production"})
    cfg := config.Load().(map[string]string)
    fmt.Printf("Config: %v\n", cfg)
}

💡 原子操作 vs Mutex：原子操作适用于简单的计数器、标志位等场景，性能优于Mutex（无锁路径，直接使用CPU的CAS指令）。但对于复合操作（如"读取-判断-写入"），如果无法用单个原子操作表达，就必须使用Mutex。一个经验法则是：如果能用atomic，就用atomic；如果逻辑太复杂，就用Mutex。

5.5 并发模式与最佳实践

5.5.0 并发安全的理论基础

数据争用（Data Race）vs 竞态条件（Race Condition）

这两个概念经常被混淆，但它们是不同层次的问题：

数据争用（Data Race） ：指两个或多个goroutine并发访问同一内存，且至少一个是写操作，且没有同步机制。数据争用是未定义行为------程序的结果完全不可预测，可能在不同运行中产生不同结果，甚至崩溃。数据争用永远是bug，必须修复。
竞态条件（Race Condition） ：指程序的正确性依赖于操作的执行顺序，但这个顺序无法保证。竞态条件是一个逻辑问题------即使所有操作都正确同步（没有数据争用），程序仍然可能因为操作顺序的不确定性而产生错误结果。

go 复制代码

// 数据争用：无同步的并发读写
var balance int
go func() { balance += 100 }()  // 写
fmt.Println(balance)              // 读 --- 数据争用！

// 竞态条件（无数据争用，但仍有逻辑问题）
mu.Lock()
if balance >= 100 {
    balance -= 100  // 在检查和使用之间，其他goroutine可能已经修改了balance
}
mu.Unlock()

💡 关键区分 ：数据争用是同步层面的bug，可以用-race检测器发现；竞态条件是逻辑层面的bug，需要通过正确的程序设计（如原子化的"检查并操作"）来避免。消除数据争用不等于消除竞态条件。

Go Race检测器的原理

Go的竞态检测器基于**ThreadSanitizer（TSan）**技术，其工作原理：

编译时插桩 ：go build -race会在编译时为每个内存访问插入检查代码
运行时追踪：插桩后的程序维护一个"影子内存"（shadow memory），记录每个内存位置的访问历史------哪些goroutine在什么时刻以什么方式（读/写）访问过
冲突检测：当新的内存访问发生时，检查其与历史记录是否存在"冲突"------即两个不同goroutine的访问中至少有一个是写操作，且没有happens-before关系
报告：发现冲突时，输出详细的调用栈信息

⚠️ 局限性 ：race检测器有约5-10倍的性能损耗和5-10倍的内存开销，因此仅用于开发和测试，不用于生产。更重要的是，race检测器只能发现实际执行到的代码路径中的数据争用------如果某个争用条件在你的测试中没有触发，检测器就无法发现。因此，高覆盖率的测试对race检测至关重要。

5.5.1 Context专节：优雅退出与级联取消

Context的设计动机

在Go 1.7正式引入context包之前，Go生态面临一个严峻的问题------协程级联退出。当一个请求（如HTTP请求）启动了多个goroutine（数据库查询、RPC调用、缓存读取等），如果请求被取消或超时，所有相关的goroutine都应该及时退出以释放资源。但在没有统一机制的情况下，每个库都需要自己发明退出信号传递方式，导致：

API不统一：有的用done chan struct{}，有的用stop()方法，有的用cancel()
级联退出困难：子任务又启动了孙子任务，退出信号难以层层传递
截止时间无法传播：超时设置只在最外层有效，内层操作不知道整体时限

Go团队在golang.org/x/net/context实验包经过两年实践后，将context正式纳入标准库（Go 1.7），并要求所有标准库的阻塞操作都接受context参数。

Context接口4个方法的理论含义

go 复制代码

type Context interface {
    Deadline() (deadline time.Time, ok bool)  // 截止时间
    Done() <-chan struct{}                     // 退出信号
    Err() error                                // 退出原因
    Value(key any) any                         // 请求级值
}

Deadline()：返回此context的截止时间。如果ok为false，表示没有设置截止时间。接收方可以用此信息决定是否还有足够时间启动新操作，而不是盲目开始后又被中断。
Done() ：返回一个只读channel，当context被取消或超时时，该channel会被关闭。选择用channel close而非发送值是因为：close是广播操作，可以同时通知所有监听者；而发送值只能被一个接收者接收。
Err() ：返回context被取消的原因。在Done channel关闭后调用，返回context.Canceled（被主动取消）或context.DeadlineExceeded（超时）。这对于错误日志和链路追踪至关重要------你需要知道是"用户主动取消"还是"操作超时"。
Value()：获取请求级别的值（如request ID、认证token等）。这是一个备受争议的方法------它本质上是一个类型安全的全局变量，容易滥用。Go社区的最佳实践是只在请求作用域内传递元数据，绝不传递业务参数。

WithCancel/WithTimeout/WithDeadline的派生机制

Context的核心设计是派生（Derivation）------从父context派生子context，形成一棵context树：

WithCancel(parent)：派生一个可手动取消的context，返回cancel函数
WithTimeout(parent, timeout)：等价于WithDeadline(parent, time.Now().Add(timeout))
WithDeadline(parent, deadline)：派生一个带截止时间的context

派生规则：

子context的截止时间不得晚于父context（取更早的）
父context退出导致子context级联退出
子context退出不影响父context和兄弟context

父Context退出导致子Context级联退出，反之不然

这是context设计的核心语义------退出信号只向下传播，不向上传播。理由很直观：父任务取消了，子任务没有继续存在的意义；但子任务完成了或被取消了，父任务可能还有其他子任务在进行。

Context底层原理

利用channel close通知所有监听协程

所有context类型的核心通知机制都是close(chan struct{})。当cancel函数被调用或超时到达时，context关闭其内部的done channel。因为channel close是广播操作，所有监听ctx.Done()的goroutine都会被唤醒。

cancelCtx结构

go 复制代码

type cancelCtx struct {
    Context       // 嵌入父context
    mu       sync.Mutex
    done     chan struct{}       // 懒创建的done channel
    children map[canceler]struct{} // 子context集合
    err      error               // 取消原因
}

cancel函数的执行逻辑：

加锁，设置err
关闭done channel（广播通知所有监听者）
遍历children，逐个取消子context（级联退出）
从父context的children中移除自己

timerCtx结构

go 复制代码

type timerCtx struct {
    cancelCtx
    timer    *time.Timer  // 定时器
    deadline time.Time    // 截止时间
}

timerCtx在cancelCtx基础上增加了定时器。创建时启动一个time.AfterFunc定时器，到达截止时间后自动调用cancel函数。

propagateCancel级联绑定

当创建子context时，propagateCancel(parent, child)函数建立级联关系：

如果父context已经取消，直接取消子context
如果父context的Done()返回nil（如context.Background()），无需绑定
否则，启动一个goroutine监听父context的Done，一旦父context退出就取消子context
将子context加入父context的children集合

💡 为什么用goroutine监听？ 这是为了避免在context创建的热路径上加锁。启动一个轻量的goroutine比在每次创建子context时获取父context的锁更高效。

Context最佳实践

不要在Context中存储业务数据------Value方法只应传递请求级别的元数据（request ID、trace ID、认证信息），不应传递业务参数。业务参数应作为函数参数显式传递。
context.Background()作为根 ------在main函数、初始化代码和测试中，使用context.Background()作为根context。不要使用context.TODO()------它是一个占位符，表示你还没有决定使用什么context。
函数第一个参数传递context ------Go社区约定：func DoSomething(ctx context.Context, arg Arg) error。context始终是第一个参数，不要放在结构体中。
不要持有context------不要将context存储在结构体中长期持有。context的生命周期应该与请求一致，请求结束context就失效了。
主动调用cancel------即使context会自动超时，也应在操作完成后主动调用cancel函数，尽早释放资源（尤其是timerCtx中的定时器）。

示例1：context的基本使用

go 复制代码

package main

import (
    "context"
    "fmt"
    "time"
)

func worker(ctx context.Context, id int) {
    for {
        select {
        case <-ctx.Done():
            fmt.Printf("Worker %d: received cancel signal, exiting (reason: %v)\n",
                id, ctx.Err())
            return
        default:
            fmt.Printf("Worker %d: working...\n", id)
            time.Sleep(500 * time.Millisecond)
        }
    }
}

func main() {
    // 创建可取消的context
    ctx, cancel := context.WithCancel(context.Background())

    // 启动3个worker，共享同一个context
    go worker(ctx, 1)
    go worker(ctx, 2)
    go worker(ctx, 3)

    // 2秒后取消
    time.Sleep(2 * time.Second)
    cancel() // 所有使用此context的goroutine都会收到取消信号

    time.Sleep(100 * time.Millisecond)
    fmt.Println("Main: all workers should have exited")
}

示例2：context超时与值传递

go 复制代码

package main

import (
    "context"
    "fmt"
    "time"
)

// 模拟数据库查询
func queryDB(ctx context.Context, query string) (string, error) {
    // 从context中获取请求ID（用于链路追踪）
    reqID, _ := ctx.Value("requestID").(string)
    fmt.Printf("[reqID=%s] Querying: %s\n", reqID, query)

    // 模拟耗时查询
    select {
    case <-time.After(3 * time.Second):
        return "query result", nil
    case <-ctx.Done():
        return "", ctx.Err()
    }
}

func main() {
    // WithValue：传递请求级别的值
    ctx := context.WithValue(context.Background(), "requestID", "req-001")

    // WithTimeout：设置超时
    ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
    defer cancel()

    result, err := queryDB(ctx, "SELECT * FROM users")
    if err != nil {
        fmt.Printf("Query failed: %v\n", err) // context deadline exceeded
        return
    }
    fmt.Println("Result:", result)
}

示例3：级联取消

go 复制代码

package main

import (
    "context"
    "fmt"
    "time"
)

func subTask(ctx context.Context, name string) {
    ticker := time.NewTicker(300 * time.Millisecond)
    defer ticker.Stop()

    for {
        select {
        case <-ticker.C:
            fmt.Printf("  %s: tick\n", name)
        case <-ctx.Done():
            fmt.Printf("  %s: canceled (%v)\n", name, ctx.Err())
            return
        }
    }
}

func main() {
    // 根context
    rootCtx, rootCancel := context.WithCancel(context.Background())

    // 子context（派生自rootCtx，rootCtx取消时子context也会取消）
    childCtx, childCancel := context.WithCancel(rootCtx)
    _ = childCancel // 不需要单独取消子context

    // 孙context
    grandchildCtx, _ := context.WithTimeout(childCtx, 10*time.Second)

    go subTask(childCtx, "Child")
    go subTask(grandchildCtx, "Grandchild")

    time.Sleep(2 * time.Second)

    // 取消根context → 子context和孙context都会被级联取消
    fmt.Println("Canceling root context...")
    rootCancel()

    time.Sleep(100 * time.Millisecond)
    fmt.Println("All subtasks should have exited")
}

5.5.2 常见并发模式

示例4：扇入（Fan-In）模式

go 复制代码

package main

import (
    "fmt"
    "math/rand"
    "sync"
    "time"
)

// 扇入：多个Channel合并为一个
func fanIn(channels ...<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup

    // 为每个输入Channel启动一个goroutine
    for _, ch := range channels {
        wg.Add(1)
        go func(c <-chan int) {
            defer wg.Done()
            for val := range c {
                out <- val
            }
        }(ch)
    }

    // 所有输入Channel关闭后，关闭输出Channel
    go func() {
        wg.Wait()
        close(out)
    }()

    return out
}

func source(name string) <-chan int {
    ch := make(chan int)
    go func() {
        defer close(ch)
        for i := 0; i < 5; i++ {
            ch <- rand.Intn(100)
            time.Sleep(time.Duration(rand.Intn(300)) * time.Millisecond)
        }
    }()
    return ch
}

func main() {
    merged := fanIn(source("A"), source("B"), source("C"))
    for val := range merged {
        fmt.Println("Received:", val)
    }
    fmt.Println("All sources exhausted")
}

示例5：扇出（Fan-Out）模式

go 复制代码

package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, jobs <-chan int, results chan<- int) {
    for job := range jobs {
        fmt.Printf("Worker %d processing job %d\n", id, job)
        time.Sleep(100 * time.Millisecond) // 模拟工作
        results <- job * job
    }
}

func main() {
    const numWorkers = 3
    const numJobs = 10

    jobs := make(chan int, numJobs)
    results := make(chan int, numJobs)

    // 扇出：启动多个worker消费同一个Channel
    var wg sync.WaitGroup
    for w := 1; w <= numWorkers; w++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            worker(id, jobs, results)
        }(w)
    }

    // 发送任务
    for j := 1; j <= numJobs; j++ {
        jobs <- j
    }
    close(jobs) // 关闭jobs Channel，worker会自然退出

    // 等待所有worker完成
    go func() {
        wg.Wait()
        close(results)
    }()

    // 收集结果
    for result := range results {
        fmt.Printf("Result: %d\n", result)
    }
}

5.5.3 数据争用检测

示例6：使用go race检测器

go 复制代码

// 将此代码保存为 race_demo.go
// 运行: go run -race race_demo.go

package main

import (
    "fmt"
    "time"
)

// ❌ 此代码存在数据争用
var sharedData int

func unsafeWrite() {
    for i := 0; i < 1000; i++ {
        sharedData++ // 多个goroutine并发写入，无同步 → data race!
    }
}

func main() {
    go unsafeWrite()
    go unsafeWrite()

    time.Sleep(time.Second)
    fmt.Println("sharedData =", sharedData) // 结果不确定，可能不是2000
}

// 运行 `go run -race race_demo.go` 会输出类似：
// ==================
// WARNING: DATA RACE
// Write at 0x... by goroutine 7
//   ...
// ==================

bash 复制代码

# 使用race检测器的几种方式
go test -race ./...           # 测试时检测
go run -race main.go          # 运行时检测
go build -race -o myapp .     # 构建带检测的二进制（性能有损失，仅用于调试）

5.6 协程调度器原理：G-P-M模型

Go的调度器是其并发性能的关键，理解G-P-M模型有助于编写高效的并发程序。

5.6.0 为什么Go 1.1引入P：全局队列加锁瓶颈

在Go 1.0的GM模型中（只有G和M，没有P），所有G存放在一个全局队列中。每次M需要获取G来执行时，必须加锁访问全局队列。这导致了严重的可扩展性问题：

全局锁竞争：多个M同时争抢全局队列的锁，随着M数量增加，锁竞争急剧恶化
缓存局部性差：G可能在M0上创建，被M1获取执行，导致缓存频繁失效
线程创建风暴：当G频繁阻塞/唤醒时，运行时不断创建新M来维持并行度

Go 1.1引入了P（Processor），核心设计：

每个P拥有自己的本地队列（256个G），获取本地队列中的G无需加锁
全局队列仍然存在，但访问频率大幅降低（每61次调度才检查一次）
P的数量等于CPU核心数（GOMAXPROCS），决定了真正的并行度
M必须持有P才能执行G，P充当了G和M之间的"中间人"

💡 设计哲学：P的引入是典型的"分而治之"策略------将全局共享状态分解为P个本地私有状态，将O(M)的锁竞争降低为O(1)的无锁访问。这种"局部性优先"的设计思想在并发系统中随处可见（如Java的ThreadLocal、Linux的per-CPU变量）。

5.6.1 G-P-M三大核心组件

G（Goroutine，协程）

轻量级执行单元，包含栈、指令指针、状态等信息
默认栈大小2KB，采用连续栈（contiguous stack）技术动态扩缩
状态：_Gidle → _Grunnable → _Grunning → _Gwaiting → _Gdead
多对多映射到M（操作系统线程）

M（Machine，操作系统线程）

真正执行代码的载体，由操作系统调度
包含一个特殊的调度协程g0，负责调度逻辑（不执行用户代码）
通过TLS（Thread Local Storage）绑定自身与当前G、P
M的最大数量默认为10000（可通过runtime/debug.SetMaxThreads调整）

P（Processor，逻辑处理器）

G和M之间的中间层，提供执行上下文
与M一一绑定（M必须持有P才能执行G）
默认数量等于CPU核心数（runtime.GOMAXPROCS），决定了真正的并行度
本地队列（Local Run Queue）长度256，存储待执行的G

┌─────────────────────────────────────────────────┐
│ Global Queue │
│ [G1] [G2] [G3] [G4] [G5] ... │
└───────────┬─────────────────┬───────────────────┘
│ │
┌──────▼──────┐ ┌─────▼───────┐
│ P0 (CPU 0) │ │ P1 (CPU 1) │
│ Local Queue │ │ Local Queue │
│ [G6][G7][G8]│ │ [G9][G10] │
│ runnext=G │ │ runnext=G │
└──────┬──────┘ └──────┬──────┘
│ │
┌──────▼──────┐ ┌─────▼───────┐
│ M0 (OS线程)│ │ M1 (OS线程) │
│ g0(调度栈) │ │ g0(调度栈) │
│ curG=G6 │ │ curG=G9 │
└─────────────┘ └─────────────┘

5.6.2 调度循环

每个M在持有P时，执行一个紧凑的调度循环：

复制代码

schedule → execute → gogo → [执行用户代码] → mcall → schedule
    ↑                                                    |
    └────────────────────────────────────────────────────┘

schedule：寻找可运行的G
execute：将G绑定到M，设置状态为_Grunning
gogo：汇编实现，切换到G的栈，开始/恢复执行用户代码
用户代码执行：G运行其任务
mcall：用户代码让出CPU（主动/被动/抢占），切换回g0栈
回到schedule，继续调度

💡 调度循环的精妙之处：gogo是从g0栈切换到G栈（汇编实现，保存/恢复寄存器），mcall是从G栈切换回g0栈。这两个函数是调度器的"栈开关"------用户代码永远在G栈上执行，调度逻辑永远在g0栈上执行，两者通过gogo/mcall交替切换。这种设计保证了调度器自身的栈空间不受用户代码影响。

5.6.3 调度算法优先级

当P需要寻找可运行的G时，按以下优先级查找：

复制代码

优先级1: runnext            → 最近刚唤醒的G，最高优先级
优先级2: 本地队列(Local Queue) → 当前P的256个G
优先级3: 全局队列(Global Queue) → 每61次调度检查一次，防止饥饿
优先级4: 网络轮询(Net Poller)  → I/O就绪的G
优先级5: 窃取(Work Stealing)   → 从其他P的本地队列偷取一半的G

为什么是这个优先级？

runnext最高：刚唤醒的G（如刚从I/O等待中返回）最可能在CPU缓存中还有热度，立即执行可以最大化缓存命中率。
本地队列优先于全局队列：本地队列无锁访问，全局队列需要加锁。优先本地避免了不必要的锁竞争。
每61次检查全局队列：如果完全忽略全局队列，全局队列中的G可能饥饿。61这个数字是经验值------足够大以避免频繁加锁，足够小以防止严重饥饿。
网络轮询在窃取之前：网络就绪的G是"主动送上门"的，不需要去偷；窃取涉及跨P访问，成本更高。
窃取是最后的手段：窃取需要访问其他P的本地队列，虽然比全局队列轻量，但仍比本地操作昂贵。窃取时偷取一半而非全部，是为了保持负载均衡。

示例1：观察调度行为

go 复制代码

package main

import (
    "fmt"
    "runtime"
    "sync"
    "time"
)

func main() {
    // 查看逻辑处理器数量
    fmt.Printf("GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))
    fmt.Printf("NumCPU: %d\n", runtime.NumCPU())
    fmt.Printf("NumCgoCall: %d\n", runtime.NumCgoCall())

    // 大量goroutine演示调度
    var wg sync.WaitGroup
    const numGoroutines = 10000

    start := time.Now()
    for i := 0; i < numGoroutines; i++ {
        wg.Add(1)
        go func(id int) {
            defer wg.Done()
            // 简单计算
            sum := 0
            for j := 0; j < 100; j++ {
                sum += j
            }
            _ = sum
        }(i)
    }
    wg.Wait()

    fmt.Printf("Created and ran %d goroutines in %v\n", numGoroutines, time.Since(start))
    fmt.Printf("Current goroutines: %d\n", runtime.NumGoroutine())
}

5.6.4 调度触发机制

调度器有三种触发方式，每种对应不同的场景：

主动调度

runtime.Gosched()：当前G主动让出CPU，重新进入队列等待调度
典型场景：长时间计算的协作式让步

被动调度

Channel操作阻塞（发送/接收）
系统调用阻塞
time.Sleep
锁竞争阻塞
G进入_Gwaiting状态，M与P解绑，P寻找新的M或被其他M接管

抢占调度

Go 1.14前：基于函数序言的栈增长检查（协作式），无法抢占不含函数调用的密集循环
Go 1.14+：基于信号的异步抢占（SIGURG），可以抢占任何goroutine

💡 Go 1.14信号机制强制抢占的原理 ：运行时向目标M发送SIGURG信号。M的信号处理器检查当前G是否运行过久（超过10ms），如果是，则在信号返回时将G的PC修改为asyncPreempt函数的入口，从而在信号处理返回后，G不再继续执行用户代码，而是进入asyncPreempt，该函数调用mcall将G挂起并回到调度循环。
⚠️ 为什么选择SIGURG？ SIGURG是一个"无害"信号------大多数程序不使用它，且它不会中断阻塞的系统调用（如read/Write）。选择一个"空余"信号避免了与用户自定义信号处理的冲突。

示例2：主动让出CPU

go 复制代码

package main

import (
    "fmt"
    "runtime"
    "time"
)

func main() {
    // 演示主动调度
    done := make(chan bool)

    go func() {
        for i := 0; i < 5; i++ {
            fmt.Printf("Goroutine A: step %d\n", i)
            runtime.Gosched() // 主动让出CPU，给其他G运行机会
        }
        done <- true
    }()

    go func() {
        for i := 0; i < 5; i++ {
            fmt.Printf("Goroutine B: step %d\n", i)
            runtime.Gosched()
        }
        done <- true
    }()

    <-done
    <-done
    fmt.Println("Both goroutines completed")
}

示例3：系统调用对调度的影响

go 复制代码

package main

import (
    "fmt"
    "net"
    "runtime"
    "time"
)

func main() {
    fmt.Printf("Initial goroutines: %d\n", runtime.NumGoroutine())

    // 模拟阻塞的系统调用
    for i := 0; i < 10; i++ {
        go func(id int) {
            // 网络I/O是非阻塞的（由net poller管理）
            // 但如果设置了deadline且超时，会导致G进入waiting状态
            conn, err := net.DialTimeout("tcp", "192.0.2.1:80", 5*time.Second)
            if err != nil {
                fmt.Printf("Goroutine %d: dial failed (expected): %v\n", id, err)
                return
            }
            conn.Close()
        }(i)
    }

    time.Sleep(6 * time.Second)
    fmt.Printf("Final goroutines: %d\n", runtime.NumGoroutine())
}

示例4：Work Stealing工作窃取

go 复制代码

package main

import (
    "fmt"
    "runtime"
    "sync"
    "sync/atomic"
)

func main() {
    // 限制为2个P来观察work stealing
    runtime.GOMAXPROCS(2)

    var counter int64
    var wg sync.WaitGroup

    // 创建大量goroutine
    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            atomic.AddInt64(&counter, 1)
        }()
    }

    wg.Wait()
    fmt.Printf("All goroutines completed, counter: %d\n", atomic.LoadInt64(&counter))

    // 在实际运行中，P0和P1会通过work stealing来平衡负载
    // 如果P0的本地队列空了，它会从P1偷取一半的G来执行
}

5.6.5 调度器关键参数

go 复制代码

package main

import (
    "fmt"
    "runtime"
    "runtime/debug"
)

func main() {
    // 查看和设置调度器相关参数

    // P的数量（决定并行度）
    fmt.Printf("GOMAXPROCS: %d\n", runtime.GOMAXPROCS(0))

    // M的最大数量
    fmt.Printf("MaxThreads (default 10000): %d\n", debug.SetMaxThreads(10000))

    // 本地队列长度（编译时常量 256）
    // runtime.runqSize = 256

    // 查看当前调度信息
    var buf []byte
    buf = make([]byte, 1<<20)
    n := runtime.Stack(buf, true)
    fmt.Printf("Stack trace (%d bytes):\n%s\n", n, buf[:n])
}

深入理解go语言-第5章 并发编程——Go的灵魂

第5章 并发编程------Go的灵魂

5.1 goroutine：轻量级并发

5.1.1 并发与并行的本质区别

5.1.2 goroutine的本质

5.1.3 goroutine的创建与基本用法

5.1.4 goroutine的关键特性

5.2 Channel：通信与同步

5.2.0 Channel底层原理

5.2.1 Channel的惯用法理论

5.2.2 Channel的声明与初始化

5.2.3 Channel的核心规则

5.3 select多路复用

5.3.0 select底层实现原理

5.3.2 select的基本行为

5.3.3 select的关键特性

5.4 sync包全家桶

5.4.0 sync包各组件的设计原理

5.4.1 sync.Mutex与sync.RWMutex

5.4.2 sync.Once

5.4.3 sync.Cond

5.4.4 sync.Pool

5.4.5 sync.Map

5.4.6 atomic原子操作

5.5 并发模式与最佳实践

5.5.0 并发安全的理论基础

5.5.1 Context专节：优雅退出与级联取消

5.5.2 常见并发模式

5.5.3 数据争用检测

5.6 协程调度器原理：G-P-M模型

5.6.0 为什么Go 1.1引入P：全局队列加锁瓶颈

5.6.1 G-P-M三大核心组件

5.6.2 调度循环

5.6.3 调度算法优先级

5.6.4 调度触发机制

5.6.5 调度器关键参数

深入理解go语言-第5章并发编程——Go的灵魂

第5章并发编程------Go的灵魂