应根据抽样需求选择合适方法：抽1个用nextInt安全；抽k个不重复且k远小于列表大小用Set去重；k接近列表大小则用Collections.shuffle()后截取，但需先拷贝避免修改原集合；多线程高频采样必须用ThreadLocalRandom.current()；务必处理空列表、k≤0、k≥列表长度等边界情况。
用 Random 从 List 里抽几个元素，别直接用 nextInt(list.size()) 循环调用
反复调用 nextInt() 取索引再取值，容易重复——尤其当你要抽的个数接近列表长度时。这不是“随机不够好”，而是逻辑没覆盖去重需求。
实操建议：
- 如果只要抽 1 个：直接
random.nextInt(list.size())拿索引，安全 - 如果要抽 k 个不重复（k 远小于 list 大小）：用
Set<integer></integer>存已选索引，循环直到 size 达标 - 如果 k 接近 list 大小，或要求高效无重复：改用
Collections.shuffle()后截取前 k 个——它内部用 Fisher-Yates，O(n) 且均匀
Collections.shuffle() 的坑：别在生产环境对大 List 直接全量打乱
它会原地修改原集合。如果你只是想采样，又得保留原始顺序，那就得先 new ArrayList(original) 拷贝一份——否则后续逻辑可能出错。
性能上，shuffle 是 O(n)，但常数不小；若 list 有 100 万元素只抽 10 个，花 50ms 打乱全部再截取，纯属浪费。
立即学习“Java免费学习笔记（深入）”；
示例对比：
List<String> src = Arrays.asList("a", "b", "c", "d", "e");
// ✅ 安全：拷贝后 shuffle
List<String> sampled = new ArrayList<>(src);
Collections.shuffle(sampled, random);
sampled = sampled.subList(0, Math.min(3, sampled.size()));
// ❌ 危险：原 list 被改了顺序
Collections.shuffle(src, random); // 后续用 src 的地方全乱了
用 ThreadLocalRandom 替代共享 Random 实例
多线程环境下，多个线程共用一个 Random 对象，会触发内部 CAS 重试，吞吐下降明显；而 ThreadLocalRandom.current() 每线程独立实例，无竞争。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
常见错误现象：Random 放在静态字段里被多线程并发调用，压测时采样速率卡在某个平台阈值上，查不出瓶颈。
实操建议：
- 单线程场景：用普通
Random或ThreadLocalRandom都行 - 多线程高频采样（如网关日志抽样）：必须用
ThreadLocalRandom.current() - 别缓存
ThreadLocalRandom实例——它本就是线程绑定的，每次调用current()开销极低
边界情况：空 List、k > list.size()、k
这些不是“异常场景”，而是真实业务中会发生的输入——比如上游数据临时为空，或配置采样数写错了。
别依赖抛异常来兜底，应主动判断：
-
list.isEmpty()→ 直接返回空List k → 返回空 <code>List（不是 throw）-
k >= list.size()→ 直接返回原List的副本（别 shuffle 全量）
很多人卡在 subList(0, k) 报 IndexOutOfBoundsException，其实就差一行 Math.min(k, list.size())。
真正难的不是“怎么随机”，是搞清你要的是“可重复”还是“不可重复”、要不要保持原顺序、有没有并发、输⼊边界是否可控——这些决定了该用哪条路，而不是死记哪个函数名。
