BitSet比HashSet更省内存，因其用1位表示一个非负整数是否存在，如标记[0,1000000)只需约125KB；但仅支持非负整数，索引即值，适用ID范围可控场景，不适用于字符串、负数或超大跨度数据。
BitSet 为什么比 HashSet 节省内存（尤其在稀疏大整数场景）
因为 BitSet 不存实际值，只用 1 bit 表示一个非负整数是否存在。比如标记 [0, 1000000) 中哪些数出现过，HashSet<Integer> 至少要存 100 万个 Integer 对象（每个约 16 字节 + 哈希表开销），而 BitSet 只需约 125 KB 内存（10⁶ ÷ 8）。
但注意：它只支持非负整数，且逻辑上“索引即值”——bitSet.set(100) 表示“数字 100 存在”，不是“第 100 个位置”。这是最容易混淆的点。
- 适用场景：日志去重（用户 ID 是递增 long）、布隆过滤器底层、权限位标记、IP 归属地索引等整数 ID 映射明确、范围可控的场景
- 不适用：字符串去重、负数、浮点数、ID 分散且跨度极大（如
Long.MAX_VALUE级别）——会直接 OOM 或浪费巨量空闲位 -
BitSet.length()返回的是最高位的索引 + 1（即“逻辑长度”），不是实际分配的字节数；BitSet.size()才是内部数组长度（单位是 long，即 64 位一组）
set() / get() / cardinality() 这三个方法怎么配合做去重计数
去重本质就是“设位 + 统计已置位数量”。关键不是存数据，而是判断某位是否已被设过。
典型误用：bitSet.set(x); count++ —— 这会重复计数。正确做法是先 get(x) 判断，再决定是否 set 并累加：
立即学习“Java免费学习笔记（深入）”；
if (!bitSet.get(userId)) {
bitSet.set(userId);
uniqueCount++;
}
-
bitSet.get(i)对越界索引（i >= bitSet.length()）返回false，不会抛异常，但可能掩盖逻辑错误（比如误把负数传进来，被转成大正数） -
cardinality()是 O(n) 扫描内部 long 数组，比手动维护uniqueCount慢；高频更新时建议自己计数 - 如果只是最终统计去重数，用
cardinality()更安全（避免并发或漏更新导致计数偏差）
BitSet 在多线程下直接用会出什么问题
它不是线程安全的。set(i) 和 get(i) 都是普通实例方法，没有同步机制。并发调用可能导致位丢失或计数错乱。
- 常见错误现象：明明插入了 1000 个不同 ID，
cardinality()却返回 997 或更小；或者get(x)偶尔返回false即使之前set(x)过 - 不要用
synchronized(bitSet)包裹所有操作——锁粒度太粗，吞吐暴跌 - 轻量级替代：用
java.util.concurrent.ConcurrentHashMap<Integer, Boolean>（内存稍高但语义清晰）；或按 ID 哈希分片，每片配一个BitSet+ 分段锁 - JDK 12+ 的
BitSet仍无并发版本，别指望“未来会加”——它设计初衷就是单线程高性能位操作
和 Redis Bitmap、RoaringBitmap 比，Java BitSet 适合什么阶段
它只适合单机、内存充足、ID 范围明确、不需要持久化或跨进程共享的场景。一旦数据量超几百 MB 或需要分布式协作，就该换工具了。
- Redis
SETBIT：适合服务间共享去重状态，但网络延迟和序列化开销明显；BitSet零拷贝、纳秒级访问 - RoaringBitmap：当数据“既有密集块又有稀疏点”（比如用户活跃天数：连续几天 + 隔几个月一次），它比
BitSet内存省 5–10 倍，且支持交并差运算；但 API 更重，引入额外依赖 - 别拿
BitSet去接 Kafka 流或 MySQL 全量 ID——没压缩、没序列化协议、没扩容策略，出问题很难 debug
真正要用好 BitSet，得先想清楚：这个“海量”到底是 10⁵、10⁷ 还是 10⁹ 级别？ID 是否真的能映射到连续/半连续整数空间？上线后有没有人会突然喂进负数或超大 long？这些边界比怎么写 set 循环重要得多。
