布隆过滤器在Java算法题中专用于快速排除“肯定不存在”的元素，而非精确查找；它作为前置守门员，false结果100%可靠，true需二次验证，常与HashSet、空值缓存等组合使用以兼顾空间效率与准确性。
布隆过滤器在Java经典算法题中不是用来“精确查找”，而是用来快速排除——它专治那种“明知不存在却反复来问”的恶意穿透场景。比如题目给定10亿用户ID，再抛出100万个待查ID，要求在内存受限（比如仅几MB）前提下，100%识别出哪些肯定不在集合里，从而跳过后续无效处理。
布隆过滤器在算法题中的典型定位
它不参与最终结果计算，只做前置守门员：返回false表示“绝对不存在”，可直接丢弃；返回true表示“可能存在”，才交给HashSet、数据库或业务逻辑进一步验证。这种“宁可放过，不可错杀”的设计，正好契合算法题对空间效率和判断确定性的双重要求。
关键操作必须写对的三步
-
初始化要预设容量和误判率：不能用默认构造。例如Guava中写
BloomFilter.create(Funnels.stringFunnel(), 10000000, 0.01)，明确告诉系统预计存1000万字符串、容忍1%误判。拍脑袋设小了，误判飙升；设大了，浪费空间。 -
所有合法数据必须一次性灌入：题目若给出全量ID列表（如文件读取、数据库查询结果），必须在查询开始前全部调用
.put()。漏掉任意一个，它就变成“不存在的合法ID”，被误拦。 -
查询时只信
mightContain()的false结果：这是唯一100%可靠的结论。一旦返回true，绝不能直接认定存在，必须走后续校验逻辑——算法题里常要求你补上这一步，否则算逻辑错误。
常搭配的防御组合套路
单靠布隆过滤器拿不到满分。高频考法是让它和别的结构配合：
- 与
HashSet组合：布隆过滤器筛掉99%的非法请求，剩下1%再用HashSet精判——既控内存，又保准确。 - 与空值缓存联动：当布隆说“可能存在”、但实际查缓存/DB为空时，把该key连同
null一起缓存（带短TTL）。这样下次相同key来，直接返回空，不再穿透。 - 加基础校验兜底：比如ID字段必须是8–16位正整数，先用正则
^[1-9]\d{7,15}$过滤非法格式，再进布隆——避免哈希函数被畸形输入拖慢。
容易踩坑的几个硬约束
- 不能删元素：题目若涉及“注销用户”或“删除ID”，布隆里没法remove。标准解法是忽略删除动作，靠空值缓存+短TTL自然失效，或换用Counting Bloom Filter（但算法题极少要求这个，因空间翻倍）。
-
哈希函数必须独立均匀：自己手写多个哈希时，避免用
hashCode() % m这种易碰撞方式。Guava或RedisBloom内部已优化，直接用即可。 -
位数组大小不是随便定的：理论公式
m = -(n × ln(p)) / (ln(2)²)（n为容量，p为误判率）会算出最优bit数。实战中直接让库自动算，别手动填错单位（比如把字节当bit）。
