Golang 实现高性能的随机数生成方案-Golang-PHP中文网

高并发下rand.Intn()因全局锁导致QPS骤降，正确做法是每个goroutine持独立*rand.Rand实例或用sync.Pool复用；其性能瓶颈源于单实例串行争锁，即使读操作也需更新原子计数器，争用不可避免。

golang 实现高性能的随机数生成方案

高并发下直接用 rand.Intn() 会锁全局源，QPS 上不去；正确做法是每个 goroutine 持独立 *rand.Rand 实例，或用 sync.Pool 复用——不是“要不要换”，而是“不换就卡住”。

它背后是单个带互斥锁的全局 *rand.Rand 实例。所有 goroutine 都串行抢同一把锁，pprof 里一眼看到 runtime.futex 占比飙升。哪怕只是读操作（如 Intn()），内部也要更新原子计数器，争用不可避免。

结构体仅约 40 字节，分配成本极低，且彻底消除锁竞争。关键是种子必须差异化：

简单场景：用 time.Now().UnixNano() ^ int64(goroutineID)，其中 goroutineID 可粗略用 uintptr(unsafe.Pointer(&i))（注意：非标准，仅作区分）
生产推荐：启动时用 crypto/rand.Read() 生成一次 8 字节种子，缓存复用 —— 不进热路径，又避免时间精度陷阱

示例：

r := rand.New(rand.NewSource(time.Now().UnixNano() ^ int64(id)))

Pool 能减分配压力，但对象可能被 GC 回收，每次 Get() 后状态不可信。不能依赖它“自动重置”：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

错：在 Pool.New 里写 rand.New(rand.NewSource(time.Now().UnixNano())) —— 种子老化，复用越久越假
对：New 函数用预生成的加密种子构造实例；或 Get() 后立刻调 r.Seed(time.Now().UnixNano())（Go
更稳：Pool 存的是已设好种子的干净实例，New 时只做一次 crypto/rand.Read()，不碰时间

不是因为“更随机”，而是因为“不能被预测”——只要涉及 token、session ID、salt、UUID v4，math/rand 再快也不能用。

crypto/rand.Read() 在 Linux 上批读 /dev/urandom，10K goroutine 并发下实测比加锁的 math/rand 还快
别自己拼 rand.Int63() + fmt.Sprintf 造 token —— 分布不均、长度不定、不安全

生成 16 字节 token：

b := make([]byte, 16)<br>_, err := rand.Read(b)

记得检查 err

真正容易被忽略的，是“全局函数只适合单 goroutine 临时用”这个边界——一旦逻辑从 CLI 工具挪到 HTTP handler，或从单测跑进压测环境，不隔离实例，性能断崖就来了。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！

Golang 实现高性能的随机数生成方案