BitSet.cardinality() 是 Java 中最直接、最高效的统计方法，它返回当前 BitSet 中置为 true 的位数。无需手动遍历，也不依赖外部库。

cardinality() 的行为和边界条件

该方法内部使用稀疏位计数优化（如分段查表 + Long.bitCount），时间复杂度接近 O(1) —— 实际是 O(有效字长数)，但对绝大多数场景可视为常量级。注意以下几点：

• 空 BitSet（未 set 任何位）返回 0
• 即使高位索引很大（如 set(1_000_000)），只要中间全为 false，cardinality() 仍只统计真实置位数，不扫描整个范围
• 调用前无需 trimToSize()：该方法本身已跳过未分配的 word 段
• 线程不安全：多线程并发修改时需同步，否则结果可能不一致

与手动遍历的性能对比

手动用 nextSetBit() 循环或 get(i) 遍历不仅代码冗长，还显著拖慢执行速度。例如：

// ❌ 不推荐：O(n) 全量扫描，n 是最大索引+1
int count = 0;
for (int i = 0; i < bs.length(); i++) {
    if (bs.get(i)) count++;
}

// ✅ 推荐：O(实际置位块数)，快一个数量级以上
int count = bs.cardinality();

尤其当 BitSet 稀疏（如只在索引 10000 和 200000 处设 true）时，cardinality() 几乎瞬时返回，而手动循环要检查 20 万次。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

立即学习“Java免费学习笔记（深入）”；

常见误用：混淆 length() 和 cardinality()

BitSet.length() 返回的是「最高置位索引 + 1」，不是 true 个数；它甚至可能大于实际容量（因内部数组未压缩）。典型错误：

• 误以为 bs.length() == bs.cardinality() → 实际上前者是“逻辑长度”，后者才是“真值个数”
• 用 bs.size()（返回内部 long[] 容量）来估算 true 位数 → 完全无关，该值通常远大于真实置位数
• 在未 set 任何位时调用 bs.length() 返回 0，但 cardinality() 同样是 0，二者此时巧合相等，不可推广

真正需要关心的只有 cardinality() —— 它不撒谎，不近似，且 JVM 已深度优化。唯一要注意的是：确保你操作的是同一个 BitSet 实例，别在并发写入时漏加锁。