go并发性能瓶颈主要在共享资源争用、gc压力、系统调用阻塞和内存分配模式；应避免全局锁、goroutine泛滥、高频堆分配及阻塞式系统调用，善用atomic、rwmutex、sharded lock、worker pool、sync.pool和高效i/o。
Go 程序的并发性能瓶颈，90% 不在 goroutine 本身，而在共享资源争用、GC 压力、系统调用阻塞和内存分配模式上。
避免 sync.Mutex 在高频热路径上锁整个结构体
常见错误是给一个高频更新的计数器或缓存结构体加一把全局 sync.Mutex，导致 goroutine 大量排队等待。这不是并发，是“伪并发”。
- 改用
sync/atomic操作基础类型（如int64、uint64、指针），例如atomic.AddInt64(&counter, 1) - 对 map 类型读多写少场景，优先用
sync.RWMutex，写时用Lock()，读时用RLock() - 若必须保护复杂结构，按字段或按 key 分片加锁（sharded lock），比如把大 map 拆成 32 个子 map + 32 把
sync.Mutex，哈希 key 后选择对应锁
控制 goroutine 泄漏与泛滥：别无脑用 go f()
每启动一个 goroutine 至少占用 2KB 栈空间（可增长），上万 goroutine 不仅吃内存，还会显著拖慢调度器和 GC 扫描速度。
- 对 I/O 密集任务（如 HTTP 请求、DB 查询），用带缓冲的 worker pool 控制并发数，例如
semaphore.NewWeighted(10)或自建 channel 控制池大小 - 所有带超时/取消逻辑的 goroutine 必须监听
ctx.Done()，并在退出前清理资源（如关闭 channel、释放 buffer） - 避免在循环内无条件启 goroutine：
for range items { go process(item) }→ 改为批量投递或使用 pool
减少堆分配：善用 sync.Pool 和栈逃逸分析
频繁 new 结构体或切片会加剧 GC 压力，尤其在 QPS 上万时，GC STW 可能从毫秒级升至数十毫秒。
立即学习“go语言免费学习笔记（深入）”；
- 对生命周期短、复用率高的对象（如 JSON 解析用的
*bytes.Buffer、自定义 request struct），注册到sync.Pool，用pool.Get()/pool.Put() - 用
go build -gcflags="-m -m"检查变量是否逃逸到堆；能放栈上的尽量放栈上（如小数组[64]byte优于[]byte） - 避免在 hot path 中拼接字符串（
s += "x"）、用fmt.Sprintf，改用strings.Builder或预分配[]byte
系统调用优化：避开阻塞式 I/O 和低效 syscall 封装
Go runtime 对系统调用做了封装，但某些操作（如 os.Open、time.Sleep）仍可能触发 M 级别阻塞，挤占 P 资源。
- 文件读写优先用
io.ReadFull/io.CopyBuffer配合复用的[]byte缓冲区，避免每次调用都 malloc - 定时任务不用
time.Sleep循环，改用time.Ticker（复用 timer）或runtime.SetFinalizer配合 channel 控制 - 网络服务中，确认是否启用
net/http.ServeMux的连接复用（HTTP/1.1 默认 keep-alive），并设置Server.ReadTimeout/WriteTimeout防止连接长期空转
真正卡住高并发 Go 程序的，往往不是 goroutine 数量，而是你没意识到某个 log.Printf 调用背后锁了全局 os.Stderr，或者某个 json.Marshal 正在反复反射遍历结构体字段——这些细节比“要不要用 channel”更决定性能上限。
