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<String, String> 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 引入：
<dependency><groupId>com.github.ben-manes.caffeine</groupId><artifactId>caffeine</artifactId><version>3.1.8</version></dependency>
Caffeine<String, String> caffeine = Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(10, TimeUnit.MINUTES);
LoadingCache<String, String> cache = caffeine.build(key -> expensiveOperation(key));
缓存穿透和雪崩不是并发问题，但常被一起误用
线程安全 ≠ 缓存可靠性。高并发下，若大量请求击穿缓存查 DB（穿透），或缓存集中失效（雪崩），照样压垮后端——这跟 ConcurrentHashMap 是否线程安全无关。
立即学习“Java免费学习笔记（深入）”；
- 防穿透：对空结果也缓存（设较短过期时间），或用布隆过滤器前置拦截非法 key
- 防雪崩：给过期时间加随机扰动，比如
expireAfterWrite(10 + random(0, 3), MINUTES) - 这些策略要和线程安全缓存正交使用，不是替代关系
computeIfAbsent 中抛异常是否影响 map 状态、Caffeine 的刷新机制是否阻塞调用线程）才是实际踩坑最多的地方。 
