并发统计UV，HashSet、BitMap与LongAdder对比

本文深入剖析了高并发场景下UV（独立访客）统计的三种主流技术方案——ConcurrentHashMap、BitMap与LongAdder（辅以优化版UV_HashSet），直击实际落地中的关键痛点：ConcurrentHashMap因存储完整用户ID导致内存爆炸、GC频繁、size()不准及无效对象分配；BitMap虽高效但严重依赖ID可归一化为可控整数空间，误用hashCode映射将引发高误判，需谨慎选型与预估容量；而UV_HashSet通过复用Boolean.TRUE和分段并发机制，在保障精度的前提下将内存占用压缩至ConcurrentHashMap的十分之一以下。文章不仅厘清了各方案的适用边界与典型陷阱，更围绕“精度—内存—速度”三角权衡，为日活统计、实时风控等核心业务提供了兼具工程鲁棒性与性能极致的落地指南。

UV统计为什么不能直接用ConcurrentHashMap

因为UV本质是去重计数，ConcurrentHashMap存的是完整用户ID（比如UUID或手机号），内存开销大、GC压力高，1000万UV可能占几百MB堆内存；并发put还涉及锁分段或CAS重试，吞吐上不去。真正要的只是“这个ID来过没”，不是“把它存下来”。

常见错误现象：ConcurrentHashMap.size()在高并发下不准——它不加锁统计，返回的是估算值；有人误用computeIfAbsent反复构造对象，触发无谓对象分配。

• 场景：日活/小时活统计、实时风控中的设备去重
• 关键取舍：精度（是否允许极低概率误判） vs 内存 vs 速度
• BitMap适合固定ID空间（如用户ID是连续整数），UV_HashSet和LongAdder则面向离散字符串ID

BitMap在UV统计中怎么用才不翻车

BitMap高效的前提是ID能映射成非负整数且范围可控。比如用户表主键是long型自增ID，最大值1亿，那用RoaringBitmap（比原生java.util.BitSet更省内存）只要约12MB；但如果ID是UUID或手机号，强行转hashCode()会撞桶，误判率飙升。

容易踩的坑：BitSet.get(i)对超限索引静默返回false，不报错，导致漏统计；RoaringBitmap.add(负数)直接抛IllegalArgumentException。

• 必须做ID归一化：用Math.abs(id.hashCode()) % MAX_SIZE不如用Murmur3Hash32再& (size-1)（确保size是2的幂）
• 线上务必预估峰值UV，避免BitMap扩容（RoaringBitmap扩容是拷贝全量数据）
• 不要拿BitMap当唯一凭证——布隆过滤器（BloomFilter）更适合做“是否存在”判断，BitMap更适合“确定存在且范围已知”

UV_HashSet为什么比ConcurrentHashMap省内存

核心在于复用java.util.HashSet底层的HashMap结构，但把value统一设为Boolean.TRUE（静态常量），避免每个entry都new一个对象；再配合ConcurrentHashMap的分段写入能力，做到线程安全+低内存。

实测对比：1000万随机UUID，ConcurrentHashMap约占用850MB，而ConcurrentHashMap配new ConcurrentHashMap(1初始容量 + loadFactor=0.75，压到约420MB——省了一半，但仍是BitMap的30倍以上。

• 参数差异：initialCapacity建议设为预估UV的1.3倍，避免rehash；concurrencyLevel（旧版）或CPU核数（新版）影响分段数，太高反而增加CAS失败率
• 注意containsKey()和putIfAbsent(key, TRUE)的原子性差异：后者才是“有就跳过，没有才记”，前者+手动put不是原子的
• 如果业务允许少量重复（比如UV误差ConcurrentSkipListSet替代，写性能略低但遍历有序，方便后续聚合

LongAdder只适合UV中间态计数，别直接当UV结果

LongAdder快是因为它把累加分散到多个cell上，避免单点竞争，但它统计的是“调用次数”，不是“去重后数量”。你不能靠它算UV——除非前面已经用BitMap或HashSet筛过一遍，只把“新用户”才发给LongAdder加1。

典型误用：if (!set.contains(id)) { set.add(id); counter.increment(); }里counter用LongAdder是对的，但有人把set换成ConcurrentHashMap又用LongAdder，结果发现UV虚高——因为contains和add之间有竞态窗口，两个线程同时判断“不存在”，都进了increment()。

• 正确姿势：先用线程安全集合完成去重逻辑（比如putIfAbsent返回null才increment），LongAdder只负责最后一步计数
• 性能影响：LongAdder.sum()需要遍历所有cell，高并发下可能比AtomicLong.get()慢，别在高频读场景频繁调用
• 兼容性：Java 8+才有，Android需注意API Level（API 24+）

真正难的不是选哪个组件，而是想清楚你的ID分布、误差容忍度、内存预算这三点。比如日志系统采样率1%，那用布隆过滤器+LongAdder就够了；要是支付系统要精确UV，就得老老实实用ConcurrentHashMap，再加定时落盘去重校验。

好了，本文到此结束，带大家了解了《并发统计UV，HashSet、BitMap与LongAdder对比》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！