bitset比boolean[]省约8倍内存，因用long[]存bit且每long管64位；但仅在索引稀疏或连续大范围时有效，小范围离散索引反致浪费。
BitSet 的内存占用到底有多省？
它比 boolean[] 节省约 8 倍内存，因为底层用 long[] 存储，每个 long 管 64 个 bit；而 boolean[] 在 HotSpot JVM 中通常按 byte 对齐，哪怕只存 true/false，也至少占 1 字节。
但别急着全换——BitSet 的“省”是有前提的：位索引必须是稀疏或连续的大范围（比如 0～1 亿），如果只用其中几千个离散位置，反而可能因扩容和未使用空间浪费更多内存。
-
BitSet默认初始容量是 64，每次扩容翻倍（ensureCapacity会触发），频繁set(i)小索引再突然设一个超大索引（如i = 10_000_000），会直接分配约 156KB 的long[]（10M / 64 ≈ 156250 个 long） - 如果已知最大位索引，用
new BitSet(maxIndex + 1)预分配，避免多次扩容 - JVM 堆外内存不受影响，
BitSet完全在堆内；若数据量真到上十亿 bit，要考虑 GC 压力——单个 10 亿 bit 的BitSet占约 125MB 堆内存
set() 和 get() 在超大索引下为什么变慢？
不是算法复杂度问题（仍是 O(1)），而是 CPU 缓存局部性崩了。当 BitSet 底层数组极大（比如千万级 long 元素），随机访问两个相距很远的 bit，大概率触发多次缓存未命中，甚至缺页中断。
典型场景：用 BitSet 做布隆过滤器的底层存储，但 hash 后的位索引完全随机。
立即学习“Java免费学习笔记（深入）”；
- 避免用
BitSet.get(i)逐个扫描——改用nextSetBit(fromIndex)批量跳过 0 区域 - 如果必须随机读多写少，且索引有局部性（比如集中在某段），可拆成多个小
BitSet，用数组或 Map 管理，提升缓存命中率 - 注意
set(i, value)中i超出当前容量时，BitSet会默默扩容，不报错但可能引发意料外的内存突增
and()、or() 等批量操作为何有时卡住？
这些方法是同步的（synchronized 修饰），而且内部遍历整个底层 long[]，不做短路。两个 1 亿 bit 的 BitSet 做 and()，哪怕实际只有前 100 个 bit 是 1，它仍要算满全部 ~156 万个 long 元素。
更坑的是：如果其中一个 BitSet 被其他线程并发修改，and() 可能读到中间态，结果不可靠。
- 用
BitSet.clone()先复制再操作，避免污染原对象 - 对超大
BitSet，手动分块处理：按long数组下标切片，用ForkJoinPool并行计算每块的&或|，最后合并（注意边界对齐） - 别依赖
length()判断“有效长度”——它返回的是最高 set bit 的索引+1，不是实际容量；要用size()看底层long[]长度
替代方案：什么时候该放弃 BitSet？
当位图逻辑复杂（比如需要带版本、支持原子更新、跨进程共享），或者单实例突破 500MB，BitSet 就不再是“够用”，而是维护黑洞。
常见替代路径：
- 内存映射文件：
FileChannel.map()+ByteBuffer.asLongBuffer()，把位图落到磁盘，用虚拟内存管理，适合只读或低频写场景 - RoaringBitmap：对稀疏数据自动分块压缩，10 亿 bit 中只有 1% 置位时，内存可压到
BitSet的 1/10；Maven 依赖是org.roaringbitmap:RoaringBitmap - Redis Bitmap：把压力转给服务端，客户端只发
SETBIT、BITCOUNT命令，适合分布式去重、用户行为标记等
真正难的不是选哪个工具，而是想清楚“海量”具体指什么——是总位数大？活跃位少？还是并发高、一致性要求严？没对齐这点，换啥都救不了。
