java缓存雪崩限流异步加载核心是用固定大小线程池（如3）控并发，配合redis分布式锁与状态标记防重复提交，runnable仅作任务载体；任务需查库、写缓存（带随机ttl）、清状态，并异常兜底。
Java中利用 Runnable 在缓存雪崩场景下实现限流异步加载，核心不是靠 Runnable 本身限流，而是将其作为异步任务载体，配合线程池控制并发、结合锁与状态标记，避免大量请求同时触发重建。关键在于“有节制地放行少数线程去加载，其余等待或降级”，而非让所有请求都排队执行 Runnable。
用固定大小线程池限制并发加载数
直接使用 Executors.newFixedThreadPool(n) 创建有限容量的线程池（如 n=3），只允许最多 n 个线程并发执行缓存重建任务。超出的请求不提交新任务，而是等待或返回兜底数据。
- 线程池大小需根据数据库承载能力预估，一般设为 2~5，避免压垮下游
- 不建议用
newCachedThreadPool，它会无限制创建线程，雪崩时反而加剧风险 - 示例：定义全局共享线程池
private static final ExecutorService LOADER_POOL = Executors.newFixedThreadPool(3);
结合 Redis 分布式锁 + 状态标记避免重复提交
即使用了线程池，仍需防止多个请求同时判断“缓存为空”后都提交 Runnable。应在提交前加锁，并用 Redis 标记“是否已有加载任务在进行中”。
- 先尝试用
SET key value NX EX 30获取加载锁，成功才提交Runnable - 锁值建议带唯一标识（如 UUID），便于排查；过期时间设为略大于预期加载耗时
- 若抢锁失败，不阻塞，可立即返回旧缓存、空值或默认响应，不进线程池
Runnable 任务内完成加载+写入+清理
提交的 Runnable 要职责清晰：查库 → 写 Redis → 清除加载中状态。不能只查不写，也不能忽略异常处理。
- 任务中需捕获数据库异常，失败时主动删除锁、记录日志，避免锁残留导致后续请求全被拒
- 写入缓存时务必设置随机过期时间（如
3600 + random.nextInt(600)），从源头降低下次雪崩概率 - 可额外写一个短时效的“加载中占位符”（如
cache:loading:user:123 → "1"，TTL=5s），供其他请求快速识别并等待
配合本地缓存做轻量级等待协调
纯靠 Redis 锁 + 线程池仍有少量请求可能“错过锁但又没等到结果”。可在应用层加一层内存标记（如 ConcurrentHashMap<string completablefuture>></string>），让后续请求复用同一异步任务结果。
- 首次请求生成
CompletableFuture并放入 map，再提交Runnable执行加载 - 后续请求查到该 future，直接
join()等待，无需重复提交或轮询 - 任务完成后移除 map 中条目，避免内存泄漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
