randomgenerator 接口不能直接 new，因是抽象接口，需通过 randomgeneratorfactory.of("lxm") 等获取实现类；它统一随机算法抽象，不替代 random 日常用法，方法返回基本类型且带双参数范围重载，模运算取范围错误。
RandomGenerator 接口到底能不能直接 new
不能。它是个接口，不是具体实现类，直接 new RandomGenerator() 会编译报错 java: RandomGenerator is abstract; cannot be instantiated。
Java 17 引入它，本意是统一随机数生成器的抽象层，让不同算法（如 LXM、Xoroshiro、SecureRandomGenerator）能共用一套方法签名，而不是替代 java.util.Random 的日常使用习惯。
- 要用，得选一个具体实现：比如
RandomGeneratorFactory.of("LXM")获取工厂，再调用create() -
ThreadLocalRandom和SecureRandom也实现了该接口，但它们本身已有成熟构造方式，不必强走工厂流程 - 别在老项目里硬套新接口——除非你真需要切换底层算法，或做可插拔的随机策略配置
如何用 RandomGeneratorFactory 挑到合适的生成器
工厂名不是随便写的，拼错就抛 IllegalArgumentException；而且不同 JVM 实现（如 OpenJDK vs. GraalVM）支持的算法列表可能不同。
推荐先查可用列表：RandomGeneratorFactory.all() 返回所有注册名，常见有："LXM"（默认推荐，速度快、周期长）、"Xoroshiro128PlusPlus"（轻量、适合嵌入式）、"SecureRandom"（注意：这是别名，实际指向 SecureRandom 实例）。
立即学习“Java免费学习笔记（深入）”；
- 性能敏感场景优先选
"LXM"，它比旧版Random快约 2–3 倍，且无统计偏差 - 需要密码学安全？用
"SecureRandom"工厂名，但要注意它创建的是新实例，不共享SecureRandom的内部状态 - 别用
"Random"当工厂名——它不存在；旧Random类没实现RandomGenerator，得自己包装
RandomGenerator 和 Random 的方法差异在哪
核心区别在「返回值类型」和「流式支持」：RandomGenerator 所有 next* 方法都返回基本类型（int、long、double），不带 bound 参数重载；而 Random 大量依赖 nextInt(int bound) 这类带范围的便捷方法。
如果你习惯写 random.nextInt(100)，换成 rg.nextInt() % 100 是错的——模运算会破坏均匀性，尤其当模数不是 2 的幂时。
- 正确做法：用
rg.nextInt(0, 100)（注意两个参数！这是RandomGenerator新增的带范围方法） -
nextDouble(double origin, double bound)同理，范围左闭右开，和Random.nextDouble()行为一致 - 要生成随机字节数组？
rg.nextBytes(byte[] bytes)可用，但没Random的nextBytes(int len)那种自动分配版本
为什么 SecureRandom 实现了 RandomGenerator 却还建议慎用
因为 SecureRandomGenerator（即工厂名 "SecureRandom" 对应的实现）每次 create() 都新建一个 SecureRandom 实例，而 SecureRandom 初始化可能阻塞（尤其在熵不足的容器环境），且内部 SecureRandomSpi 实现未必线程安全。
换句话说：它“能用”，但不等于“该这么用”。生产环境已有 SecureRandom 单例时，没必要绕一圈工厂。
- 如果只是需要密码学安全随机数，继续用单例
SecureRandom.getInstanceStrong()更稳 - 只有当你需要把安全随机器作为策略注入（比如测试时 mock、或运行时动态切换 SPI），才值得走
RandomGeneratorFactory流程 - 别在循环里反复
factory.create()—— 创建开销大，且可能耗尽熵池
真正麻烦的不是接口怎么写，而是搞清你到底要不要换。大多数业务代码继续用 ThreadLocalRandom 或单例 SecureRandom 就行；RandomGenerator 是给框架作者和算法替换留的后门，不是给日常 nextInt(6) 加个新写法的。
