c# 在多线程代码中如何正确使用 Random 和 Guid

来源：这里教程网时间：2026-02-21 17:40:22 作者：

Random 在多线程中为什么不能直接共享实例

因为

Random

的内部状态是可变的，多个线程同时调用

Next()

、

NextDouble()

等方法会竞争修改同一个

uint

种子和内部缓冲，导致返回重复值、0 值，甚至抛出

InvalidOperationException

（尤其在 .NET Core 3.0+ 中对状态冲突做了更严格的检测）。

常见错误写法：

private static readonly Random _sharedRnd = new Random();
// 多个线程同时调用 _sharedRnd.Next() → 不安全

正确做法是每个线程独占一个

Random

实例，但注意：不能用相同种子初始化（比如都用

new Random()

），否则高并发下秒级时间戳相同，导致大量线程拿到一模一样的随机序列。

推荐用
ThreadLocal<random></random>
：线程首次访问时用
Guid.NewGuid().GetHashCode()
或
Environment.TickCount64
生成唯一种子 .NET 6+ 可直接用
Random.Shared
（它是线程安全的静态实例，底层已加锁并优化了争用路径）若需高性能且不介意轻微偏差，可用
System.Security.Cryptography.RandomNumberGenerator
（密码学安全，但开销大）

Guid.NewGuid() 是线程安全的，但有隐含陷阱

Guid.NewGuid()

本身是线程安全的，.NET 内部已处理并发调用，无需额外同步。但它在高吞吐场景下可能暴露两个实际问题：

Windows 上依赖
CoCreateGuid
，底层用系统熵池 + 时间戳 + 线程ID等混合，极低概率出现重复（理论碰撞率约 1e-18，但若每秒生成百万级 Guid，持续数年仍需警惕）默认生成的是
GuidVersion.Random
（v4），但部分旧环境（如某些 SQL Server 集群配置）对 Guid 排序性能差，大量插入会导致索引碎片加剧若用于分布式 ID，
Guid.NewGuid()
不保证单调递增，无法替代雪花算法类有序 ID

替代方案参考：

// .NET 7+ 推荐：创建时间/节点/序列混合的有序 Guid
Guid.CreateSequential(); // 注意：仅限 .NET 7+，且需配合数据库支持 sequential Guid 存储

多线程下 Random 和 Guid 混用的典型误用

有人试图用

Guid.NewGuid().GetHashCode()

当作

Random

种子来“绕过”线程安全问题，这是危险的：

GetHashCode()
在 x64 和 x86 下结果不同，且不保证跨进程/重启一致
Guid
的哈希码只取前 4 字节，信息严重丢失，导致实际种子空间极小（约 2³²），容易撞 seed 连续调用
Guid.NewGuid().GetHashCode()
在单线程内也可能返回相同哈希值（哈希碰撞）

正确混用方式只有一种场景：需要「每个线程一个确定性随机源」且允许复现 —— 此时应显式传入稳定种子，例如从配置读取或用线程名哈希（用

HashCode.Combine

而非

GetHashCode

）：

var seed = HashCode.Combine(Thread.CurrentThread.ManagedThreadId, Environment.ProcessId);
var rnd = new Random(seed);

实际项目中该选哪个

没有银弹。选择取决于你的约束：

只是生成测试数据、日志 ID？→ 直接用
Guid.NewGuid()
，简单可靠需要随机整数/浮点数，且吞吐不高（Random.Shared.Next()（.NET 6+）或
ThreadLocal<random></random>
（旧版本）密钥、token、盐值？→ 必须用
RandomNumberGenerator.GetInt32()
或
GetBytes()
，禁用
Random
要分布式唯一 + 时间局部性 + 数据库友好？→ 放弃
Guid
，改用
DateTime.UtcNow.Ticks + Interlocked.Increment(ref seq)
或成熟库如
Twitter.Snowflake

最常被忽略的一点：别在静态构造函数或类型初始化器里预热