BitSet比boolean[]省内存因用1bit存布尔值，而boolean[]按字节对齐致空间放大8倍；适合稀疏布尔标记，但get/set略慢、不支持泛型；底层为long[]，扩容翻倍，初始化建议预设大小；遍历用nextSetBit()高效跳零；跨系统需注意字节序与padding。
BitSet 为什么比 boolean[] 节省内存
因为 BitSet 每个 bit 存一个布尔值，而 boolean[] 在 JVM 中通常按 byte 对齐（至少 1 字节/元素），实际空间放大 8 倍。比如存 100 万个开关状态，boolean[1_000_000] 占约 1MB，BitSet 只要约 125KB。
但要注意：这不是免费午餐——BitSet 的 get/set 是位运算 + 数组索引，比数组直接寻址略慢；而且它不支持泛型、不能直接用在集合流式操作里。
- 适合场景：大量稀疏布尔标记（如用户 ID 是否活跃、IP 是否封禁、日志中事件是否发生）
- 不适合场景：需要频繁随机写入+遍历混合操作、或对单次访问延迟极度敏感的实时路径
- 底层是
long[]，所以实际容量按 64 的倍数向上取整；size()返回的是内部数组长度（单位：bit），不是已设置位数
如何正确初始化和扩容 BitSet
BitSet 默认构造函数创建空实例，内部数组长度为 0；首次 set 时才分配第一个 long（64 bits）。它会自动扩容，但扩容策略是翻倍（类似 ArrayList），所以如果提前知道最大位索引，建议用 new BitSet(int) 预设大小。
常见错误：用 new BitSet(n) 以为能存 n 个元素，其实参数是「预估位数」，不是数组长度。例如 new BitSet(100) 表示最多可能用到第 100 位（索引 0~99），内部初始 long 数组长度为 2（128 bits）。
立即学习“Java免费学习笔记（深入）”；
- 设定位：用
set(int index)，index 从 0 开始；越界不会报错，会自动扩容 - 清空位：用
clear(int index)，不是set(index, false)（后者效率低且语义不清） - 避免反复 set/clear 同一范围：先
clear()再批量set()，比逐个操作快得多
遍历已置位的索引（不是遍历所有位）
别用 for-loop 从 0 到 length() 硬扫——当数据稀疏时，时间复杂度炸掉。要用 nextSetBit(int fromIndex) 迭代：
int i = bs.nextSetBit(0);
while (i != -1) {
System.out.println(i);
i = bs.nextSetBit(i + 1);
}
这个方法跳过所有 0，只返回下一个 1 的位置，内部利用 long 的 bitCount 和 Long.numberOfTrailingZeros 加速。
-
length()返回的是「最高位 1 的索引 + 1」，不是总容量；未设置过的高位不计入 -
cardinality()才是真正已置位的数量，O(n) 时间，慎在 tight loop 里调用 - 如果需要倒序遍历，没有内置方法，得自己从
length()-1往下 scan，性能差很多
与 Redis 或数据库位图协同时的坑
Java BitSet 序列化后是 JVM 特定格式，不能直接丢给 Redis 的 SETBIT 或 PostgreSQL 的 varbit。跨系统交互必须转成标准字节数组，并注意字节序和位序。
典型错误：把 BitSet.toByteArray() 直接当 raw bitmap 发给 Redis，结果高位低位颠倒、或者末尾 padding 导致解析错位。
-
toByteArray()返回的是小端字节序，每个 byte 内部是 LSB 在前（即 bit 0 是最低位），符合大多数位图协议 - 但 Redis 的
GETBIT key offset中 offset 是全局 bit 偏移，和BitSet.get(offset)对齐，这点可以直连 - 若需紧凑传输，记得用
BitSet.length()截断无效 padding；否则toByteArray()可能多出全零字节
位图看着简单，但位序、字节序、padding、自动扩容这四点只要漏一个，线上就容易出现“明明 set 了却 get 不到”或者“统计数量翻倍”的问题。
