ConcurrentHashMap 是多线程环境下替代 HashMap 的首选,通过分段锁(JDK7)或 CAS+synchronized(JDK8+)保障并发安全,读操作无锁;computeIfAbsent 支持原子化懒加载;需过期功能应选 Caffeine 而非手动实现。

用 ConcurrentHashMap 替代 HashMap 是最直接有效的做法
普通 HashMap 在多线程写入时会触发扩容导致死循环(JDK 7)或数据丢失(JDK 8+),而 ConcurrentHashMap 通过分段锁(JDK 7)或 cas + synchronized(JDK 8+)保证了读写并发安全,且读操作完全无锁。
- 不需要额外加锁,
putIfAbsent、computeIfAbsent等方法本身就是原子的 - 避免用
Collections.synchronizedMap包裹HashMap:它只是给每个方法加了全局锁,吞吐量差很多 - 注意
size()返回的是估算值,高并发下可能不准;如需精确计数,改用mappingCount()
computeIfAbsent 是实现“懒加载缓存”的关键方法
它在键不存在时才执行计算逻辑,并保证整个“查 + 算 + 存”过程原子化,彻底规避双重检查锁(DCL)的手动实现风险。
ConcurrentHashMapcache = new ConcurrentHashMap<>(); String result = cache.computeIfAbsent("key", k -> { // 这里放耗时操作,比如查数据库、调远程接口 return expensiveOperation(k); });
- 如果多个线程同时调用
computeIfAbsent同一个 key,只有一个线程会执行 lambda,其余阻塞等待并直接获取结果 - lambda 内不能抛受检异常,需自行包装为运行时异常,否则编译不通过
- 不适用于需要“过期自动失效”的场景——它本身不支持 TTL
需要自动过期?别自己手写定时清理,优先用 Caffeine
ConcurrentHashMap 没有过期机制,手动维护 lastAccessTime + 定时扫描清理,极易出错:漏删、误删、并发修改异常、GC 压力大。
-
Caffeine是目前 Java 生态最推荐的本地缓存库,API 简洁,性能接近理论极限,支持expireAfterWrite、expireAfterAccess、大小限制、引用回收等 - 它底层仍用
ConcurrentHashMap存储,但封装了异步清理、权重统计、LRU/King-Max 等策略 - Maven 引入:
com.github.ben-manes.caffeine caffeine 3.1.8
Caffeinecaffeine = Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(10, TimeUnit.MINUTES); LoadingCache cache = caffeine.build(key -> expensiveOperation(key));
缓存穿透和雪崩不是并发问题,但常被一起误用
线程安全 ≠ 缓存可靠性。高并发下,若大量请求击穿缓存查 DB(穿透),或缓存集中失效(雪崩),照样压垮后端——这跟 ConcurrentHashMap 是否线程安全无关。
立即学习“Java免费学习笔记(深入)”;
- 防穿透:对空结果也缓存(设较短过期时间),或用布隆过滤器前置拦截非法 key
- 防雪崩:给过期时间加随机扰动,比如
expireAfterWrite(10 + random(0, 3), MINUTES) - 这些策略要和线程安全缓存正交使用,不是替代关系
computeIfAbsent 中抛异常是否影响 map 状态、Caffeine 的刷新机制是否阻塞调用线程)才是实际踩坑最多的地方。










