BitSet 在数据量≥百万级且索引集中于非负整数区间时比 boolean[] 更快更省内存；小数据量下 boolean[] 更优，因 BitSet 有对象开销和位运算成本，而 boolean[] 内存连续、缓存友好。
BitSet 真的比 boolean[] 快且省内存吗？看场景
是，但只在数据量 ≥ 百万级、索引集中于非负整数区间（比如用户 ID 从 0 到 9999999）时成立。小数据量（如几百个开关）用 boolean[] 反而更快——BitSet 是对象，有创建开销、位运算跳转成本；而原生数组是连续内存，CPU 缓存友好。
内存节省是确定的：存 1000 万个布尔值，boolean[10_000_000] 至少占 10MB（JVM 每 boolean 实际占 1 字节），BitSet 只需约 1.25MB（10⁷ ÷ 8 ÷ 1024 ÷ 1024）。关键在于它把 8 个布尔值压进 1 字节，底层用 long[] 存储，每个 long 管 64 位。
- 别盲目替换：如果开关状态对应的是随机大整数（如用户 ID 是
Long值且跨度超 10⁹），或含负数，BitSet不适用——会因扩容失败或 OOM 崩溃 - 稀疏场景（比如只设了 100 个位，但最大索引是 10⁷）仍省内存，但遍历时不能用
for (int i = 0; i < bs.length(); i++)，否则扫 10⁷ 次 - 如果你需要键值映射（如
Map<String, Boolean>），BitSet无法直接替代——它只支持int索引
初始化和写入必须避开的三个硬坑
BitSet 的性能陷阱大多出在初始化和首次写入阶段。默认构造器 new BitSet() 只分配 64 位，第一次 set(1000000) 就触发扩容，后续再 set(5000000) 又扩，反复 realloc long[] 数组，吞吐骤降。
- 预估最大索引：一定用带参构造器，如
new BitSet(maxUserId + 1)（+1 防止maxUserId越界） - 写入统一用
set(int index)或clear(int index)，别用set(int index, boolean value)——传false时效率低于clear()，且语义模糊 - 流式写入优于批量收集：从数据库游标或文件逐行读取 ID 时，边读边
bitSet.set(id)，别先collect()到List<Integer>再循环——省中间对象、控内存峰值
怎么安全又高效地查状态和遍历已设位
get(int index) 不抛异常，越界（index < 0 或 index >= bitSet.length()）一律返回 false。这很危险：外部输入解析出负 ID 时，bitSet.get(-1) 静默返回 false，你以为“不存在”，其实是越界失效。
立即学习“Java免费学习笔记（深入）”；
- 安全检查必须显式写：
x >= 0 && x < bitSet.length() && bitSet.get(x) - 遍历已设位别硬扫：
for (int i = 0; i < bitSet.length(); i++)在稀疏时是 O(n)，应改用nextSetBit()：int i = bitSet.nextSetBit(0);<br>while (i != -1) {<br> // 处理 i<br> i = bitSet.nextSetBit(i + 1);<br>}这个循环只遍历真正为true的位，时间复杂度 O(k)，k 是置位数量 - 没有
contains()方法，自己封装一层纯属冗余——get()已是 JVM 内联的位运算，无调用开销
and/or/xor 运算和线程安全的真实代价
and()、or()、xor()、andNot() 全部原地修改调用方对象，且完全不加锁。多线程并发调用 a.and(b) 会导致结果错乱，甚至 ArrayIndexOutOfBoundsException（因内部 words 数组 resize 被中断）。
- 需要保留原值？必须先
clone()：BitSet result = (BitSet) a.clone(); result.and(b); - 必须并发写？用
synchronized(bitSet)包裹所有操作，或拆成多个分段BitSet+ 外部分段锁 -
andNot(b)是a = a & (~b)，不是“a 减 b”——b中为false的位对a无影响，这点常被误读 - 性能上，
or()比and()略快：前者遇到全 0 的long可跳过，后者必须逐位计算
真正容易被忽略的是：BitSet 的“极速”完全依赖你提前知道索引范围且能预分配容量。一旦运行时索引远超预期，扩容抖动和内存碎片会让它比 HashSet<Integer> 还慢。
