go 默认的全局 rand 包因内部互斥锁导致高并发下成为性能瓶颈，限制了多核利用率；解决方法是为每个 goroutine 独立初始化 *rand.rand 实例，并使用唯一种子（如基于时间+goroutine id 的组合），从而消除争用、实现接近 100% 的 cpu 利用率。
go 默认的全局 rand 包因内部互斥锁导致高并发下成为性能瓶颈，限制了多核利用率；解决方法是为每个 goroutine 独立初始化 *rand.rand 实例，并使用唯一种子（如基于时间+goroutine id 的组合），从而消除争用、实现接近 100% 的 cpu 利用率。
在 Go 中，math/rand 包的全局函数（如 rand.Intn()）底层共享一个全局 *rand.Rand 实例，其 Intn() 方法被 sync.Mutex 保护（见 Go 源码 L233）。这意味着——无论你启动多少 goroutine，所有对 rand.Intn() 的调用都必须串行排队等待同一把锁，形成严重的并发瓶颈。这正是你观察到“240 个 goroutine 仅达 77% CPU 利用率”的根本原因：CPU 大量时间花在锁等待上，而非数学计算。
✅ 正确做法：*为每个 goroutine 分配独立的、已正确播种的 `rand.Rand` 实例**，彻底绕过全局锁。关键在于确保种子唯一性，避免多个 goroutine 初始化出相同随机序列（虽不影响正确性，但削弱并行价值）。
以下是优化后的完整示例：
package main
import (
"math/rand"
"runtime"
"time"
)
// NewLockedRand 创建线程安全的独立 Rand 实例（无需额外锁）
func NewLockedRand() *rand.Rand {
// 使用纳秒级时间 + 当前 goroutine ID（通过 runtime.GoroutineProfile 近似获取）
// 更简洁可靠的做法：用 time.Now().UnixNano() + 随机偏移（或直接用 sync/atomic 计数器）
seed := time.Now().UnixNano() ^ int64(runtime.GoID()) // Go 1.21+ 支持 runtime.GoID()
// 若使用 Go < 1.21，可改用 atomic.AddInt64(&counter, 1) 作为唯一 ID
return rand.New(rand.NewSource(seed))
}
func DoSomeMath() int {
r := NewLockedRand() // 每次调用创建专属 Rand
k := 0
for i := 0; i < 1000; i++ {
j := i*i + 2
k += i * r.Intn(j) // 调用实例方法，无锁
}
return k
}
// 或更推荐：在 goroutine 启动时一次性创建 Rand（避免重复构造开销）
func Worker(id int) int {
src := rand.NewSource(time.Now().UnixNano() ^ int64(id))
r := rand.New(src)
k := 0
for i := 0; i < 1000; i++ {
j := i*i + 2
k += i * r.Intn(j)
}
return k
}⚠️ 注意事项：
- 种子唯一性至关重要：避免使用 time.Now().UnixNano() 单独作为种子（高并发下易重复），务必混入 goroutine 标识（如 id、runtime.GoID() 或原子计数器）。
- *不要复用 `rand.Rand跨 goroutine**：即使不加锁，*rand.Rand的Intn()` 方法也不是并发安全的（其内部状态更新非原子）。
- 性能验证：启用 GOMAXPROCS(12) 并启动 ≥12 个 goroutine 后，top 或 htop 应显示所有 12 个核心持续稳定在 95–100% 利用率。
- 替代方案：若需密码学安全随机数，应使用 crypto/rand，但其本身 I/O 密集，天然无法满载 CPU；本场景属确定性伪随机，math/rand + 每 goroutine 独立实例是最优解。
总结：Go 的并发优势绝不能被全局锁扼杀。识别瓶颈（pprof CPU profile 可快速定位 rand.(*rng).Int63 的锁等待）、隔离状态、合理播种——三步即可让数百 goroutine 真正并行飞驰，榨干每一块 CPU 核心。
