BitSet 不适合海量数据过滤，因其底层为 long[] 数组，不支持负数、无法稀疏存储、最大索引受限且易 OOM；适用于小范围连续非负整数场景，如小时、状态码等。
BitSet 为什么不适合直接用在海量数据过滤场景
Java 的 BitSet 底层是 long[] 数组，每个 bit 对应一个非负整数索引。它不支持负数、不能稀疏存储、最大索引受限于内存（约 Long.MAX_VALUE * 64，但实际远达不到——因为分配超大数组会 OOM）。你遇到的“过滤失败”或“内存爆掉”，大概率不是算法逻辑错，而是误把它当成了可伸缩的布隆过滤器或 RoaringBitmap 替代品。
常见错误现象：
- 对 10 亿级别 ID 做 set(id)，JVM 直接抛 OutOfMemoryError: Requested array size exceeds VM limit
- 用 BitSet.length() 误以为是“已设置位数”，其实返回的是最高位索引+1，中间大量 0 也会被计入容量
- 多线程并发调用 set() / get()，没加锁导致结果不可靠（BitSet 非线程安全）
什么时候能用 BitSet？明确的适用边界
适合场景非常窄：数据范围已知、连续、且上限可控（比如用户行为日志中「当天活跃小时」0–23、「HTTP 状态码」100–599、「枚举状态位」≤ 1024 种）。它快，是因为位运算零拷贝，不是因为它“能存海量”。
实操建议：
- 先算内存：n 个 bit ≈ n / 8 字节。1 亿 bit ≈ 12MB；10 亿 bit ≈ 125MB；但若最大 ID 是 10 亿，即使只设了 1000 个位，BitSet 仍要分配 ~125MB 数组
- 别依赖 size()：它返回的是内部 long[] 长度 × 64，和实际业务数据量无关
- 小范围才考虑复用：比如用 BitSet.clear() + BitSet.or() 做轻量级集合交并，比新建 ArrayList 快，但仅限几千~几万元素
替代方案选型：RoaringBitmap 是当前最现实的选择
如果你的真实需求是「对上亿 ID 做快速去重、交集、差集，并控制内存在百 MB 级」，RoaringBitmap 几乎是标准解。它把数据分块（chunk），每块用 bitmap 或 list 存储，稀疏时省内存，密集时保持位图效率。
关键差异点：
- 支持 long 类型 ID（需转为非负，比如 id ^ 0x8000000000000000L）
- RoaringBitmap.add() 不会触发大数组分配，插入 1000 万随机 ID 内存通常
- 原生支持序列化、内存映射、与 Spark/Flink 集成
- 注意：它不是 JDK 自带，需引入 org.roaringbitmap:RoaringBitmap 依赖
简单对比示例：BitSet bs = new BitSet(); bs.set(1_000_000_000); // OOM 风险高RoaringBitmap rb = new RoaringBitmap(); rb.add(1_000_000_000); // 安全
立即学习“Java免费学习笔记（深入）”；
如果硬要用 BitSet，必须绕开的三个坑
不是不能用，是得主动规避设计缺陷：
无序列表：
- 绝不直接用原始 ID 当索引：先做哈希压缩（如 Math.abs(id.hashCode()) % N），N 控制在 100 万以内，再配合布隆过滤器二次校验，否则就是给自己埋 OOM 雷
- 不要用 BitSet.stream() 遍历大集合：它会从 0 扫到 length()，哪怕只有最后 1 个 bit 被设，也要遍历几亿次
- 跨 JVM 或持久化时别存 raw BitSet：它的序列化格式不稳定，JDK 版本升级可能读失败；改用 toByteArray() + 自定义 header，或直接换 RoaringBitmap
真正难的不是写对代码，是判断“这个场景到底适不适合用位图”。BitSet 的名字太有迷惑性，它本质是个紧凑的布尔数组，不是大数据工具。
