IntFunction 作为哈希映射桥梁，将输入转为 int 索引供位运算使用；其设计影响哈希均匀性与误判率，需配合安全取模或位运算适配数组长度，并避免 Math.abs 等低效写法。
IntFunction 在构建本地内存布隆过滤器时，本身不直接参与位运算，但它常被用作哈希值映射的“函数式桥梁”——把原始输入（如 String、Long）转为 int 类型的哈希索引，再交由位运算逻辑处理。真正起性能作用的是后续对 BitSet 或自定义位数组的位操作，而 IntFunction 的设计质量直接影响哈希分布均匀性与计算开销，间接决定位数组利用率和误判率。
为什么用 IntFunction 而不是直接写哈希逻辑？
使用 IntFunction<T> 接口（如 IntFunction<String>）能解耦哈希计算与布隆过滤器主逻辑，便于：
- 替换不同哈希策略（MurmurHash3、xxHash、Objects.hash）而不改核心代码
- 复用预编译的 lambda 表达式，避免每次调用都新建对象
- 配合 Stream 或并行初始化批量加载数据，提升构建吞吐
关键优化点：哈希输出必须适配位数组长度
布隆过滤器要求所有哈希结果落在 [0, m) 范围内（m 是位数组总长度）。若直接用 hash % m，负数哈希会引发越界或错误位置。推荐组合方式：
- 用
IntFunction封装安全取模：index -> ((hash.applyAsInt(item) % m) + m) % m - 更优做法是用位运算替代取模：当 m 是 2 的幂时（如 1 hash & (m - 1)，零开销且线程安全
- 建议在构造 BloomFilter 时强制要求 m 对齐 2 的幂，并在文档中明确约束
位运算落地：从 IntFunction 输出到 BitSet 操作
IntFunction 只负责生成 int 索引，真正的位操作由底层完成。典型链路如下：
立即学习“Java免费学习笔记（深入）”；
- 获取索引：
int idx = hashFunc.applyAsInt(item) & (bitSetSize - 1); - 定位 long 单元：
int wordIndex = idx >>> 6;（等价于 idx / 64） - 计算位偏移：
int bitOffset = idx & 63;（等价于 idx % 64） - 置位：
words[wordIndex] |= (1L - 查位：
((words[wordIndex] >>> bitOffset) & 1) == 1
实战避坑提醒
常见低效或错误写法：
- 用
Math.abs(hash % m)—— abs 无法修复负数取模偏差，且有分支判断开销 - 每次查询都 new 一个 IntFunction 实例 —— 建议作为 final 字段复用
- 忽略哈希种子多样性：单个 IntFunction 不足以支撑 k 个独立哈希，应封装为
IntFunction<String>[] hashers数组，每个带不同 seed - BitSet.set(idx) 内部虽已优化，但频繁小范围调用仍不如批量 flip 或 and 操作 —— 高并发初始化时可先收集索引再批量设置
