ConcurrentHashMap 可实现线程安全简易缓存，支持原子操作如 computeIfAbsent，适合静态数据；需手动管理过期与清理，不自动回收；Weak/SoftReference 不适用因不可控且非线程安全；LinkedHashMap 非线程安全且无 TTL；复杂场景应选 Caffeine。
用 ConcurrentHashMap 实现线程安全的简易缓存
Java 标准库没有开箱即用的“轻量缓存类”，但 ConcurrentHashMap 足以支撑大多数简单场景——它支持高并发读写，且自带 computeIfAbsent 这类原子操作，避免手动加锁。
- 适合缓存不常变更、生命周期由业务控制（比如配置项、枚举映射表）的场景
- 不自动过期，需自行在写入/读取时检查时间戳或版本号
- 若键值对数量增长不可控，必须配合
size()+ 定期清理逻辑，否则可能内存泄漏
private final ConcurrentHashMap<String, CacheEntry> cache = new ConcurrentHashMap<>();
static class CacheEntry {
final Object value;
final long expireAt; // 毫秒时间戳
CacheEntry(Object value, long ttlMs) {
this.value = value;
this.expireAt = System.currentTimeMillis() + ttlMs;
}
}
public <T> T get(String key, Supplier<T> loader) {
CacheEntry entry = cache.get(key);
if (entry != null && System.currentTimeMillis() < entry.expireAt) {
return (T) entry.value;
}
T loaded = loader.get();
cache.put(key, new CacheEntry(loaded, 60_000)); // 默认 60s TTL
return loaded;
}
为什么不用 WeakReference 或 SoftReference 做自动回收
初学者常误以为用 WeakHashMap 或包装 SoftReference 就能“自动释放缓存”，实际效果往往不符合预期：
-
WeakHashMap的 key 是弱引用，一旦外部无强引用，GC 后整个 entry 就消失——但缓存 key 通常就是字符串字面量或池化对象，几乎永不被回收 -
SoftReference的回收时机由 JVM 内存压力决定，不是按访问频次或 TTL，无法预测；且 JDK 8+ 后策略更保守，容易长期驻留导致 OOM - 两者都不提供并发安全保证，需额外同步，反而抵消了引用类型带来的收益
避免踩 LinkedHashMap 的坑：重写 removeEldestEntry 不等于 LRU 缓存
LinkedHashMap 确实可通过重写 removeEldestEntry 控制大小，但它默认是插入顺序，不是访问顺序——除非构造时传入 true：
Map<String, Object> lruCache = new LinkedHashMap<>(16, 0.75f, true) {
@Override
protected boolean removeEldestEntry(Map.Entry<String, Object> eldest) {
return size() > 1000; // 超过 1000 个就淘汰最久未访问的
}
};
但注意：LinkedHashMap 非线程安全，多线程下必须外层加锁（如 synchronized），而锁粒度大时会严重拖慢性能；另外，它不支持 TTL，过期逻辑仍需手动维护。
立即学习“Java免费学习笔记（深入）”；
真正需要过期 + 并发 + LRU 时，直接用 Caffeine
如果项目已引入 Maven，且缓存需求超出“简单”范畴（例如：毫秒级 TTL、权重驱逐、统计命中率、异步刷新），别自己造轮子。Caffeine 是目前 Java 生态最成熟的本地缓存库，API 清晰，性能远超 Guava Cache：
Cache<String, Object> cache = Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.recordStats()
.build();
Object value = cache.get("key", k -> loadFromDB(k));
它的 get 方法是原子的，内部用分段锁 + CAS 实现高并发；recordStats() 开启后可随时调用 cache.stats() 查看命中率——这些细节自己实现极易出错。
复杂点在于：Caffeine 的驱逐不是实时触发的，而是惰性清理（在读写时顺带处理），所以内存占用略高于理论值；若对内存敏感，需定期调用 cleanUp()，但不要过于频繁，否则影响吞吐。
