goroutine数量暴增会因调度开销、P竞争和系统调用阻塞降低吞吐量；应限流、复用goroutine、用带缓冲channel和worker pool控制并发，避免隐式阻塞。
为什么 goroutine 数量暴增反而降低吞吐量
Go 的 goroutine 虽轻量，但调度器（GMP 模型）在高并发下会因频繁的抢占、G 切换、P 竞争和系统调用阻塞而产生显著开销。当 runtime.NumGoroutine() 达到数万且多数处于 runnable 或 syscall 状态时，schedtrace 日志常出现大量 “preempted” 和 “handoff” 记录，实际 CPU 利用率却不足 60%。
- 避免无节制
go f()：尤其在循环中启动 goroutine 处理网络请求或数据库查询时，必须加限流 - 优先复用已有 goroutine：用
sync.Pool缓存临时对象，减少 GC 压力；用chan struct{}或semaphore控制并发数，例如make(chan struct{}, 100)限制最多 100 个活跃任务 - 警惕隐式阻塞：如未设超时的
http.DefaultClient.Do()、未配缓冲区的无界 channel 写入，都会导致 G 长时间阻塞并拖慢整体调度
如何正确使用 worker pool 模式压测真实吞吐
单纯增加 goroutine 不等于提升吞吐；关键在于让 P 充分利用、减少上下文切换、匹配 I/O 和 CPU 资源比例。worker pool 是最可控的落地方式。
- worker 数量通常设为
runtime.GOMAXPROCS(0)的 1–4 倍，而非机器核数的 10 倍；若任务含大量 HTTP 调用，可适当放大（如 2×GOMAXPROCS），但需配合连接池与超时 - 任务 channel 必须带缓冲：
jobs := make(chan Task, 1000)，否则生产者易被阻塞，吞吐卡在 sender 端 - 每个 worker 应主动处理 panic 并 recover，否则一个 panic 会导致整个 pool 崩溃；同时建议在 job 结构体中嵌入
context.Context，支持统一取消
for job := range jobs {
select {
case <-job.ctx.Done():
continue
default:
// 执行任务
}
}
何时该用 runtime.LockOSThread() 提升特定任务性能
绝大多数场景不该用，但它在极少数绑定 OS 线程能规避代价的场景下有效——比如集成 C 代码调用 TLS 全局变量、或需要固定 CPU core 运行的实时性敏感任务（如高频 tick 处理）。
- 仅在初始化后立即调用，且必须配对
runtime.UnlockOSThread()；若 goroutine 退出前未解锁，该 M 将永久绑定，造成 P 饥饿 - 无法跨 goroutine 复用线程绑定；每次
go func() { runtime.LockOSThread(); ... }()都会新建 M，不是“复用线程”，而是“独占线程” - 开启
GODEBUG=schedtrace=1000可观察 M 是否持续处于lockedm状态，确认是否泄漏
channel 选型与缓冲区大小怎么影响吞吐
无缓冲 channel 是同步点，有缓冲才是异步解耦的关键。但缓冲区不是越大越好——过大会吃内存、延迟任务响应、掩盖背压问题。
立即学习“go语言免费学习笔记（深入）”；
- 生产者快 + 消费者慢 → 用带缓冲 channel，大小 ≈ 单位时间最大突发量 × 平均处理耗时（单位：任务数），例如每秒突增 500 请求、平均处理 200ms，则缓冲 100 合理
- 避免
chan interface{}：类型擦除带来分配和反射开销；定义具体结构体 channel，如chan *UserEvent - 关闭 channel 前确保所有 sender 已退出，否则引发 panic；更安全的做法是用
sync.WaitGroup+close，或直接用context.WithCancel驱动退出
真正卡吞吐的往往不是 goroutine 数，而是 channel 阻塞位置、GC STW 时间、以及 netpoller 在高连接数下的就绪事件批量处理效率——这些需要 go tool trace 定点分析，不能只靠调参数。
