不能直接用普通 dict 做带过期的缓存,因为 dict 不记录写入时间、无法自动清理过期项,每次读取需手动校验时间且遍历删除性能差、易漏删、线程不安全。

为什么不能直接用普通 dict 做带过期的缓存
直接拿 dict 当缓存,最大的问题就是它“没记性”——写入时不会记录时间戳,读取时也不会自动判断是否过期。你查 cache['key'],它只会傻乎乎地返回值,根本不管这个值是不是已经“超时下线”。就算你自己在存的时候偷偷记个时间,每次读都得手动跟 time.time() 比一比,过期了还得遍历删,效率低、容易漏、还线程不安全。说白了,dict 就不是为缓存设计的。
最简可行方案:封装一个 TTLCache 类,用 time.time() + dict 维护
核心思路其实很简单:每个 key 存一个元组 (value, expire_at),expire_at 是过期的时间戳。读取时检查 expire_at < time.time(),没过期就返回值,过期了就删掉并返回 None。写入时直接算好绝对时间戳,而不是存相对秒数——这样更稳定,系统时间跳变或 NTP 同步时不会乱套。
- 写入时用
time.time() + ttl_seconds存绝对时间戳,比存相对时间更靠谱(尤其在系统时钟步进时) - 读取时不做删除动作,只判断是否过期;真正清理交给
get()或__getitem__()中的惰性剔除 - 如果需要批量清理,可以加个
purge()方法遍历删,但别在每次get里全量扫——O(n) 太伤
import time
class TTLCache:
def __init__(self):
self._data = {}
def set(self, key, value, ttl):
self._data[key] = (value, time.time() + ttl)
def get(self, key, default=None):
item = self._data.get(key)
if item is None:
return default
value, expire_at = item
if time.time() > expire_at:
del self._data[key]
return default
return value
def __contains__(self, key):
return self.get(key) is not None
time.time() 精度和时钟漂移会影响 TTL 准确性吗
确实会,但大多数场景下可以接受。Linux/macOS 上 time.time() 默认基于 CLOCK_REALTIME,精度约毫秒级,而且受系统时钟调整影响——比如 NTP 的 step 调整会导致时间突变。如果业务对“严格±100ms 内过期”有强要求,那就得换 time.monotonic()。它不随系统时间跳变,但无法映射到真实时间点,所以必须在 set() 时记录起始单调时间,并基于 ttl 做相对偏移。
- 用
time.monotonic()的话,set()存的是(value, time.monotonic() + ttl),get()比较用time.monotonic() > expire_at - 缺点:无法实现“固定时刻过期”,比如“每天凌晨 2 点清空”,只能做“写入后 N 秒过期”
- 优点:完全免疫系统时钟倒拨/跳跃,TTL 行为可预测
并发访问下 dict 不是线程安全的,怎么办
dict 的读写在 CPython 中虽有 GIL 保护,但像 if key in d: return d[key] 这种“检查-读取”操作不是原子的,多线程下可能读到过期值或触发 KeyError。真要在线程间共享,必须加锁。
- 最简单是给整个
_data加threading.RLock(),所有方法入口加with self._lock: - 不要用
@synchronized或装饰器隐藏锁逻辑——容易漏锁,也难调试 - 如果用在 asyncio 环境,换成
asyncio.Lock(),但注意:不能混用同步/异步锁 - 高并发场景下,锁粒度太粗会成瓶颈,这时该考虑
functools.lru_cache+ 外部 TTL 轮询,或直接上redis
实际用的时候,多数小项目够用;但一旦缓存键量级上万、或要求强一致性、或部署在容器里频繁启停,就别硬撑——TTL 逻辑会迅速变得脆弱。时间戳怎么存、锁怎么加、过期怎么测,每个细节松一扣,线上就容易出“缓存雪崩”或“脏读”。