布隆过滤器线程安全的关键是仅对位数组的写操作加锁，因位数组是唯一可变共享状态，哈希计算无状态可并发；推荐用私有锁对象或锁位数组本身，避免锁整个实例或仅锁哈希过程。
布隆过滤器（Bloom Filter）本身是概率型数据结构，设计上不支持删除，且标准实现是只读或单线程写入。它由一个位数组（bit array）和若干哈希函数组成，多个线程并发写入时，若不做同步，会导致位翻转丢失、误判率异常升高，甚至彻底失效。
Java 中用 synchronized 实现跨线程安全写入，核心不是“给布隆过滤器加锁”，而是保护所有对共享位数组的修改操作——因为位数组是唯一可变的共享状态，而哈希计算本身无状态、可并发。
关键点：位数组是唯一需要保护的共享资源
标准布隆过滤器包含：
- 一个固定长度的
boolean[]或更省内存的long[]（按位操作）作为底层存储 - 一组独立哈希函数（如 MurmurHash3 + 模运算），仅读取输入、不修改任何状态
- 预设的容量（m）和哈希函数个数（k），初始化后不可变
只有对位数组执行 set(bitIndex) 操作会改变共享状态，必须互斥。
synchronized 的合理作用范围
不能只锁“某一次 set”，也不能锁整个对象实例（除非明确设计为单例共享）。推荐方式是：
-
锁位数组本身：例如
synchronized(bitArray) { ... }—— 简洁、语义清晰，且避免锁粒度太粗（比如锁 this）影响其他无关方法 -
或使用私有 final 锁对象：
private final Object writeLock = new Object();，然后在add()中synchronized(writeLock)—— 更可控，便于未来扩展（如分离读写锁） - 绝对不要只锁哈希计算过程：哈希函数无副作用，加锁纯属冗余
典型安全写入方法示例
以下是一个最小可行的线程安全 add() 实现（基于 long[] 位图）：
public class ThreadSafeBloomFilter {
private final long[] bits;
private final int numHashes;
private final HashFunction hashFn;
private final Object writeLock = new Object();
<pre class="brush:php;toolbar:false;">public void add(String item) {
// 多个哈希值可并行算，不加锁
for (int i = 0; i <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill8775" title="Java Maven Common"><img
src="https://img.php.cn/upload/skill/000/000/081/179222954019613.jpg" alt="Java Maven Common" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill8775" title="Java Maven Common" class="overflowclass">Java Maven Common</a>
<p class="overflowclass">Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。</p>
</div>
<a rel="nofollow" href="/xiazai/skill8775" title="Java Maven Common" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>注意：
- 每个
set操作单独加锁 → 避免多个线程同时改同一个long元素导致位丢失 - 没有在循环外加锁 → 否则会串行化全部 k 次哈希设置，大幅降低吞吐
- 若使用
boolean[]，同样需对bits[index] = true加锁，因 boolean 写入非原子（JVM 规范未保证）
为什么不推荐 synchronized 方法？
写成 public synchronized void add(...) 看似简单，但存在隐患：
- 锁的是当前实例（
this），若该对象被用于其他非布隆逻辑（如配置管理、统计计数），会造成意外阻塞 - 无法与外部读操作（如
mightContain）做读写分离——而布隆过滤器的contains是纯读，本可完全无锁 - 一旦后续想升级为
ReentrantReadWriteLock，重构成本高
补充：读操作通常无需加锁
mightContain() 只做位读取（(bits[longIndex] & (1L ），属于天然线程安全的“不可变访问”。只要位数组引用不变、且写入时保证可见性（<code>synchronized 块内写入自动刷新主内存），读线程总能看到已成功写入的位 —— 这正是 synchronized 提供的**可见性保证**。
总结：用 synchronized 实现布隆过滤器跨线程安全写入，本质是精准锁定位设置动作，而非包裹整个逻辑。锁得细、锁得准，才能兼顾正确性与并发效率。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
