多线程中应使用 ThreadLocalRandom 而非 Random，因后者依赖 AtomicLong CAS 导致高并发下性能骤降且可能产生重复/可预测值；ThreadLocalRandom 每线程私有实例，零竞争，但缺失 nextGaussian()、setSeed() 等方法，且 nextBytes() 不保证填满数组。
为什么多线程里用
会变慢甚至出错
因为
内部用
做种子更新，每次调用
、
都要 CAS 重试。高并发下线程争抢激烈，大量失败重试拖慢速度；更隐蔽的问题是：某些 JDK 版本中，连续多次
可能因竞争导致种子更新顺序错乱，产出重复或可预测的值。
典型现象：
在压测时吞吐骤降，或多个线程生成的随机数序列高度相似
适用场景：单线程工具类、测试数据生成、非关键路径的轻量随机
别在
或
里共享同一个
实例
怎么用才不白费
它不是靠加锁，而是每个线程首次调用时初始化自己的私有
实例，后续完全无共享、无竞争。但必须通过静态方法获取——不能 new，也不能从其他 Random 派生。
正确写法：
，每次都要调
错误写法：
（构造函数私有）、
（不生效）
注意：
不支持设置自定义种子，初始化种子来自
和
操作，不可控但够安全
替换时要注意的三个兼容性断点
接口和
高度一致，但少了几个常用方法，硬替可能编译不过或逻辑跑偏。
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
没有
—— 如果需要正态分布，得自己用 Box-Muller 公式实现，或继续用
实例（隔离在线程内）
没有
—— 无法复现随机序列，单元测试若依赖固定种子，得保留
分支
行为不同：它不保证填满整个数组（文档明确说明），而
一定填满；若业务依赖“必填满”，需加循环校验
性能差距到底有多大
在 16 核机器上，100 个线程并发调用
100 万次：
耗时约 850ms，
稳定在 110ms 左右。差距主要来自 CAS 失败率——线程越多，
的失败率指数上升。
立即学习
“
Java免费学习笔记（深入）
”；
小线程数（≤4）时差异不明显，但代码可维护性上
更清晰
JDK 17+ 中
底层已优化，但
仍是唯一零竞争方案
如果用
，尤其要注意：工作线程复用频繁，
的线程局部性优势更突出
真正麻烦的是混合场景——比如主线程预热用
设种子，子线程又切到
。这种跨上下文的随机性衔接，没人帮你自动对齐。
java.util.Randomjava.util.RandomAtomicLongnextInt()nextDouble()nextLong()Random.nextInt()RunnableCompletableFutureRandomThreadLocalRandomRandomThreadLocalRandom.current().nextInt(100)current()new ThreadLocalRandom()ThreadLocalRandom.current().setSeed(...)ThreadLocalRandomSystem.nanoTime()UNSAFEThreadLocalRandomRandomnextGaussian()RandomsetSeed(long)RandomnextBytes(byte[])Random.nextBytes()nextInt()RandomThreadLocalRandomRandomThreadLocalRandomRandomThreadLocalRandomForkJoinPoolThreadLocalRandomRandomThreadLocalRandom