Golang中的并发与同步操作_Golang并发编程与同步原语的使用

goroutine泄漏表现为内存持续增长、NumGoroutine()值只增不减；常见于未关闭channel接收、select阻塞、未调用cancel()；可用pprof查看堆栈，-gcflags=”-m”分析逃逸，defer中检查ctx.Err()清理。

goroutine 泄漏的典型表现与快速定位方法

goroutine 泄漏不是报错，而是程序内存持续增长、runtime.NumGoroutine() 返回值只增不减。常见于未关闭的 channel 接收、阻塞在 select 等待永远不发生的 case、或忘记调用 cancel() 导致 context 无法退出。

• 用 pprof 查看 goroutine 堆栈：curl http://localhost:6060/debug/pprof/goroutine?debug=2
• 启动时加 -gcflags="-m" 观察逃逸分析，确认是否意外捕获了大对象导致 goroutine 持有引用
• 对所有带超时/取消逻辑的 goroutine，强制在 defer 中检查 ctx.Err() == context.Canceled 并做清理

sync.Mutex 和 sync.RWMutex 的真实适用边界

sync.Mutex 不是万能锁，也不是性能瓶颈本身；它的代价在于竞争时的调度开销和缓存行争用。读多写少场景下，sync.RWMutex 只有在真正存在并发读（且读操作耗时明显）时才值得引入——否则它比 sync.Mutex 更重，因为内部维护了额外的状态字段和 goroutine 队列。

• 若读操作只是简单取一个 int 或指针，直接用 atomic.LoadInt64 比任何 mutex 都快
• RWMutex 的写锁会阻塞新读锁获取，但已持有的读锁不会被中断；这意味着写操作可能长时间等待，尤其当读 goroutine 频繁创建时
• 不要嵌套使用 RWMutex：先 RUnlock() 再 Lock()，否则死锁

channel 关闭后继续发送 panic 的规避策略

向已关闭的 channel 发送数据会触发 panic: send on closed channel，但接收是安全的（返回零值 + false）。问题常出现在多个 goroutine 共享同一 channel 且关闭时机不明确时。

• 遵循“谁创建，谁关闭”原则；避免跨 goroutine 传递关闭责任
• 用 select + default 避免盲发：

  select { case ch <- v:>

• 若必须由接收方决定关闭，改用 sync.Once 包裹 close(ch)，并配合 sync.WaitGroup 确保所有发送者退出后再关闭

context.WithTimeout 在 HTTP client 与数据库查询中的误用点

context.WithTimeout 创建的子 context，其超时是相对于调用时刻的绝对截止时间。在长连接池（如 http.Client 或 database/sql.DB）中，它不能自动中断底层 socket 读写——仅影响上层函数是否提前返回错误。

立即学习“go语言免费学习笔记（深入）”；

• http.Client.Timeout 是连接+请求+响应全过程的总时限；而 ctx 传给 Do() 只控制该次调用是否被取消，不终止正在进行的 TLS 握手或 TCP 重传
• postgresql 驱动（lib/pq）支持 context，但 mysql 驱动（go-sql-driver/mysql）直到 v1.7 才完整支持 cancel；旧版本中 ctx 超时只会中断 query 构建阶段，实际 SQL 仍可能在服务端执行
• 避免在循环中反复调用 WithTimeout 创建新 context，应复用父 context 并用 WithDeadline 精确控制每个操作的截止点

真正难的不是记住这些原语怎么写，而是判断某个操作到底该用 channel 还是 mutex，该用 context.WithCancel 还是直接设固定超时，以及——在压测时发现 goroutine 数翻倍，你得立刻想到去查 /debug/pprof/goroutine 而不是先改代码。