原生 map[uint64]bool 不能并发写入，因 Go map 非并发安全，多 goroutine 同时写必 panic；正确解法是分块位图：用 []uint64 存桶，每桶管 64 bit，配独立 Mutex，按 n>>6 定桶、n&63 定偏移，实现无冲突并发位操作。
为什么原生 map[uint64]bool 不能直接并发写入
Go 的 map 不是并发安全的，只要两个 goroutine 同时对同一个 map 做写操作（哪怕只是设 true），运行时大概率 panic 报 fatal error: concurrent map writes。这不是概率问题，是确定性崩溃 —— 只要触发条件满足，必崩。
常见错误写法：
var seen = make(map[uint64]bool)<br>go func() { seen[123] = true }()<br>go func() { seen[456] = true }()别指望加个
sync.Once 或只读不写就能绕过：只要存在任何写操作，就必须保护。
- 用
sync.Map？不行 —— 它适合「读多写少 + key 类型不确定」场景，但位图本质是密集整数索引，sync.Map的哈希+分段锁开销大，且不支持原子位操作 - 用
sync.RWMutex包裹普通map？可以但低效 —— 每次 set/check 都要锁整个结构，吞吐上不去 - 真正解法是分治：把大位图切块，每块配独立锁，写操作只锁对应块
用 sync.Pool + 分块 []uint64 实现高并发位图
核心思路：把 64 位整数当一个“桶”，每个桶管理 64 个 bit；用数组 []uint64 存所有桶，再用 sync.Mutex 数组按桶索引分锁。这样两个 goroutine 写不同桶（比如 bit 123 和 bit 456）完全不冲突。
关键计算：
- bit 位置 n 对应桶索引：n / 64（即 n >> 6）
- 在桶内偏移：n % 64（即 n & 63）
- 设置位：bits[idx] |= (1
- 桶数组长度建议预估：比如去重 10 亿 ID，最大 ID 是
1e9，需要(1e9 + 63) / 64 ≈ 15.6M个uint64，约 125MB 内存 - 锁数组大小建议和桶数一致，或取其平方根（如 1024 锁管 1M 桶），避免锁竞争又不过度分配
- 不要用
sync.Pool复用整个位图 —— 它适合短期对象，位图生命周期通常贯穿业务流程，复用反而导致状态残留
atomic 能否替代锁？看场景
如果只做「设置位」（set）且不关心返回旧值，可以用 atomic.Or64 直接操作单个 uint64 桶，完全免锁。但注意：
- atomic.Or64(&bits[idx], 1 是安全的<br>
- 但 <code>Get() 判断是否已存在，需读取后与掩码做 & 运算：(atomic.LoadUint64(&bits[idx]) & (1
- 优势：零锁，超高吞吐，适合「只写不查」或「查之前已确保写过」的场景（如日志去重）
- 坑点：Go 1.19+ 才支持
atomic.Or64；低于此版本只能手写汇编或退回到 mutex 分块 - 不适用场景：需要 CAS（如「如果未存在则设」）、需要统计当前位数、或需要清零某 bit —— 这些必须用锁保原子性
内存布局和扩容怎么不拖慢性能
位图一旦初始化，就应尽量避免动态扩容。每次 append 底层数组都会触发 realloc + copy，而并发中 copy 过程若被其他 goroutine 访问，极易读到中间态（部分旧数据、部分新数据）。
- 初始化时就按最大可能 bit 位申请：用
make([]uint64, size)，不是make([]uint64, 0, size)—— 后者仍会触发首次写入扩容 - 如果 ID 范围不可预估（如 hash 后的 uint64），用布隆过滤器预筛 + 小位图分片组合，别硬扛全量
- 测试时重点压测「高位 bit 写入」：比如总长 1M 桶，专写第 999999 个桶，确认锁和内存访问没越界
最易被忽略的是 cache line 伪共享：多个高频访问的桶如果落在同一 cache line（通常是 64 字节 = 10 个 uint64），会导致 CPU 核心间频繁同步该 line。解决方案是桶之间填充 padding，或让锁粒度略大于单桶（如每 8 桶共用一把锁）。
立即学习“go语言免费学习笔记（深入）”；
