搞了这么多年技术回头一看“随机数”这仨字几乎是所有程序里最不起眼却最容易翻车的东西。写抽奖活动要用它做AB实验分桶要用它连单元测试里造假数据也离不开它。可真正问一句“随机数到底是怎么来的”能讲清楚的人真不多。很多人以为Math.random()和random.randint是同一个东西还有人在生产环境用时间戳当种子生成用户Token出了安全问题才知道随机数也有真假之分。这篇就把随机数的原理、算法、代码实现、业务场景里的坑一次讲透适合所有写过、正在写或者即将写随机数逻辑的开发者参考。我最早接触随机数是在游戏服写暴击判定当时老板说“概率调高一点就行”结果上线后玩家反馈“为什么连续十次不出暴击”我一看代码用的是srand(time(NULL))配合rand() % 100那一刻我就意识到随机数这件事看起来是几行代码实际上藏着大量值得深挖的细节。这篇文章从底层原理讲到业务实战最后附上我这些年踩过的坑希望能帮你少走弯路。1. 随机数的本质伪随机和真随机到底差在哪1.1 你写的随机数其实是一串“看起来随机”的数列绝大多数编程语言里你调用的随机函数都是伪随机数生成器PRNGPseudo Random Number Generator。它不是真的随机而是通过一个确定的数学公式从一个初始值种子开始不断迭代生成一个长数列。只要种子相同生成的数列就完全一致。这就是为什么很多游戏支持“种子地图”——同一个种子同样的地形重播时一模一样。那为什么我们感觉它很随机因为好的PRNG生成出来的数列能通过大部分统计学随机性测试比如数字分布均匀、序列之间没有明显相关性、周期足够长。换句话说它是在“模拟随机”而不是“制造随机”。以最经典的线性同余生成器LCG为例核心就一行公式X(n1) (a * X(n) c) mod m用一个小例子跑跑看假设a5, c1, m16, 种子1生成的序列是1, 6, 15, 12, 13, 2, 11, 8, 9, 14, 7, 4, 5, 10, 3, 1……到第16个数回到起点周期就是16。这个序列在统计意义上并不算优质但足够说明一个问题伪随机数的一切行为都是可预测的只要你知道算法和当前状态。而真随机数TRNG则是从物理世界的噪声中提取随机性比如CPU的热噪声、电子元件的抖动、甚至大气噪声这些过程本质上不可预测每次生成都是独立事件。1.2 为什么大多数场景用伪随机就足够看到这里你可能会问既然真随机更“正宗”为什么大家都在用伪随机答案很简单真随机太慢、太贵了。硬件真随机数生成器需要专门芯片或者至少依赖系统的熵池比如/dev/urandom每秒能产出的随机数数量有限而且不适合高频调用。而PRNG是纯数学计算一毫秒能跑几百上千万次性能差距悬殊。所以工程上的通用做法是“分层配合”系统层用硬件熵源做种子应用层用PRNG快速生成大量随机数。比如你在Java里用SecureRandom它内部先用操作系统的真随机源种下种子再基于种子做伪随机扩展兼顾安全性和性能。从这个角度看选PRNG还是TRNG核心判断标准只有一个这个随机数能不能被预测如果被预测了后果严不严重游戏里刷怪掉落、内容推荐里的随机排序被预测了无非是损失一点体验PRNG完全够用。但抽奖发红包、生成重置密码的Token、产生加密密钥一旦被预测就是安全事故这时候就必须上密码学安全的随机源。2. 亲手写一个随机数生成器从LCG到梅森旋转2.1 线性同余生成器的实现与致命弱点光说不练假把式先手写一个LCG看看真实面貌。我用Python实现一个class LCG: def __init__(self, seed): self.state seed self.a 1103515245 self.c 12345 self.m 2**31 def next(self): self.state (self.a * self.state self.c) % self.m return self.state def next_float(self): return self.next() / self.m这是很多C标准库早年使用的参数组合ANSI C。测试一下均匀性生成100万个数看分布lcg LCG(42) counts [0] * 10 for _ in range(1_000_000): bucket int(lcg.next_float() * 10) counts[bucket] 1 print(counts)我实测的结果大致在[99800, 100100, 99971, ...]附近看着还行分布确实比较均匀。但LCG有几个出了名的毛病低位周期短取state % 2^k时低k位的周期最多是2^k。比如x % 2的结果会严格在0、1、0、1交替根本不像随机的。序列相关性多维空间中点会落在超平面上这是LCG的数学结构导致的固有缺陷。状态可预测攻击者只要拿到连续两个输出反推参数和状态并不难。当年glibc早期版本的random()、以及很多旧平台的rand()都有类似问题。所以在真实项目里不要自己实现LCG去做任何跟“质量”相关的事。用它来跑个作业演示、生成散点图这种低频场景还凑合生产环境请直接选择成熟的库。2.2 梅森旋转算法为什么统治了十多年为了摆脱LCG的质量瓶颈1997年松本真和西村拓士提出了梅森旋转算法Mersenne TwisterMT19937。它用一段624个32位整数的状态数组通过一系列位运算生成随机数周期高达2^19937 - 1一度是“质量好”的代名词。Python 2.3到3.x的random模块底层用的就是它很多统计软件也默认用MT19937。MT19937的核心优势在于周期极长、分布均匀、生成速度快。它对所有基于1~623维的分布测试都能通过因此在蒙特卡洛模拟这类场景里表现非常可靠。但从安全视角看MT19937有一个致命伤只要连续观察624个32位输出就能完整恢复它的内部状态。恢复之后未来所有的输出都能被预测过去的也能回推。这个特性在密码学场景是绝对的禁忌。所以Python官方的建议也很明确random模块只用于非安全场景做Token、密码相关的事请用secrets模块它底层基于操作系统的安全随机源。2.3 现代语言内置生成器的现状技术一直在迭代近十年各大语言慢慢把默认PRNG都换成了更新、更快的算法Python的random目前仍是MT19937官方在PEP 554等提案里曾讨论过更换但因为兼容性原因一直没动。JavaScript的Math.random()在V8引擎中曾长期使用 xorshift128它的生成速度比MT19937更快且状态空间小更适合浏览器这种内存敏感场景。Java的java.util.Random用的是48位种子的LCG变体质量只能说中等偏上Java 17之后引入了Xoshiro256** 算法RandomGenerator接口用来满足对性能和质量双重要求的场景。Go的math/rand/v2在Go 1.22中改用ChaCha8这个改动有点意思——直接用流密码当PRNG从设计上就兼顾了不可预测性。选型建议很直接不确定就跟着语言官方推荐走。只要不是写密码学相关代码语言内置的PRNG基本都够用一旦涉及安全立刻切换到密码学安全随机源。3. 不同语言里随机数的正确打开方式3.1 Pythonrandom 和 secrets 千万别混用Python大概是很多人上手编程用的第一门语言但random和secrets的区分很多老手都会忽视。import random import secrets # 非安全场景模拟、洗牌、随机抽样 print(random.randint(1, 100)) print(random.sample(range(1000), 10)) # 安全场景Token、验证码、密码学相关 print(secrets.token_hex(16)) print(secrets.randbelow(1000))经验法则凡是用户能通过输出倒推规律、或者被预测后会造成财产/安全损失的一律用secrets。我见过一些团队拿random.randint生成优惠券兑换码结果因为种子可预测被用户批量枚举出了所有有效码。这属于比较典型的随机数安全事件。另外一个Python高频陷阱多进程环境下的随机数重复。你用random.seed(time.time())在不同进程里分别设置种子一旦两个进程在同一毫秒启动种子完全相同生成的随机序列也会完全一样。更稳的做法是每个进程直接使用系统默认种子Python会自动从/dev/urandom取不要手动干预或者显式用进程PID参与种子构造。3.2 Java从 Random 到 SecureRandom 的选型之路Java里的随机数体系比较清晰但很多人从没注意过ThreadLocalRandom的存在。简单总结一下java.util.Random线程安全但性能差多线程高并发下会有CAS竞争因为底层用AtomicLong更新种子。java.util.concurrent.ThreadLocalRandom每个线程独立的随机数实例没有竞争性能最高适合并发环境下的非安全随机。java.security.SecureRandom密码学安全用于Token、密钥等敏感场景。初始化时建议显式指定算法比如SHA1PRNG或NativePRNG避免不同JDK版本默认值不一致导致的行为漂移。我在做高并发AB实验平台时曾经把所有分桶请求都用new Random(System.currentTimeMillis())创建实例结果QPS一上来大量线程拿到相同种子分桶结果严重偏斜。后来统一改成ThreadLocalRandom.current().nextInt()问题直接消失。每次new Random()本身也是一笔开销更可怕的是同毫秒内种子相同导致序列相同这类问题在日志里极难排查因为概率分布是对的只有分桶交叉验证时才会暴露。3.3 JavaScriptMath.random 与 crypto 的边界浏览器端的Math.random()被V8实现为 xorshift128生成速度快但存在一个已知问题攻击者可以通过抓取有限次输出恢复算法内部状态进而预测未来输出。这个特质在客户端抽奖、盲盒游戏里很可能被利用。如果你的抽奖逻辑跑在浏览器端本质上就是“开卷考试”——玩家修改内存、抓包、逆向代码都能操控结果。安全的做法是抽奖逻辑一律放服务端使用密码学安全的随机源。前端如果需要随机数做校验码可以调用crypto.getRandomValues或crypto.randomUUID。Node.js服务端则用require(crypto).randomInt()它比Math.random更安全生成的随机整数分布也更均匀。还有一个JS特有的问题Math.random()生成的是[0,1)之间的浮点数直接乘以区间长度再取整会引入微妙的模偏差modulo bias。尤其是当你用它来做随机索引、抽卡片时偏差虽然很小但在抽奖这种需要“绝对公平”的场景会被较真用户通过大量统计抓出来。4. 随机数在生产环境中的真实坑4.1 模偏差生成指定区间随机整数时最常见的暗坑很多教科书教的“随机0到n-1之间的整数”写法是rand() % n这个写法在数学上其实有陷阱。假设RAND_MAX32767你想生成0到9之间的整数32768不能被10整除余数分布是0到7各多一次机会导致你摸到0~7的概率比8~9略高。虽然单次差异微乎其微但在大量调用下分布偏差是可以通过统计检验发现并实锤的。正确处理方式有两种。第一种是通用的拒绝采样rejection samplingdef random_int_below(n, rand_max, rand_func): if n 0: raise ValueError(n must be positive) limit rand_max - (rand_max % n) while True: r rand_func() if r limit: return r % n它的大致思路是把能整除n的最大区间作为有效区间超出的部分直接丢弃重新生成这样每个余数出现的概率严格相等。第二种是直接用语言内置方法比如Pythonrandom.randrange内部已经做了拒绝采样Java的ThreadLocalRandom.nextInt(n)也处理了这个细节你自己别再加一层%就行。我个人在给一个游戏直播平台做抽奖引擎时遇到过某个运营反馈“这个奖池的SSR概率比配置的低了0.3个百分点”。排查到最后发现同事在ThreadLocalRandom.nextInt(100)结果上又做了一次%导致概率分布轻微偏斜。这类问题光看代码很难发现只有拿实际运行数据做分布检验才能看出端倪。4.2 并发环境下的随机数竞争与序列重复多线程程序里使用java.util.Random或Python多进程中不带独立种子的随机数会引发两类问题。一类是性能问题java.util.Random用CAS更新种子高并发下线程会大量自旋重试拖垮吞吐量。替代方案是用ThreadLocalRandomJava或random.Random的线程隔离实例Python。另一类是序列重复问题多个进程通过time.time()或time.monotonic_ns()设置种子在并发启动场景下极容易碰撞。最典型的就是容器化的多个实例同时启动时恰好都在同一微秒级调用随机数初始化结果生成相同序列导致数据库里出现大量相同的“随机验证码”。这个问题的根治思路是不手动设种子交给系统熵源。我在运维一个促销活动服务时踩过类似的坑。活动开始时需要批量生成10万个兑换码服务是20个Pod同时执行。用time.time_ns()做种子20个实例生成了大量重复码。后来把生成逻辑统一收敛到一个单实例服务里用secrets.token_hex(8)产出问题就消失了。随机数也属于“全局资源”尤其是需要全局唯一或全局随机性的场景一定要通过单一入口发号。4.3 蒙特卡洛模拟中的可复现性需求蒙特卡洛模拟Monte Carlo simulation是随机数在工程和科研里的重要应用。金融领域做期权定价、供应链做需求预测、物理模拟粒子运动都要依赖大量随机采样。这里有个反直觉的需求很多时候我们希望随机序列“可复现”。什么意思假如你跑100万次模拟发现结果异常如果没有固定种子每次重新运行序列都不同你根本无法定位是算法问题还是随机波动。所以规范的蒙特卡洛实验一定会设置固定种子并且把种子记录在日志里让结果可以被重复验证。用Python实现import random random.seed(20240601) # 固定种子 # 模拟逻辑...这样不仅方便复现还方便做并行计算。多个进程分别用不同种子跑子集最后再汇总结果能够显著提升大规模模拟的效率。4.4 密码学安全随机数为什么不能替代普通随机数看到这里可能有人会问既然secrets那么安全那我不分场景全用它不就行了不行两个原因。第一性能。密码学安全随机数生成依赖系统熵池或硬件DRBG吞吐量远低于普通PRNG。你在蒙特卡洛模拟里每秒需要上百万个随机数如果全走secrets性能会断崖式下降。第二可复现性。普通PRNG支持你设置种子、重放序列这在测试和模拟里是刚需加密安全随机数刻意设计成不可预测、不可复现你没法通过设置种子让测试场景稳定复现。所以工程上的正确姿势是“区分场景分层使用”抽奖、分桶、洗牌、模拟等非安全场景用高性能PRNG并支持种子注入Token、密钥、验证码等安全场景用加密安全随机源两者之间不要互相越界。5. 常见问题排查与避坑清单5.1 随机数“好像不够随机”时怎么判断有个很常见的问题是“我生成的随机数怎么总是重复”或者“为什么我用随机数洗牌总有几组排列很相似”先别急着怀疑算法按这几步排查检查种子设置。是不是每次都用time做种子而进程启动间隔极短导致种子相同。检查调用方式。是不是每次调用都重新new Random()而没有复用同一个实例。检查采样规模。如果从一个有限集合里重复采样碰撞是必然的这属于数学规律不是随机数质量问题。比如从100万个整数里随机抽1000个两个相同的概率极低但如果是抽奖码这种6位数字总共只有100万个空间生成100万次后碰撞概率就趋近100%这和PRNG质量无关。做基本统计检验。拿100万个数按100个桶做卡方检验如果卡方统计量超过临界值说明分布显著偏斜。网上有一些轻量级的随机数测试工具比如ent它输入一个二进制文件就能输出熵、卡方值、算术平均值等指标可以用来快速判断一个PRNG是否出现明显异常。5.2 抽奖系统被人抓出规律怎么办这种情况我见过不止一次。技术团队图省事把抽奖结果用Math.random()在前端生成或者在后端用random.randint生成但没注意日志里记录了种子。玩家通过多次抽奖、反推代码把内部状态摸清楚后就能在下一次抽奖前精准预测结果。应对措施分三块服务端抽奖核心算法用加密安全随机源secrets.randbelow或SecureRandom.nextInt。永远不要在日志或接口响应里暴露种子或内部状态。概率可见但结果不可预测。开奖节点定好开奖前不透露任何可能影响种子的信息。另外如果你用“奖池立即扣减”模式开奖同时从奖池里抽走奖项一定要保证随机生成和库存扣减在同一事务内完成否则并发请求会出现“超卖”。“随机”不只是一个数学问题涉及资金、库存时更是分布式系统一致性问题。5.3 一个常用的随机数选型速查表场景推荐方案不推荐方案普通模拟、随机抽样Pythonrandom/ JavaThreadLocalRandom自己手写LCG高并发AB分桶JavaThreadLocalRandom/ Gomath/rand/v2每次new Random()抽奖、发码、TokenPythonsecrets/ JavaSecureRandom/ Nodecrypto.randomIntMath.random()/random.randint需要可复现的模拟实验random.seed(固定值)不固定种子测试环境造数据固定种子保证稳定每次随机分布式环境生成唯一IDUUID v4 / 雪花算法 / 发号器时间戳做种子单独生成这张表也算是我这几年折腾出来的个人经验汇总。原则归纳起来就四句话能用系统库就用系统库别自己发明随机算法非安全场景别用安全随机源安全场景别用非安全随机源能固定种子就用固定种子方便调试和复现涉及全局唯一或并发启动的务必集中发号、避免种子碰撞。5.4 关于随机数质量你还应该知道的一个细节最后再分享一个容易被忽视的点。很多语言默认浮点随机数random.random()的精度是53位双精度浮点尾数而整数随机数的范围上限可能只有32位。如果你需要生成高精度随机小数比如做粒子模拟、金融定价要留意精度是否足够。很多专业库会提供高精度随机小数生成或者要求你自己用多个整数拼接出64位随机值再转成浮点数。我在写一个期权定价模型的时候拿Python的random.random()生成标准正态分布样本跑了500万次后发现尾部极值样本比理论期望少了约0.2%最后定位到是random.random()的53位精度在小概率事件采样上产生了微小的截断偏差。后来换成numpy.random.Generator基于PCG64算法支持64位随机整数并显式指定正态分布采样这个问题才消掉。越是追求极致精度和正确性的场景越要审视底层随机数的位宽和算法。随机数这个东西看起来是一行API调用实际需要考量的维度很多算法质量、种子管理、并发模型、安全边界、可复现性。希望这篇能帮你把散落的知识点串起来。写代码时多留个心眼该用secrets的别用random该固定种子的别偷懒不设出问题之前把这些都安排好你后面会少掉很多头发。
搞了这么多年技术回头一看“随机数”这仨字几乎是所有程序里最不起眼却最容易翻车的东西。写抽奖活动要用它做AB实验分桶要用它连单元测试里造假数据也离不开它。可真正问一句“随机数到底是怎么来的”能讲清楚的人真不多。很多人以为Math.random()和random.randint是同一个东西还有人在生产环境用时间戳当种子生成用户Token出了安全问题才知道随机数也有真假之分。这篇就把随机数的原理、算法、代码实现、业务场景里的坑一次讲透适合所有写过、正在写或者即将写随机数逻辑的开发者参考。我最早接触随机数是在游戏服写暴击判定当时老板说“概率调高一点就行”结果上线后玩家反馈“为什么连续十次不出暴击”我一看代码用的是srand(time(NULL))配合rand() % 100那一刻我就意识到随机数这件事看起来是几行代码实际上藏着大量值得深挖的细节。这篇文章从底层原理讲到业务实战最后附上我这些年踩过的坑希望能帮你少走弯路。1. 随机数的本质伪随机和真随机到底差在哪1.1 你写的随机数其实是一串“看起来随机”的数列绝大多数编程语言里你调用的随机函数都是伪随机数生成器PRNGPseudo Random Number Generator。它不是真的随机而是通过一个确定的数学公式从一个初始值种子开始不断迭代生成一个长数列。只要种子相同生成的数列就完全一致。这就是为什么很多游戏支持“种子地图”——同一个种子同样的地形重播时一模一样。那为什么我们感觉它很随机因为好的PRNG生成出来的数列能通过大部分统计学随机性测试比如数字分布均匀、序列之间没有明显相关性、周期足够长。换句话说它是在“模拟随机”而不是“制造随机”。以最经典的线性同余生成器LCG为例核心就一行公式X(n1) (a * X(n) c) mod m用一个小例子跑跑看假设a5, c1, m16, 种子1生成的序列是1, 6, 15, 12, 13, 2, 11, 8, 9, 14, 7, 4, 5, 10, 3, 1……到第16个数回到起点周期就是16。这个序列在统计意义上并不算优质但足够说明一个问题伪随机数的一切行为都是可预测的只要你知道算法和当前状态。而真随机数TRNG则是从物理世界的噪声中提取随机性比如CPU的热噪声、电子元件的抖动、甚至大气噪声这些过程本质上不可预测每次生成都是独立事件。1.2 为什么大多数场景用伪随机就足够看到这里你可能会问既然真随机更“正宗”为什么大家都在用伪随机答案很简单真随机太慢、太贵了。硬件真随机数生成器需要专门芯片或者至少依赖系统的熵池比如/dev/urandom每秒能产出的随机数数量有限而且不适合高频调用。而PRNG是纯数学计算一毫秒能跑几百上千万次性能差距悬殊。所以工程上的通用做法是“分层配合”系统层用硬件熵源做种子应用层用PRNG快速生成大量随机数。比如你在Java里用SecureRandom它内部先用操作系统的真随机源种下种子再基于种子做伪随机扩展兼顾安全性和性能。从这个角度看选PRNG还是TRNG核心判断标准只有一个这个随机数能不能被预测如果被预测了后果严不严重游戏里刷怪掉落、内容推荐里的随机排序被预测了无非是损失一点体验PRNG完全够用。但抽奖发红包、生成重置密码的Token、产生加密密钥一旦被预测就是安全事故这时候就必须上密码学安全的随机源。2. 亲手写一个随机数生成器从LCG到梅森旋转2.1 线性同余生成器的实现与致命弱点光说不练假把式先手写一个LCG看看真实面貌。我用Python实现一个class LCG: def __init__(self, seed): self.state seed self.a 1103515245 self.c 12345 self.m 2**31 def next(self): self.state (self.a * self.state self.c) % self.m return self.state def next_float(self): return self.next() / self.m这是很多C标准库早年使用的参数组合ANSI C。测试一下均匀性生成100万个数看分布lcg LCG(42) counts [0] * 10 for _ in range(1_000_000): bucket int(lcg.next_float() * 10) counts[bucket] 1 print(counts)我实测的结果大致在[99800, 100100, 99971, ...]附近看着还行分布确实比较均匀。但LCG有几个出了名的毛病低位周期短取state % 2^k时低k位的周期最多是2^k。比如x % 2的结果会严格在0、1、0、1交替根本不像随机的。序列相关性多维空间中点会落在超平面上这是LCG的数学结构导致的固有缺陷。状态可预测攻击者只要拿到连续两个输出反推参数和状态并不难。当年glibc早期版本的random()、以及很多旧平台的rand()都有类似问题。所以在真实项目里不要自己实现LCG去做任何跟“质量”相关的事。用它来跑个作业演示、生成散点图这种低频场景还凑合生产环境请直接选择成熟的库。2.2 梅森旋转算法为什么统治了十多年为了摆脱LCG的质量瓶颈1997年松本真和西村拓士提出了梅森旋转算法Mersenne TwisterMT19937。它用一段624个32位整数的状态数组通过一系列位运算生成随机数周期高达2^19937 - 1一度是“质量好”的代名词。Python 2.3到3.x的random模块底层用的就是它很多统计软件也默认用MT19937。MT19937的核心优势在于周期极长、分布均匀、生成速度快。它对所有基于1~623维的分布测试都能通过因此在蒙特卡洛模拟这类场景里表现非常可靠。但从安全视角看MT19937有一个致命伤只要连续观察624个32位输出就能完整恢复它的内部状态。恢复之后未来所有的输出都能被预测过去的也能回推。这个特性在密码学场景是绝对的禁忌。所以Python官方的建议也很明确random模块只用于非安全场景做Token、密码相关的事请用secrets模块它底层基于操作系统的安全随机源。2.3 现代语言内置生成器的现状技术一直在迭代近十年各大语言慢慢把默认PRNG都换成了更新、更快的算法Python的random目前仍是MT19937官方在PEP 554等提案里曾讨论过更换但因为兼容性原因一直没动。JavaScript的Math.random()在V8引擎中曾长期使用 xorshift128它的生成速度比MT19937更快且状态空间小更适合浏览器这种内存敏感场景。Java的java.util.Random用的是48位种子的LCG变体质量只能说中等偏上Java 17之后引入了Xoshiro256** 算法RandomGenerator接口用来满足对性能和质量双重要求的场景。Go的math/rand/v2在Go 1.22中改用ChaCha8这个改动有点意思——直接用流密码当PRNG从设计上就兼顾了不可预测性。选型建议很直接不确定就跟着语言官方推荐走。只要不是写密码学相关代码语言内置的PRNG基本都够用一旦涉及安全立刻切换到密码学安全随机源。3. 不同语言里随机数的正确打开方式3.1 Pythonrandom 和 secrets 千万别混用Python大概是很多人上手编程用的第一门语言但random和secrets的区分很多老手都会忽视。import random import secrets # 非安全场景模拟、洗牌、随机抽样 print(random.randint(1, 100)) print(random.sample(range(1000), 10)) # 安全场景Token、验证码、密码学相关 print(secrets.token_hex(16)) print(secrets.randbelow(1000))经验法则凡是用户能通过输出倒推规律、或者被预测后会造成财产/安全损失的一律用secrets。我见过一些团队拿random.randint生成优惠券兑换码结果因为种子可预测被用户批量枚举出了所有有效码。这属于比较典型的随机数安全事件。另外一个Python高频陷阱多进程环境下的随机数重复。你用random.seed(time.time())在不同进程里分别设置种子一旦两个进程在同一毫秒启动种子完全相同生成的随机序列也会完全一样。更稳的做法是每个进程直接使用系统默认种子Python会自动从/dev/urandom取不要手动干预或者显式用进程PID参与种子构造。3.2 Java从 Random 到 SecureRandom 的选型之路Java里的随机数体系比较清晰但很多人从没注意过ThreadLocalRandom的存在。简单总结一下java.util.Random线程安全但性能差多线程高并发下会有CAS竞争因为底层用AtomicLong更新种子。java.util.concurrent.ThreadLocalRandom每个线程独立的随机数实例没有竞争性能最高适合并发环境下的非安全随机。java.security.SecureRandom密码学安全用于Token、密钥等敏感场景。初始化时建议显式指定算法比如SHA1PRNG或NativePRNG避免不同JDK版本默认值不一致导致的行为漂移。我在做高并发AB实验平台时曾经把所有分桶请求都用new Random(System.currentTimeMillis())创建实例结果QPS一上来大量线程拿到相同种子分桶结果严重偏斜。后来统一改成ThreadLocalRandom.current().nextInt()问题直接消失。每次new Random()本身也是一笔开销更可怕的是同毫秒内种子相同导致序列相同这类问题在日志里极难排查因为概率分布是对的只有分桶交叉验证时才会暴露。3.3 JavaScriptMath.random 与 crypto 的边界浏览器端的Math.random()被V8实现为 xorshift128生成速度快但存在一个已知问题攻击者可以通过抓取有限次输出恢复算法内部状态进而预测未来输出。这个特质在客户端抽奖、盲盒游戏里很可能被利用。如果你的抽奖逻辑跑在浏览器端本质上就是“开卷考试”——玩家修改内存、抓包、逆向代码都能操控结果。安全的做法是抽奖逻辑一律放服务端使用密码学安全的随机源。前端如果需要随机数做校验码可以调用crypto.getRandomValues或crypto.randomUUID。Node.js服务端则用require(crypto).randomInt()它比Math.random更安全生成的随机整数分布也更均匀。还有一个JS特有的问题Math.random()生成的是[0,1)之间的浮点数直接乘以区间长度再取整会引入微妙的模偏差modulo bias。尤其是当你用它来做随机索引、抽卡片时偏差虽然很小但在抽奖这种需要“绝对公平”的场景会被较真用户通过大量统计抓出来。4. 随机数在生产环境中的真实坑4.1 模偏差生成指定区间随机整数时最常见的暗坑很多教科书教的“随机0到n-1之间的整数”写法是rand() % n这个写法在数学上其实有陷阱。假设RAND_MAX32767你想生成0到9之间的整数32768不能被10整除余数分布是0到7各多一次机会导致你摸到0~7的概率比8~9略高。虽然单次差异微乎其微但在大量调用下分布偏差是可以通过统计检验发现并实锤的。正确处理方式有两种。第一种是通用的拒绝采样rejection samplingdef random_int_below(n, rand_max, rand_func): if n 0: raise ValueError(n must be positive) limit rand_max - (rand_max % n) while True: r rand_func() if r limit: return r % n它的大致思路是把能整除n的最大区间作为有效区间超出的部分直接丢弃重新生成这样每个余数出现的概率严格相等。第二种是直接用语言内置方法比如Pythonrandom.randrange内部已经做了拒绝采样Java的ThreadLocalRandom.nextInt(n)也处理了这个细节你自己别再加一层%就行。我个人在给一个游戏直播平台做抽奖引擎时遇到过某个运营反馈“这个奖池的SSR概率比配置的低了0.3个百分点”。排查到最后发现同事在ThreadLocalRandom.nextInt(100)结果上又做了一次%导致概率分布轻微偏斜。这类问题光看代码很难发现只有拿实际运行数据做分布检验才能看出端倪。4.2 并发环境下的随机数竞争与序列重复多线程程序里使用java.util.Random或Python多进程中不带独立种子的随机数会引发两类问题。一类是性能问题java.util.Random用CAS更新种子高并发下线程会大量自旋重试拖垮吞吐量。替代方案是用ThreadLocalRandomJava或random.Random的线程隔离实例Python。另一类是序列重复问题多个进程通过time.time()或time.monotonic_ns()设置种子在并发启动场景下极容易碰撞。最典型的就是容器化的多个实例同时启动时恰好都在同一微秒级调用随机数初始化结果生成相同序列导致数据库里出现大量相同的“随机验证码”。这个问题的根治思路是不手动设种子交给系统熵源。我在运维一个促销活动服务时踩过类似的坑。活动开始时需要批量生成10万个兑换码服务是20个Pod同时执行。用time.time_ns()做种子20个实例生成了大量重复码。后来把生成逻辑统一收敛到一个单实例服务里用secrets.token_hex(8)产出问题就消失了。随机数也属于“全局资源”尤其是需要全局唯一或全局随机性的场景一定要通过单一入口发号。4.3 蒙特卡洛模拟中的可复现性需求蒙特卡洛模拟Monte Carlo simulation是随机数在工程和科研里的重要应用。金融领域做期权定价、供应链做需求预测、物理模拟粒子运动都要依赖大量随机采样。这里有个反直觉的需求很多时候我们希望随机序列“可复现”。什么意思假如你跑100万次模拟发现结果异常如果没有固定种子每次重新运行序列都不同你根本无法定位是算法问题还是随机波动。所以规范的蒙特卡洛实验一定会设置固定种子并且把种子记录在日志里让结果可以被重复验证。用Python实现import random random.seed(20240601) # 固定种子 # 模拟逻辑...这样不仅方便复现还方便做并行计算。多个进程分别用不同种子跑子集最后再汇总结果能够显著提升大规模模拟的效率。4.4 密码学安全随机数为什么不能替代普通随机数看到这里可能有人会问既然secrets那么安全那我不分场景全用它不就行了不行两个原因。第一性能。密码学安全随机数生成依赖系统熵池或硬件DRBG吞吐量远低于普通PRNG。你在蒙特卡洛模拟里每秒需要上百万个随机数如果全走secrets性能会断崖式下降。第二可复现性。普通PRNG支持你设置种子、重放序列这在测试和模拟里是刚需加密安全随机数刻意设计成不可预测、不可复现你没法通过设置种子让测试场景稳定复现。所以工程上的正确姿势是“区分场景分层使用”抽奖、分桶、洗牌、模拟等非安全场景用高性能PRNG并支持种子注入Token、密钥、验证码等安全场景用加密安全随机源两者之间不要互相越界。5. 常见问题排查与避坑清单5.1 随机数“好像不够随机”时怎么判断有个很常见的问题是“我生成的随机数怎么总是重复”或者“为什么我用随机数洗牌总有几组排列很相似”先别急着怀疑算法按这几步排查检查种子设置。是不是每次都用time做种子而进程启动间隔极短导致种子相同。检查调用方式。是不是每次调用都重新new Random()而没有复用同一个实例。检查采样规模。如果从一个有限集合里重复采样碰撞是必然的这属于数学规律不是随机数质量问题。比如从100万个整数里随机抽1000个两个相同的概率极低但如果是抽奖码这种6位数字总共只有100万个空间生成100万次后碰撞概率就趋近100%这和PRNG质量无关。做基本统计检验。拿100万个数按100个桶做卡方检验如果卡方统计量超过临界值说明分布显著偏斜。网上有一些轻量级的随机数测试工具比如ent它输入一个二进制文件就能输出熵、卡方值、算术平均值等指标可以用来快速判断一个PRNG是否出现明显异常。5.2 抽奖系统被人抓出规律怎么办这种情况我见过不止一次。技术团队图省事把抽奖结果用Math.random()在前端生成或者在后端用random.randint生成但没注意日志里记录了种子。玩家通过多次抽奖、反推代码把内部状态摸清楚后就能在下一次抽奖前精准预测结果。应对措施分三块服务端抽奖核心算法用加密安全随机源secrets.randbelow或SecureRandom.nextInt。永远不要在日志或接口响应里暴露种子或内部状态。概率可见但结果不可预测。开奖节点定好开奖前不透露任何可能影响种子的信息。另外如果你用“奖池立即扣减”模式开奖同时从奖池里抽走奖项一定要保证随机生成和库存扣减在同一事务内完成否则并发请求会出现“超卖”。“随机”不只是一个数学问题涉及资金、库存时更是分布式系统一致性问题。5.3 一个常用的随机数选型速查表场景推荐方案不推荐方案普通模拟、随机抽样Pythonrandom/ JavaThreadLocalRandom自己手写LCG高并发AB分桶JavaThreadLocalRandom/ Gomath/rand/v2每次new Random()抽奖、发码、TokenPythonsecrets/ JavaSecureRandom/ Nodecrypto.randomIntMath.random()/random.randint需要可复现的模拟实验random.seed(固定值)不固定种子测试环境造数据固定种子保证稳定每次随机分布式环境生成唯一IDUUID v4 / 雪花算法 / 发号器时间戳做种子单独生成这张表也算是我这几年折腾出来的个人经验汇总。原则归纳起来就四句话能用系统库就用系统库别自己发明随机算法非安全场景别用安全随机源安全场景别用非安全随机源能固定种子就用固定种子方便调试和复现涉及全局唯一或并发启动的务必集中发号、避免种子碰撞。5.4 关于随机数质量你还应该知道的一个细节最后再分享一个容易被忽视的点。很多语言默认浮点随机数random.random()的精度是53位双精度浮点尾数而整数随机数的范围上限可能只有32位。如果你需要生成高精度随机小数比如做粒子模拟、金融定价要留意精度是否足够。很多专业库会提供高精度随机小数生成或者要求你自己用多个整数拼接出64位随机值再转成浮点数。我在写一个期权定价模型的时候拿Python的random.random()生成标准正态分布样本跑了500万次后发现尾部极值样本比理论期望少了约0.2%最后定位到是random.random()的53位精度在小概率事件采样上产生了微小的截断偏差。后来换成numpy.random.Generator基于PCG64算法支持64位随机整数并显式指定正态分布采样这个问题才消掉。越是追求极致精度和正确性的场景越要审视底层随机数的位宽和算法。随机数这个东西看起来是一行API调用实际需要考量的维度很多算法质量、种子管理、并发模型、安全边界、可复现性。希望这篇能帮你把散落的知识点串起来。写代码时多留个心眼该用secrets的别用random该固定种子的别偷懒不设出问题之前把这些都安排好你后面会少掉很多头发。
算法精解与面试技巧)
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
