基于CPU时钟快照生成的数字是否具备真随机性？

我一直对随机数十分关注，由于计算机中的RNG（随机数生成器）并非真正的随机，我在寻找不同的随机数生成方式。这一点在音乐播放器上表现得尤为明显：开启随机播放时，总会重复某些歌曲，完全跳过另一些；重置播放器后，重复的歌曲会变化，但总有部分歌曲被选中的频率远高于其他。

于是我思考如何生成更「自然」的随机数。计算机中的「真随机性」来自哪里？我认为是CPU——CPU时钟的速率会因负载、温度、电源波动等多种因素，每皮秒都有所不同。我得出结论：定期对时钟进行快照，提取其小数部分（范围在100微秒到1皮秒，即0.00000n - 0.00000000n）可以得到随机数。

我编写了如下Python脚本进行测试：

#!/usr/bin/env python
import time
ct = 0

#Are these numbers random?

while ct < 10:

    print (str(time.monotonic())[-4:-1],str(time.monotonic())[-4:-1],str(time.monotonic())[-4:-1],end='\n')
    ct += 1

输出结果：

710 062 469
345 863 084
639 060 263
643 057 258
627 039 249
032 767 971
436 839 040
637 097 302
693 158 937
175 207 402

在此向专业人士请教：这些生成的数字是否是随机数？

抱歉我的技术知识有限——我曾是一名机械师，在一场摩托车事故中失去了一只手臂，现在正在自学计算机科学。我对随机数和质数很感兴趣，但显然对两者都了解不深。

首先直接给出结论：你提取的这些数字不具备足够的随机性，无法作为可靠的随机数使用，核心原因如下：

1. time.monotonic()的精度限制
   大多数系统中，time.monotonic()的实际精度远达不到皮秒级，通常仅能到毫秒或微秒级。你提取的末尾几位，本质是系统时钟计数的低位，更多由操作系统的时钟调度逻辑决定，而非CPU时钟的自然波动。

2. 强相关性问题
   你在同一循环内连续三次调用time.monotonic()，调用间隔极短，返回值的末尾几位存在极强相关性——从输出也能看到同一行的三个数字完全相同，这不符合随机数的独立性要求。

3. 可预测性高
   即使CPU时钟存在波动，这种波动通常是缓慢且有规律的（比如温度上升导致时钟速率线性下降），并非无规律的随机事件。通过监测系统负载、温度等参数，攻击者可以大概率预测你提取的数值范围，不满足高强度随机数的要求。

更可靠的随机数生成方案 #

如果你需要真正的随机数，推荐以下几种方向：

• 系统原生真随机数源：Linux的/dev/random//dev/urandom、Windows的CryptGenRandom，Python中可通过secrets模块（密码学安全场景）或os.urandom()访问，这些源会收集系统硬件噪声（CPU波动、磁盘IO延迟、输入设备操作等）生成真随机数。
• 硬件随机数生成器：部分高端CPU内置硬件随机数模块（如Intel的RdRand指令），Python的cryptography库可直接调用这类硬件接口。
• 优化伪随机数使用：如果只是解决音乐播放器的不均匀问题，无需真随机数——用Python的random.shuffle()先将播放列表完全打乱，再顺序播放，就能避免重复或偏斜问题。

补充 #

你遇到的音乐播放器随机播放问题，本质是伪随机数生成器的均匀性不足，很多播放器的算法在小样本下易出现重复，打乱列表再播放是最简单的解决办法。

内容的提问来源于stack exchange，提问作者Pollypeptide