本文深入分析 go 中计算阶乘时并发与顺序执行的性能差异，揭示“并发不等于并行”的核心误区，并通过代码实证说明何时以及如何正确使用 goroutine 实现真正的并行加速。
本文深入分析 go 中计算阶乘时并发与顺序执行的性能差异，揭示“并发不等于并行”的核心误区，并通过代码实证说明何时以及如何正确使用 goroutine 实现真正的并行加速。
在 Go 语言实践中，初学者常误以为“只要用 goroutine 就能提速”。但您提供的两个阶乘实现——一个使用 channel + goroutine 并发处理百万次 10!，另一个纯顺序循环计算——实测结果却显示：顺序版本显著更快。这并非 Go 性能缺陷，而是对并发（concurrency）与并行（parallelism）本质的典型误解。
? 根本问题：并发 ≠ 并行，且存在显著开销
您的并发版本确实启动了约 100 万个 goroutine（对应 gen(1000000) 的每个 10），但：
- 每个 goroutine 独立重复执行完全相同的计算：calcFact(10)；
- 没有任务分解（task decomposition），不存在工作分片；
- 所有 goroutine 竞争同一 CPU 资源（即使多核，调度与上下文切换开销巨大）；
- 频繁的 channel 发送/接收、sync.WaitGroup 同步、goroutine 创建/销毁带来可观的运行时开销。
简言之：您让系统“并发地做一模一样的事”，而非“并行地分工协作”。这就像派 100 个工人每人抄写同一段话 100 遍，远不如 1 个工人专注抄写 100 遍高效。
✅ 正确并行：分解问题，协同求解
要真正利用多核优势，必须将单一计算任务拆分为可独立执行的子任务。以 10! = 1 × 2 × 3 × … × 10 为例，可将其乘积分段并行计算：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
func factParallel(n int) int {
if n <= 1 {
return 1
}
ch := make(chan int, 2) // buffered channel avoids blocking
mid := n / 2
// Launch two goroutines for [1, mid] and [mid+1, n]
go func() { ch <- productRange(1, mid) }()
go func() { ch <- productRange(mid+1, n) }()
// Multiply partial results
a, b := <-ch, <-ch
return a * b
}
func productRange(start, end int) int {
result := 1
for i := start; i <= end; i++ {
result *= i
}
return result
}该方案仅启动 2 个 goroutine，各自计算互不重叠的整数区间乘积，最后合并结果。它实现了真正的并行：CPU 核心可同时处理不同区间，无冗余计算，同步开销极小。
? 提示：实际应用中，productRange 可进一步递归分治（如四路并行），但需权衡分片粒度与调度成本。对于小规模 n（如 n ≤ 20），顺序计算通常仍更优——并行收益需覆盖其固有开销。
⚠️ 关键注意事项
- 不要为微小计算滥用 goroutine：calcFact(10) 是 O(n) 递归，耗时纳秒级，goroutine 启动成本（约数十纳秒）远超其本身；
- 避免过度并发：100 万 goroutine 会占用大量内存（每个默认栈 2KB），并触发频繁调度，严重拖慢整体性能；
- 善用缓冲 channel 与合理同步：无缓冲 channel 易造成 goroutine 阻塞等待，sync.WaitGroup 使用需确保 Add 在 go 前调用；
- 基准测试需严谨：使用 go test -bench 替代 time.Now() 手动计时，排除 GC、调度抖动等干扰。
? 总结
| 维度 | 顺序版本 | 原并发版本 | 正确并行版本 |
|---|---|---|---|
| 核心思想 | 单线程串行执行 | 大量 goroutine 重复执行相同任务 | 任务分片，多核协同计算 |
| 性能表现 | ✅ 快（无调度/同步开销） | ❌ 慢（高开销 + 无实质并行） | ✅ 快（真正利用多核） |
| 适用场景 | 小规模、低延迟要求任务 | I/O 密集型（如 HTTP 请求、文件读取） | 计算密集型、可分割大任务 |
记住 Go 的箴言：“Don’t communicate by sharing memory; share memory by communicating.” —— 但更根本的是：先问“能否并行”，再问“如何并发”。优化始于对问题本质的洞察，而非对语法特性的盲目套用。
