Spring单例Bean中HashSet的线程安全与数据一致性问询

首先直接给你核心结论：你代码里的HashSet是非线程安全的，高并发场景下一定会出现数据丢失的情况，没法保证完整保存所有请求传入的值。

1. 高并发场景下的具体问题分析 #

你举的R1和R2同时调用的例子，最终结果大概率不是{"value1","value2"}，甚至可能出现更诡异的情况——比如集合大小是1但只存了其中一个值，或者内部结构损坏（比如链表成环，后续遍历抛出异常）。

为什么会这样？因为HashSet的add()方法不是原子操作，它的底层逻辑大概是：

• 先计算元素的哈希值
• 检查集合中是否已经存在该元素
• 如果不存在，就把元素加入数组/链表

当两个线程同时执行这几步时，可能会出现：

• R1和R2都检查到集合里没有自己要加的元素（因为对方还没完成添加）
• 然后其中一个线程的添加操作覆盖了另一个的，或者因为底层数组扩容时的并发操作导致元素丢失

所以哪怕R2获取实例时R1还没完成increment，最终也极大概率无法同时保存两个值。

2. 为什么ConcurrentHashMap不是合适方案？ #

你提到这个点很有意思——确实，如果你只是需要一个线程安全的集合来存唯一值，ConcurrentHashMap本身是键值对结构，虽然可以用ConcurrentHashMap.newKeySet()来得到一个线程安全的Set，但你说每个服务仅调用一次increment，这种场景下用ConcurrentHashMap确实有点“重”了，它的设计是为了高并发下的频繁读写，而你的场景几乎没有并发修改的持续压力，所以用更轻量的方案更合适。

3. 给increment方法加synchronized是否可行？ #

完全可行！而且是这个场景下非常合适的解决方案。

因为你的Spring Bean是单例的，给increment方法加上synchronized后，所有调用这个方法的线程都会排队执行，确保variableAddeds.add()操作的原子性和可见性——也就是说，每次只有一个线程能执行添加操作，不会出现并发冲突，自然也就不会丢失数据。

对于“每个服务仅调用一次”的场景，这个方案的性能开销几乎可以忽略不计，毕竟不会有大量线程长时间阻塞的情况，是性价比很高的选择。

另外，你也可以替换HashSet为线程安全的集合实现，比如Collections.synchronizedSet(new HashSet<>())，不过这个实现本质上也是在所有方法上加了同步锁，和你给increment加synchronized的效果类似，区别只是锁的范围（前者是整个集合对象，后者是单例Bean的方法），在你的场景下两者差异不大。

内容的提问来源于stack exchange，提问作者Blocfos