多线程高频生成随机数且无需可重现序列时应优先用ThreadLocalRandom；它为每线程提供独立实例避免同步开销，而Random适用于需固定种子复现序列的场景。
什么时候该用 ThreadLocalRandom 而不是 Random
多线程环境下直接共享一个 Random 实例会导致竞争，性能下降明显；ThreadLocalRandom 为每个线程提供独立实例，避免同步开销。它专为并发场景设计，**只要你在多线程里生成随机数，且不需要可重现的序列，就该优先选 ThreadLocalRandom**。
常见误用场景包括：在 Runnable 或 CompletableFuture 中反复调用 new Random()，或把单例 Random 注入到 Spring Bean 中被多个线程共用。
-
ThreadLocalRandom不支持设置种子（setSeed()），无法复现随机序列 - 不能通过构造函数创建，必须用静态方法获取：
ThreadLocalRandom.current() - 它不继承
Random，但 API 高度兼容（nextInt()、nextDouble()等行为一致）
Random 的种子机制和可重现性怎么控制
Random 的核心价值在于确定性——相同种子产生完全相同的随机数序列。这对测试、模拟、游戏存档等场景至关重要；而 ThreadLocalRandom 完全不支持这个能力。
例如单元测试中想验证某段逻辑对固定随机输入的响应，必须用 new Random(123L)；若用 ThreadLocalRandom.current()，每次运行结果都不同，断言会不稳定。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 无参构造器
new Random()使用系统时间纳秒 + 系统哈希混合生成种子，实际不可控 - 显式传入
long种子（如new Random(42L)）才能保证跨 JVM、跨运行复现 - 注意：
SecureRandom虽也继承Random，但其种子生成机制更复杂，setSeed()行为与Random不同，不要混用
nextInt(int bound) 的边界行为容易踩哪些坑
两个类都提供 nextInt(int bound)，但它的范围是 [0, bound)（左闭右开），**不包含 bound 本身**。这是最常被忽略的边界细节。
比如想生成 1~6 的骰子点数，写成 random.nextInt(6) 得到的是 0~5；正确写法是 random.nextInt(6) + 1。若 bound ≤ 0，会直接抛 IllegalArgumentException。
-
bound必须为正整数，否则运行时报错：java.lang.IllegalArgumentException: bound must be positive - 生成 [min, max] 闭区间整数：用
random.nextInt(max - min + 1) + min - 生成 [0.0, 1.0) 浮点数用
nextDouble()，它没有参数重载，永远是这个范围
高并发下 ThreadLocalRandom 的初始化成本和线程生命周期影响
ThreadLocalRandom 第一次调用 current() 时才会初始化本线程专属实例，内部基于 Unsafe 操作，开销极小。但它和线程绑定，**如果在线程池中长期复用线程（如 Tomcat 或 ForkJoinPool），实例会一直存在，不会泄漏，也不需要手动清理**。
真正要注意的是：不要在每次任务里重复调用 ThreadLocalRandom.current() 并赋值给局部变量——这不是必须的，但更关键的是，别把它当作“线程安全的 Random 单例”去缓存或传递，它只应在当前线程内使用。
- 错误做法：
private final ThreadLocalRandom rnd = ThreadLocalRandom.current();（在类字段里初始化，可能发生在类加载线程，后续在其他线程调用会出错） - 正确做法：每次需要时调用
ThreadLocalRandom.current().nextInt(100)，JVM 已优化过该调用路径 - 在 ForkJoinPool 的并行流中，
ThreadLocalRandom.current()依然有效，无需额外适配
真正复杂的点在于：你得时刻分清「是否需要可重现」和「是否处于多线程高频调用路径」——这两个条件一旦交叉，选错工具就会导致测试失败或压测时 CPU 突增。没想清楚这点，光看 API 文档容易掉进坑里。
