17370845950

Go并发编程以goroutine+channel重构并发思维：goroutine轻量（2KB栈、纳秒级创建）、由GMP调度；channel用于同步与通信，非共享内存替代，无缓冲需配对阻塞，有缓冲仍保序原子性。

Go 并发编程不是“多线程的另一种写法”，而是用 goroutine + channel 重构了并发的思考方式：你不再操心锁、状态同步、线程生命周期，而是设计数据如何流动。

goroutine 不是线程，别拿 pthread 的经验去猜它

启动一个 goroutine 只需 go f()，但它和操作系统线程（pthread）有本质区别：

• 初始栈仅 2KB，可动态伸缩；系统线程栈通常固定 1MB~8MB
• 创建/销毁不触发系统调用，开销在纳秒级；pthread_create 是微秒级甚至更高
• 调度由 Go 运行时（GMP 模型）接管，不是内核；一个 OS 线程（M）可跑成百上千个 G
• 阻塞系统调用（如 read、accept）不会卡死整个线程，运行时会自动把其他 G 切到别的 M 上

常见错误：在循环里无节制启 go handle(req) 却不控制并发数 → 内存暴涨或调度器过载。应配合 semaphore 或带缓冲的 channel 限流。

channel 是通信契约，不是共享内存的替代品

channel 的核心作用是同步 +

数据传递，不是“线程安全的队列”。它的行为由类型和缓冲区决定：

• make(chan int)：无缓冲，send 和 recv 必须配对阻塞（即“握手”），天然实现同步
• make(chan int, 10)：有缓冲，发送不阻塞直到满；接收不阻塞直到空；但**仍保证顺序与原子性**
• 向已关闭的 channel 发送 panic；从已关闭的 channel 接收返回零值 + false（可用 v, ok := 判断）
• 永远不要在多个 goroutine 中同时关闭同一个 channel —— 这是典型的竞态源，应由发送方单侧关闭

典型误用：for range ch 在接收端，但发送端未关闭 channel → 永远阻塞。务必确保 sender 明确调用 close(ch)，或用 context 控制生命周期。

select 不是 switch，它是 goroutine 的“等待多路复用器”

select 用来同时监听多个 channel 操作，但它不是轮询，也不保证公平性：

• 所有 case 的 channel 操作必须是**非阻塞准备就绪**状态，否则该 case 被跳过
• 多个 case 同时就绪时，Go 运行时**随机选择一个**（不是 FIFO），不可依赖顺序
• 加 default 可实现非阻塞尝试；不加 default 且所有 case 阻塞，则当前 goroutine 挂起
• 不能在 select 里直接调用函数（如 case ch ），因为 compute() 会在 select 判定前执行，破坏语义

实用技巧：用 select + time.After 实现超时，但注意 time.After 创建的是单次定时器，高频场景建议复用 time.NewTimer 并 Reset。

context 不是“传参工具”，它是 goroutine 生命周期的总控开关

context.Context 的唯一正统用途是**取消传播与截止时间控制**，不是用来塞业务参数（那是 anti-pattern）：

• context.WithCancel：手动触发取消，适合用户中断、任务终止等显式信号
• context.WithTimeout / context.WithDeadline：自动在超时后关闭 Done() channel，下游 goroutine 应监听并退出
• context.WithValue 仅限传递**请求范围的、不可变的元数据**（如 request-id, user-id），绝不传结构体指针或可变对象
• 所有 I/O 操作（http.Client.Do、database/sql.QueryContext）都支持 context，不传等于放弃超时/取消能力

最容易被忽略的一点：goroutine 启动时若没把 ctx 传进去，或者传了却没在关键路径上检查 ctx.Err()，那这个 goroutine 就成了“幽灵协程”——无法被优雅终止，最终导致泄露。