bitset比boolean[]节省8倍内存因其按位存储，1字节存8个布尔值；但存在线程不安全、无泛型、随机访问有位运算开销、大索引可能oom等问题。
BitSet 为什么比 boolean[] 节省 8 倍内存
因为 boolean 在 JVM 里实际占 1 字节（不是 1 bit），而 BitSet 真正按位存——每个 bit 存一个布尔值，8 个值才用 1 字节。如果你要存一千万个开关状态，boolean[10_000_000] 占约 10MB，BitSet 只要约 1.25MB。
但别急着全换：它不支持泛型、不能直接用 for-each 遍历、且随机访问的 get/set 操作有少量位运算开销。
-
BitSet内部用long[]存储，每次操作都要算下标（wordIndex = bitIndex >> 6）和位偏移（bitOffset = bitIndex & 0x3F） - 小数据量（比如几百个布尔值）时，
BitSet的对象头和数组初始化成本反而可能更高 - 多线程读写必须加锁——
BitSet本身不是线程安全的，ConcurrentHashMap那种无锁思路它没有
set() / get() 的边界行为容易踩空指针或越界
BitSet.set(int bitIndex) 如果 bitIndex 是负数，会直接抛 IndexOutOfBoundsException；但如果 bitIndex 很大（比如 2^31-1），它不会立即扩容失败，而是默默分配超大数组——可能触发 OOM 或卡顿。
更隐蔽的是：get(int bitIndex) 对未设置过的位返回 false，但不会自动扩容；而 set() 会自动扩容到覆盖该位所需的最小容量。
- 不要用
bitSet.get(i)配合i 来遍历——<code>length()返回的是“最高位为 true 的索引 + 1”，中间可能有大量 false 位没被统计 - 想安全遍历所有已置位的索引，用
bitSet.nextSetBit(0)循环，而不是从 0 到size() - 如果业务明确知道最大位宽（比如用户 ID 不超过 1 亿），初始化时指定容量：
new BitSet(100_000_000)，避免反复扩容
与 int / long 位运算混用时要注意符号扩展
当你把 BitSet 导出为字节数组（toByteArray()）或长整型数组（toLongArray()）做底层处理时，Java 的 byte 是有符号的——低位补零还是补一，取决于你是否做了掩码。
例如：bitSet.set(0); bitSet.set(7);，toByteArray() 返回 {(byte)0x81}，但直接打印 (byte)0x81 会显示 -127，不是 129。后续用 Integer.toBinaryString(b & 0xFF) 才能正确还原位模式。
-
toByteArray()返回的数组长度是(bitCount + 7) / 8，但高位字节可能全零——别假设长度等于逻辑位数 / 8 -
fromByteArray(byte[])会把每个byte当作低 8 位，高位字节在前（大端），和ByteBuffer.putLong()行为一致 - 如果要和 C/C++ 二进制协议对接，确认对方是否把字节数组当 little-endian 解析；Java 默认是 big-endian 存储
替代方案：EWAHCompressedBitmap 更适合稀疏场景
当你的布尔集合里 true 很少（比如百万位中只有几百个 1），BitSet 依然按 long[] 分块存储，浪费空间。EWAHCompressedBitmap（来自 RoaringBitmap 生态）用游程编码，能把连续 0 压缩成计数，内存可再降 10–100 倍。
但它不是 JDK 自带类，得引入 org.roaringbitmap:RoaringBitmap；而且压缩/解压有 CPU 开销——纯内存计算密集型场景可能变慢。
- 判断是否该换：如果
bitSet.cardinality() / (double) bitSet.size() -
BitSet.and()是原地操作，EWAHCompressedBitmap.and()返回新对象，注意 GC 压力 - RoaringBitmap 在 64K 以内整数范围有优化，如果位索引集中在 0–65535，它比 EWAH 更快更省
位运算的“省”是有代价的：你要清楚自己压的是内存、CPU 还是开发时间。BitSet 不是银弹，只是把位操作的包袱甩给了你自己。
