math/rand包级函数在并发下因共享全局锁导致严重性能瓶颈；go 1.22起math/rand/v2彻底移除全局状态，强制显式创建独立*rand.rand实例，采用pcg算法与lemire优化，实现无锁高并发随机数生成。
math/rand 包级函数在并发下会锁争用
直接调用 rand.Intn(100) 等全局函数时，Go 1.15+ 虽已加锁保证线程安全，但所有 goroutine 共享同一把互斥锁。高并发场景下（比如每秒万级随机数请求），rand.Float64() 会变成串行瓶颈——实测吞吐可能比单 goroutine 还低，go test -race 也会报告 Read at ... by goroutine X 类似警告。
- 锁竞争不是理论问题：压测中 goroutine 等待锁的平均延迟常超 10µs，远高于生成随机数本身开销
- 即使不触发 data race 检测，性能衰减也真实存在；Go 1.22 前无真正无锁方案
- 全局状态还带来隐式耦合：某个库调用
rand.Seed()会重置整个程序的随机序列
math/rand/v2 彻底移除了全局状态
Go 1.22 引入的 math/rand/v2 不再提供包级函数，强制你显式创建 *rand.Rand 实例。这意味着：
-
rand.New()返回的每个实例完全独立，无共享字段、无隐式锁 - 初始化必须传入
rand.Source，不再有rand.Seed()这种污染全局的入口 - 旧代码里
rand.Intn(2)必须改为r.IntN(2)（注意函数名大小写变化）
示例迁移：
// Go 1.21 及之前（有锁、有全局状态） rand.Seed(time.Now().UnixNano()) coin := rand.Intn(2) // Go 1.22+ math/rand/v2（无锁、无全局状态） src := rand.NewPCG(uint64(time.Now().UnixNano()), 0) r := rand.New(src) coin := r.IntN(2)
为什么 v2 默认用 PCG 而非旧 LFSR
math/rand/v2 的 rand.NewPCG() 使用 PCG（Permuted Congruential Generator）算法，相比旧版 math/rand 的 LFSR：
- 周期更长（264 vs 263），对长时间运行的服务更稳妥
- 统计质量更好：通过 BigCrush 测试集，而旧 LFSR 在部分位模式上存在可检测偏差
- PCG 初始化更快，且种子空间更大（两个 uint64），降低多实例种子碰撞概率
注意：rand.NewPCG() 第二个参数是增量（increment），不要传 0 以外的固定值——除非你明确需要可复现的子序列。
v2 下的并发实践：别共享，也别乱造种子
最简健壮模式是每个 goroutine 拥有自己的 *rand.Rand，但种子不能全用 time.Now().UnixNano() ——纳秒级时间戳在短生命周期 goroutine 中极易重复。
- ✅ 推荐：用
rand.NewPCG(rand.NewSource(time.Now().UnixNano()).Uint64(), 0)生成唯一种子 - ✅ 测试时：传入固定
uint64种子，确保行为可重现 - ❌ 避免：用原子计数器拼接时间戳（如
atomic.AddUint64(&counter, 1) + time.Now().UnixNano()），PCG 本身已处理种子扩散 - ❌ 避免：为每个请求 new 一个
*rand.Rand实例却不复用——内存分配开销会盖过锁收益
复杂服务建议在启动时预建 sync.Pool[*rand.Rand]，Get 时重置种子或调用 r.Reset()（v2 提供）。
