nextsecondaryseed 不是供你主动调用的公开 api，它不参与随机数生成主流程，也不该用于实现随机化分布——强行使用会破坏线程隔离、引入竞态且毫无收益。
直接说结论：nextSecondarySeed 不是供你主动调用的公开 API，它不参与随机数生成主流程，也不该被用于“实现随机化分布”——强行使用会破坏线程隔离、引入竞态，且毫无收益。
为什么不能调用 nextSecondarySeed
这个方法是 ThreadLocalRandom 内部使用的私有辅助函数，仅在极少数初始化或探针更新场景下由 JVM 自动触发。它的返回值不保证均匀性，也不参与 nextInt()、nextLong() 等任何公开随机逻辑；它只负责更新 threadLocalRandomSecondarySeed 这个次要探针字段，用途是缓解哈希冲突（比如 ForkJoinPool 的 work-stealing 调度），和业务层的“随机化分布”完全无关。
- 它没有 public 修饰符，反射调用会触发
IllegalAccessError（JDK 9+ 模块系统默认禁止） - 即使绕过访问限制，多次调用也不会改变当前线程的主随机种子
threadLocalRandomSeed，对生成的随机数序列无影响 - 它的算法（基于 gamma 常量的简单位移异或）并非统计学安全，也不满足均匀/独立性要求
ThreadLocalRandom.current().nextInt(origin, bound) 才是正确起点
真正支撑高并发随机化分布的是 ThreadLocalRandom.current() 返回的线程独占实例，以及其带范围的生成方法。它们天然隔离、无锁、语义明确：
-
nextInt(1, 1001)生成 [1, 1000] 的整数，开闭区间清晰，避免手写%带来的偏斜 - 每个线程的
threadLocalRandomSeed由SecureRandom初始化，初始值互不相关，从源头杜绝序列重复 - 在
ExecutorService或ForkJoinPool中，只要不把实例缓存为static，每次调用都走当前线程专属路径
容易踩的坑：静态缓存 + 线程池复用 = 随机性坍塌
常见误用是把 ThreadLocalRandom 实例存在 static final 字段里，尤其在 Spring Bean 或工具类中：
private static final ThreadLocalRandom RANDOM = ThreadLocalRandom.current(); // ❌ 危险！
public int nextId() {
return RANDOM.nextInt(1_000_000);
}
问题在于：current() 在类加载时只执行一次，所有线程共享同一个初始实例 —— 这等价于退化成 Random，CAS 竞争照旧，且线程池复用后，不同请求拿到的“随机数”可能高度重复（因种子未重置）。正确做法是每次需要时都调用 ThreadLocalRandom.current()。
真要控制分布？靠参数，不是靠底层字段
如果你需要非均匀分布（比如幂律、指数衰减、加权抽样），不要碰 nextSecondarySeed，而应：
- 用
ThreadLocalRandom.current().nextDouble()获取 [0.0, 1.0) 均匀源，再套用逆变换法（inverse transform）映射到目标分布 - 对加权场景，先用
nextInt()生成总权重范围内的索引，再二分查找对应项（避免Stream的skip开销） - 若需跨线程复现序列（如压测回放），必须放弃
ThreadLocalRandom，改用带固定 seed 的new Random(seed)
记住：ThreadLocalRandom 的价值在于“每个线程玩自己的骰子”，而不是给你拆开骰子看齿轮。想改分布，换投法，别撬骰子。
