hashset不能直接用于高并发幂等校验，但可在单机、低频、短时本地去重场景中配合concurrenthashmap与原子操作安全使用；高并发应选redis setnx等分布式方案。
HashSet 本身不能直接用于高并发场景下的幂等性校验，因为它不是线程安全的集合。但在轻量、单机、低并发或**本地缓存+短时去重**类场景中，配合合理设计，它能作为幂等性前置校验的低成本手段——关键在于“怎么用”，而不是“能不能用”。
适用前提：明确边界，不越界使用
HashSet 只适合以下情况：
- 单 JVM 进程内、无分布式节点（如非集群部署的定时任务、后台管理端表单提交）
- 请求频率不高（例如每秒几十次以内），且校验 key 生命周期极短（如 1–5 秒）
- 允许极小概率失效（比如 GC 或内存压力导致缓存被清空，此时降级为无校验）
- 业务容忍“重复一次”的后果（如日志记录、通知触发），而非资金/订单等强一致性场景
正确用法：结合原子操作与生命周期控制
不能直接 new HashSet() 全局共享，也不能在多线程里裸用 add()。必须满足三点：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
用 ConcurrentHashMap + computeIfAbsent 构建线程安全的局部缓存容器，例如：
ConcurrentHashMap> requestCache = new ConcurrentHashMap();
SettokenSet = requestCache.computeIfAbsent("order", k -> Collections.newSetFromMap(new ConcurrentHashMap())); - 每次 add() 后必须检查返回值：只有返回 true 才代表首次见到该 token，可执行业务；返回 false 则立即拦截，避免后续逻辑重复运行
- 主动清理过期数据：不能依赖 GC。建议搭配 ScheduledExecutorService 定期扫描并移除创建超时（如 3 秒）的 tokenSet，或改用 Guava Cache / Caffeine 带自动过期的本地缓存
典型错误写法（务必避开）
这些看似简洁的做法，在并发下会直接失效：
-
static HashSet
globalTokenSet = new HashSet(); → 多线程 add 非原子，可能丢失、报 ConcurrentModificationException - if (set.contains(token)) { return; } set.add(token); → 存在竞态窗口：两个线程同时通过 contains 判断，都执行 add，重复通过
- 只用 add() 不看返回值 → 完全失去去重判断能力，和没加一样
- token 不带业务上下文（如用户ID+操作类型） → 全局 token 冲突，A 用户的 token 被 B 用户误判为重复
更推荐的替代方案（高并发首选）
当 QPS 超过百级、或系统已集群部署时，请放弃 HashSet，改用真正可靠的方案：
- Redis + SETNX（setIfAbsent）：原子写入，天然支持分布式，超时自动释放，是目前最主流选择
- 数据库唯一索引 + 插入前校验：适用于有主键/业务单号的写操作（如订单号唯一），失败后查库确认是否已存在
- 状态机 + 乐观锁更新：如订单状态从“待支付”→“已支付”，update where status=‘待支付’ and version=x，影响行数为 0 即说明已被处理
