bitset可实现极低内存、o(1)查询、高吞吐去重，内存=⌈maxid/64⌉×8字节（如id∈[0,10⁶)约122kb），但仅适用于非负整数且范围可控场景；稀疏、超大跨度或并发场景应改用roaringbitmap。
做不到“近乎零内存开销”，但可以用 BitSet 实现**极低内存、O(1) 查询、高吞吐去重**——关键不在“零开销”，而在**精准预估+规避陷阱+合理替代**。
明确内存开销底线：不是零，但可精确估算
BitSet 内存 = ⌈最大可能 ID / 64⌉ × 8 字节（一个 long 占 8 字节）。
例如：若数据 ID 范围是 [0, 999_999]，最多需 ⌈10⁶/64⌉ = 15625 个 long → 约 122 KB；
若 ID 达 10 亿（1e9），则需 ⌈1e9/64⌉ ≈ 15.6M 个 long → 约 122 MB。
这不是“开销”，而是**确定性成本**：只要知道数据范围上限，就能算准，不随实际数据量线性增长（只和 maxID 相关）。
- 别用
bitSet.size()估算内存 —— 它返回的是内部 long[] 长度 × 64，含大量未使用的高位 - 真正有效容量看
bitSet.length()（最高已设置位索引 + 1），但它也不等于业务数据量 - 若 ID 稀疏（比如只用了 1000 个离散大数），BitSet 仍要分配整块数组 → 此时它就不是最优解
高频在线检索：get/set 必须快，但得防越界和线程撕裂
bitSet.get(i) 和 bitSet.set(i) 是纯位运算，确实 O(1)，但有隐藏风险：
-
负数传入会转成极大正数：如
bitSet.set(-1)实际等价于set(0xffffffffffffffffL)，可能触发 OOM 或静默写错位置 -
越界不报错，只返回 false：比如
i ≥ bitSet.length()时get(i)永远返回false，容易掩盖逻辑错误（如 ID 解析异常） -
非线程安全：并发 set/get 可能丢失更新，cardinality() 统计失真 —— 多线程必须加锁或改用
ConcurrentHashMap<integer boolean></integer>（小数据）或RoaringBitmap（大数据）
去重逻辑要自己兜底，别依赖 cardinality()
高频插入场景下，bitSet.cardinality() 是 O(n) 扫描整个 long 数组，比维护一个原子计数器慢得多：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 推荐模式：
if (!bitSet.get(id)) { bitSet.set(id); uniqueCount.incrementAndGet(); } - 仅在最终统计阶段用
cardinality()校验（避免并发漏更新导致偏差） - 注意：clear() 后计数器要重置，BitSet 本身不清除计数
真海量时，BitSet 不是答案，RoaringBitmap 才是
当 ID 超过千万级、分布稀疏、或需交并差/序列化/跨进程共享时，BitSet 会迅速暴露短板：
- 不支持 long ID 原生存储（需手动偏移，如
id ^ 0x8000000000000000L） - 无法压缩稀疏区间（比如只存 1、1000000、999999999，BitSet 仍占 ~125MB）
- 无内置并发控制、无内存映射、无 Spark/Flink 集成能力
换成 RoaringBitmap：
RoaringBitmap rb = new RoaringBitmap();<br>rb.add(1_000_000_000); // 安全，内存按实际数据块增长<br>rb.contains(1_000_000_000); // O(log n) 但实测仍快于 HashMap 查找
它把数据按 16-bit 分块（0–65535、65536–131071…），每块用 bitmap 或 array 存储，兼顾密集与稀疏场景。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
