为何numpy.random.seed在并行计算中不固定，RandomState却可稳定生效？

咱们先把两个核心问题拆解开来解释，结合你遇到的并行场景问题，就能明白为啥会出现这种差异了。

一、np.random.seed() 和 RandomState 的核心差异 #

• 全局共享状态 vs 独立局部状态
  • np.random.seed(n) 是给numpy全局的随机数生成器设置初始种子，整个Python进程里所有调用 np.random.* 系列函数的地方，都会共享这同一个生成器的状态。每次调用随机数函数，这个全局状态都会被修改。
  • np.random.RandomState(n) 是创建一个独立的随机数生成器实例。这个实例的状态完全独立于全局生成器，也不会和其他RandomState实例互相干扰。只有调用这个实例的方法（比如local_state.normal()）时，才会修改它自己的状态。

二、为什么np.random.seed()在并行（threading后端）场景下无法保证结果稳定？ #

你用的是joblib的threading后端，这种多线程模式下，所有线程共享同一个进程的内存空间——也就是说，全局的随机数生成器状态是所有线程共用的。问题就出在线程调度的不确定性和全局状态的竞争上：

1. 你的_estimate_mean()函数里，每次都会先调用np.random.seed(0)重置全局状态，然后生成随机数。但线程的执行是由操作系统抢占式调度的，完全没有固定顺序。
2. 举个例子：线程A刚执行完np.random.seed(0)，还没来得及生成随机数，线程B就抢到了CPU时间片，也执行了np.random.seed(0)——这相当于把全局状态又重置了一次。等线程A再回来执行np.random.normal()时，看起来是从seed=0开始，但实际上可能已经被其他线程的操作干扰了状态（或者反过来）。
3. 更极端的情况是，线程A在生成100个随机数的过程中，线程B插入并重置了全局seed，导致线程A后续生成的随机数根本不是预期的序列，最终每个线程返回的均值就会不一样。

而用RandomState时，每个线程都会创建自己的局部生成器实例，它们的状态完全隔离。不管线程怎么调度，每个实例都是从seed=0的初始状态开始生成随机数，所以每次调用_estimate_mean()的结果都是一致的。

结合你的代码示例验证 #

原始串行代码（结果稳定） #

import numpy as np
from joblib import Parallel, delayed

def _estimate_mean():
    np.random.seed(0)
    x = np.random.normal(0, 2, size=100)
    return np.mean(x)

# 串行运行
tst = [_estimate_mean() for i in range(8)]
# 输出: [0.11961603106897, 0.11961603106897, ...]

串行时，每次调用函数都会先重置全局seed到同一个起点，完整生成随机数序列，所以结果完全一致。

原始并行代码（结果不稳定） #

tst = Parallel(n_jobs=-1, backend="threading")(delayed(_estimate_mean)() for i in range(8))
# 输出: [0.11961603106897, 0.11961603106897, 0.1640259414956747, ...]

多线程共享全局状态，seed(0)的调用和随机数生成被线程调度打乱，导致部分线程的随机数序列不符合预期，结果不稳定。

修改后使用RandomState的并行代码（结果稳定） #

def _estimate_mean():
    local_state = np.random.RandomState(0)
    x = local_state.normal(0, 2, size=100)
    return np.mean(x)

tst = Parallel(n_jobs=-1, backend="threading")(delayed(_estimate_mean)() for i in range(8))
# 输出: [0.11961603106897, 0.11961603106897, ...]

每个线程使用独立的RandomState实例，状态互不干扰，所以所有线程生成的随机数序列完全相同，结果稳定一致。

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