17370845950

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）的手动实现风险。

ConcurrentHashMap cache = 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.caffeinecaffeine3.1.8

Caffeine caffeine = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(10, TimeUnit.MINUTES);
LoadingCache cache = caffeine.build(key -> expensiveOperation(key));

缓存穿透和雪崩不是并发问题，但常被一起误用

线程安全 ≠ 缓存可靠性。高并发下，若大量请求击穿缓存查 DB（穿透），或缓存集中失效（雪崩），照样压垮后端——这跟 ConcurrentHashMap 是否线程安全无关。

• 防穿透：对空结果也缓存（设较短过期时间），或用布隆过滤器前置拦截非法 key
• 防雪崩：给过期时间加随机扰动，比如 expireAfterWrite(10 + random(0, 3), MINUTES)
• 这些策略要和线程安全缓存正交使用，不是替代关系

缓存的线程安全性容易验证，但复合场景下的行为边界（比如 computeIfAbsent 中抛异常是否影响 map 状态、Caffeine 的刷新机制是否阻塞调用线程）才是实际踩坑最多的地方。