向领导汇报技术难点，同事却突然插话“这点问题都解决不了，能力不行啊”。。

算法题：有时间限制的缓存

说到“有时间限制的缓存”，咱们干这行的第一反应肯定是：这不就跟咱日常写的那种缓存加个过期时间么？听起来不复杂对吧？但你真上项目，尤其是高并发场景，坑就多了去了👀。

我先说个最简单的版本吧，就是搞个 HashMap 搭配一个记录时间戳的结构，然后每次访问的时候判断这个 key 有没有过期。听起来像模像样，但这玩意儿根本扛不住并发，缓存击穿了就一地鸡毛。

来个例子感受一下：

classTimeLimitedCache<K, V> {
privatefinal Map<K, CacheEntry<V>> map = new ConcurrentHashMap<>();
privatefinallong ttl;

publicTimeLimitedCache(long ttl){
this.ttl = ttl;
    }

publicvoidput(K key, V value){
long expiryTime = System.currentTimeMillis() + ttl;
        map.put(key, new CacheEntry<>(value, expiryTime));
    }

public V get(K key){
        CacheEntry<V> entry = map.get(key);
if (entry == null || entry.expiryTime < System.currentTimeMillis()) {
            map.remove(key);
returnnull;
        }
return entry.value;
    }

privatestaticclassCacheEntry<V> {
        V value;
long expiryTime;
        CacheEntry(V value, long expiryTime) {
this.value = value;
this.expiryTime = expiryTime;
        }
    }
}

看着还行吧？但问题在哪？⚠️ 没有定时清理机制。这种实现适合读多写少的小缓存，如果 key 多得飞起，那 ConcurrentHashMap 会一直堆积，最后 JVM 内存爆了你都不知道怎么死的。

所以你得加个定时清理线程，来扫掉过期的 key。但定时清理的频率怎么设？太频繁浪费资源，太慢又不准时清理，取个中间值吧？结果你可能就陷入一个调参地狱。

那更高级点的方案是啥？用个优先队列 PriorityQueue 按过期时间排序，再加个后台线程一直从队列头取，如果过期了就删掉，没过期就等着。但 Java 原生的 PriorityQueue 线程不安全，必须包一层锁，性能又下来了。

而且更关键的是，如果并发 put 和清理线程一起跑，这种延迟会非常明显，甚至可能删掉还没来得及被读的值。这时候你就知道为啥 Guava Cache、Caffeine 这些成熟库会做那么多复杂处理了……

再聊点业务上的应用场景。有次我们搞一个搜索结果缓存，需求是十分钟过期，但十分钟内同一个用户查同一个词不能重新请求搜索服务。当时贪图省事直接用上面这种结构，结果用户疯狂刷新，几乎每次都在边界值刷新，缓存刚好失效。搜索服务被打爆，我们集体被拉群开会🐶。

后来换成 Caffeine 以后，不但支持基于访问时间的刷新，还有软引用 GC 回收和缓存自动调整机制，终于稳住了。

说到底，“有时间限制的缓存”这四个字听起来简单，做起来门道一堆。你要考虑线程安全、内存泄漏、定期清理、缓存雪崩、击穿、穿透这些问题。稍微大点的系统，这玩意儿都是用来挡流量、稳服务的核心组件。

所以我的建议是，自己实现练练手可以，但真上项目别造轮子，老老实实上成熟的缓存库，比如 Guava 或 Caffeine，别拿自己的系统冒险🔥。

不过讲真，这事儿也让我反思了，写代码不能光看需求表面，得带脑子考虑系统演进，不然你写个看起来精巧的逻辑，过几天业务量一上去，系统全崩了，到时候挨骂还得你自己背锅🫠。

各位兄弟姐妹们，用缓存这事儿别掉以轻心，能借力成熟组件就别硬刚了，系统扛得住才是硬道理。你们项目里有遇到类似缓存过期导致系统异常的案例吗？欢迎来聊聊～

-END-

我为大家打造了一份RPA教程，完全免费：https://www.songshuhezi.com/rpa.html