Go用Goroutine+M:N调度模型替代传统多线程，因轻量栈、用户态调度、自动挂起I/O阻塞，更适I/O密集型任务；性能瓶颈常在I/O使用方式而非并发数。
Go语言中没有传统意义上的“多线程模型”用于I/O密集型任务——它用的是Goroutine + 系统线程复用的并发模型，底层由Go运行时调度器（M:N调度）自动管理。这不是Java或Python那种“一个线程对应一个OS线程”的多线程，因此不能直接套用“开10个线程就快10倍”的直觉。
为什么Goroutine比OS线程更适合I/O密集型任务
磁盘读写、网络请求、数据库查询等I/O操作本质是“等待”，不是计算。当一个Goroutine执行conn.Read()或http.Get()时，Go调度器会自动将其挂起，并立即切换到另一个就绪的Goroutine继续运行，无需操作系统介入上下文切换。整个过程不阻塞M（系统线程），一个M可承载成千上万个Goroutine。
- 启动开销极小：一个Goroutine初始栈仅2KB，可动态伸缩；OS线程通常需1~8MB栈空间
- 调度成本低：Go调度器在用户态完成，避免陷入内核；而频繁创建/销毁OS线程会触发大量系统调用和内存分配
- 天然规避“线程爆炸”：比如处理10万并发连接，开10万个Goroutine很轻松；但10万个OS线程在大多数系统上会直接OOM或卡死
真实瓶颈往往不在并发模型，而在I/O使用方式
即便用了Goroutine，并发性能也可能很差——常见原因不是“不够多”，而是“用错了”。例如：
- 没加
bufio缓冲，每次fmt.Fscanf或fmt.Fprintln都触发一次系统调用，吞吐量断崖式下跌 - HTTP客户端未配置连接池：
http.DefaultTransport默认只允许2个并发连接，再多Goroutine也得排队等 - 反复
make([]byte, ...)分配小buffer，引发GC压力，间接拖慢I/O响应 - 误用
select + time.After轮询模拟非阻塞，白白占用CPU且无法释放Goroutine
什么时候该增加系统线程数（GOMAXPROCS）？
runtime.GOMAXPROCS控制的是P（逻辑处理器）数量，即能并行执行Goroutine的OS线程上限。对纯I/O密集型任务，通常不需要调大，默认值（等于CPU核心数）完全够用。因为I/O等待期间Goroutine自动让出P，其他Goroutine立刻补上。
立即学习“go语言免费学习笔记（深入）”；
- 只有当I/O操作中混有较重的同步计算（如解密、压缩、JSON解析）时，才可能因P被占满导致Goroutine饥饿，此时可适度提高GOMAXPROCS
- 盲目设为CPU数的2倍或更高，反而增加调度竞争和缓存失效，实测常无收益甚至变慢
- 更关键的是调优I/O本身：缓冲大小、连接复用、对象复用，而非堆线程
对比其他语言：Go不靠“多线程”赢，靠“少阻塞+少系统调用+少分配”赢
Python受GIL限制，多线程无法提升CPU密集型性能，对I/O密集型虽有用（因I/O会释放GIL），但线程创建成本高、数量受限；Java线程轻量级不如Goroutine，且需手动管理线程池与生命周期。Go的优势不是“更多线程”，而是：
- 写法简单：
go handleRequest(conn)一行启动并发，无需显式线程池或回调嵌套 - 资源友好：10K并发连接 ≈ 10K Goroutine + 几个OS线程，内存占用可控
- 组合高效：配合
errgroup、sync.Pool、bufio等工具，一条流水线就能压榨出硬件I/O带宽
