应使用TreeMap<Long, T>存储累积权重右边界实现O(log n)加权随机抽取，而非Random.nextDouble()×totalWeight遍历匹配，因后者时间复杂度O(n)在高频调用时显著拖慢性能。
为什么不用 Random.nextDouble() 直接乘总权重
直接用 nextDouble() * totalWeight 得到一个浮点数，再遍历累加权重匹配区间——看似简单，但实际在权重数量大（比如上千个选项）或高频调用时，每次都要从头累加，时间复杂度是 O(n)。线上服务里，单次抽取耗时从纳秒级跳到微秒级，积少成多就容易拖慢吞吐。
TreeMap 的核心价值不是“排序”，而是利用其底层红黑树的 floorEntry() 实现 O(log n) 范围查找：把累积权重当 key，选项当 value，一次二分就能定位。
- 必须预计算前缀和，不能边插边查；插入新选项需重建整个 TreeMap
- key 必须是
long或double，但推荐long（避免浮点精度导致floorEntry()找错区间） - TreeMap 的 key 不能重复，所以累积权重必须严格递增——哪怕两个选项权重为 0，也要保证 key 唯一（例如用索引补位）
怎么构建带累积权重的 TreeMap<Long, T>
关键不是存“权重”，而是存“右边界”。比如选项 A 权重 3、B 权重 5、C 权重 2，对应累积数组是 [3, 8, 10]，TreeMap 应存：{3=A, 8=B, 10=C}。抽取时生成 [1, 10] 内随机 long，用 floorEntry(randomValue) 拿到最接近且不大于它的 entry。
- 随机数下界是
1，不是0：因为权重为 0 的选项本就不该被抽中，nextLong(totalWeight)返回[0, totalWeight)，要 +1 对齐左闭右闭语义 - 用
nextLong(totalWeight) + 1，而非nextInt()：避免 int 溢出（总权重大于Integer.MAX_VALUE很常见） - 构建时用
new TreeMap<>()即可，别用ConcurrentSkipListMap：它不支持floorEntry()的强一致性语义，且并发写入仍需外部同步
Map<Long, String> weightedMap = new TreeMap<>();
long sum = 0;
for (var item : items) {
sum += item.weight;
weightedMap.put(sum, item.value);
}
// 抽取：
long rand = random.nextLong(sum) + 1;
String result = weightedMap.floorEntry(rand).getValue();
floorEntry() 返回 null 怎么办
只会在 rand < 1 或 weightedMap 为空时发生。前者不可能（因为 rand = nextLong(sum) + 1，最小为 1），后者是逻辑错误。真正要防的是：sum == 0 时 nextLong(0) 抛 IllegalArgumentException。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 构建前必须校验
totalWeight > 0，否则直接抛IllegalStateException，别等运行时崩 - 如果业务允许“零权重选项存在”，构建 TreeMap 前应先过滤掉权重 ≤ 0 的项，而不是给它们分配 key=0
- 不要用
ceilingEntry()回退：它可能跳过第一个区间，导致分布偏移
比 ArrayList + 线性扫描快多少
实测 1000 个选项时，TreeMap 查找 P99 耗时约 50ns，ArrayList 线性扫描约 300ns；到 10000 个选项，前者仍稳定在 60ns，后者升至 3μs 以上。但注意：TreeMap 构建开销比 ArrayList 大 3–5 倍，所以适用于“构建一次、反复抽取”的场景。
- 如果权重频繁变更（如实时竞价中每毫秒更新），宁可用数组+二分搜索（
Arrays.binarySearch()），自己维护前缀和数组，避免 TreeMap 的对象创建和树平衡开销 - Java 17+ 可考虑
TreeMap.tailMap(key, true).firstEntry()，但语义等价于floorEntry()，无实际优势 - 别为了“看起来高级”而用 TreeMap：只有当选项数 ≥ 50 且抽取频次高时，log n 才真有价值
最易被忽略的一点：累积权重的类型必须和随机数类型严格一致。用 long 累加却用 nextInt() 生成随机数，或者反过来，会导致范围错位、永远抽不到末尾项——这种 bug 在压测时才暴露，但原因极难定位。
