HashSet 白名单校验核心优势是 O(1) 平均查找性能，需预加载不可变集合、标准化输入、只读场景线程安全，万级数据优先用 HashSet 而非布隆过滤器。
HashSet 实现白名单校验的核心优势在于 O(1) 平均时间复杂度的 contains() 查找，适合高频、低延迟的判断场景。关键不在“怎么用”，而在“怎么用对”——包括初始化时机、数据一致性、线程安全和内存权衡。
白名单数据应预加载到 HashSet，避免运行时重复构造
每次校验都 new HashSet() 或反复 add() 会浪费 CPU 和内存。正确做法是：在应用启动或配置更新时一次性构建不可变集合。
- 使用
Set.of("a.com", "b.org", "api.example.com")（Java 9+）创建不可变 Set，再传入 HashSet 构造器（如需后续可变） - 若白名单来自配置文件或数据库，建议封装为单例 Bean（Spring 中用 @PostConstruct 初始化），并监听配置变更后重建实例
- 避免在 for 循环或请求处理中反复调用 new HashSet(list)
校验前统一标准化输入，避免大小写、空格、协议头等导致误判
白名单通常存的是规范域名（如 "example.com"），但输入可能是 "EXAMPLE.COM"、" https://example.com " 或 "example.com/"。直接 contains() 会失败。
- 标准化建议：转小写 + 去首尾空格 + 提取 host（用 URL 或 URI 解析，而非 substring）
- 示例：
String host = new URL(input).getHost().toLowerCase().trim(); - 若白名单本身含通配符（如 "*.example.com"），HashSet 不适用，需换用 Trie 或正则预编译——此时 HashSet 仅适合精确匹配
高并发场景下注意线程安全，但别盲目加锁
HashSet 本身非线程安全，但白名单集合一旦构建完成就只读，contains() 是安全的，无需同步。
- 只要确保初始化完成后不再调用 add/remove/clear，多个线程并发调用 contains() 完全没问题
- 若需运行时动态增删白名单（如运营后台实时开关），改用
ConcurrentHashMap.newKeySet()（Java 8+），它提供线程安全的 Set 接口且性能接近 HashSet - 避免用 Collections.synchronizedSet() —— 它对每个操作加全局锁，严重拖慢吞吐量
内存够用时优先用 HashSet，别过早优化成布隆过滤器
当白名单规模在几万以内、JVM 堆充足时，HashSet 简单、准确、无误判。布隆过滤器虽省内存，但有假阳性风险，且增加复杂度。
- 估算内存：10 万个 String（平均 20 字节），加上 HashSet 结构开销，约占用 5–10 MB 堆空间，通常可接受
- 只有当白名单达百万级、内存敏感（如嵌入式）、且能容忍极低概率误拦（false positive）时，才考虑 Guava 的 BloomFilter
- 切记：布隆过滤器不能替代 HashSet 做最终判定，只能作为快速“可能在白名单中”的前置过滤
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
