bitset底层使用long[]数组而非泛型数组，因其绕开java泛型擦除限制，避免装箱开销与空间浪费；每个long存64位，索引i映射到words[i>>6]的i&0x3f位，通过位运算高效操作。

Java 中 BitSet 的底层 long[] words 并不是泛型数组，也不涉及泛型数组的转换过程。这一点需要先明确——BitSet 从设计之初就完全绕开了泛型数组的限制与复杂性。

BitSet 为什么不用泛型数组？

Java 的泛型在编译期被擦除（type erasure），而泛型数组创建在运行时是非法的。例如以下代码会编译失败：

T[] arr = new T[10]; // ❌ 编译错误：generic array creation

BitSet 若试图用类似 E[] 或 Boolean[] 实现位存储，不仅空间爆炸（每个 Boolean 对象至少 16 字节+对象头），还会彻底失去位图的核心价值：极致紧凑 + 位级原子操作。所以它反其道而行之，直接使用原始类型数组 long[]，彻底规避泛型机制。

long[] words 是怎样承担“位数组”职责的？

• 每个 long 占 64 位 → 可表示 64 个布尔状态；
• 索引 i 对应的位，落在第 i >> 6（即 i / 64）个 long 元素中，偏移量为 i & 0x3F（即 i % 64）；
• 设置第 i 位：words[wordIndex] |= (1L ；
• 查询第 i 位：(words[wordIndex] & (1L ；

这个映射关系完全由整数位运算驱动，和泛型无关，也不依赖任何类型参数。

Password Generator Pro

使用 Python secrets 模块生成安全随机密码，支持自定义长度和字符集。

下载

那 BitSet 类声明里的 <e></e> 呢？

BitSet 没有泛型参数。它的类签名是：

public class BitSet implements Cloneable, Serializable

它不属于 Java 集合框架（没实现 Collection<e></e>），也不参与泛型体系。这是有意为之的设计隔离——它是一个专用的、面向位操作的工具类，而非通用容器。

对比：如果强行套用泛型会怎样？

假设有人想封装一个 BitSet<t></t>，比如用 T 表示“被标记的元素类型”：

• 无法避免 T 必须可哈希、可比较，还要映射到非负整数索引（BitSet 只接受 int 下标）；
• 最终仍得把 T 转成 int（如 t.hashCode() & 0x7FFFFFFF），再定位到 long[] 中某一位；
• 这层转换逻辑不在 words 数组里，而在使用者代码中；words 本身始终只是 long[]，干净、固定、无类型负担。

---

所以结论很清晰：
BitSet 的 long[] words 是面向位运算优化的原始数组设计，它主动放弃泛型抽象，换来的是确定性内存布局、零装箱开销、可预测的缓存友好性。这不是妥协，而是精准取舍。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南