UV统计不宜直接用ConcurrentHashMap，因其需存储完整用户ID导致内存开销大、GC压力高，且size()不准确、computeIfAbsent易引发无效对象分配；BitMap适用于ID可映射为可控范围非负整数的场景，否则误判率高；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<string boolean></string>约占用850MB，而ConcurrentHashMap<string boolean></string>配new ConcurrentHashMap(1初始容量 + <code>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，再加定时落盘去重校验。
