Java中用Semaphore实现Redis缓存雪崩下的异步保护，核心是轻量级准入控制：在进入数据库前卡住并发数，让多数请求等待而非穿透；它与Runnable+线程池协同形成“双层节流”，Semaphore控入口并发，线程池控实际加载线程数。
Java中用Semaphore实现Redis缓存雪崩下的异步保护，核心不是替代线程池，而是对“缓存重建请求”做轻量级准入控制——在进入数据库前卡住并发数，让多数请求等待而非直接穿透。它和Runnable+线程池配合使用，形成“双层节流”：Semaphore控入口并发，线程池控实际加载线程数。
用Semaphore限制同时触发重建的请求数
缓存失效瞬间，成百上千请求涌入，若全部尝试加锁查库，Redis分布式锁竞争激烈，数据库仍可能被压垮。Semaphore可提前拦截：
- 定义全局信号量，许可数设为2~5（与数据库单次查询吞吐匹配，例如DB能扛3QPS，就设3）
- 每次读缓存未命中时，先尝试acquire()；获取失败则直接返回兜底数据或空值，不进后续流程
- 成功获取许可后，才执行加锁、查库、写缓存等操作；完成后必须在finally里release()
- 注意设置超时 acquire(1, 100, TimeUnit.MILLISECONDS)，避免无限阻塞，超时即降级
与Redis分布式锁协同防重复加载
Semaphore只控“有多少请求能进重建流程”，不保证它们不会重复查库。必须叠加分布式锁：
- acquire成功后，立刻用SET key value NX EX命令争抢加载锁，锁名建议含业务标识+key（如lock:reload:user:1001）
- 抢锁失败，说明已有其他线程在加载，此时释放Semaphore许可（release()），并等待缓存写入完成（可用Redis Pub/Sub或短TTL占位符通知）
- 抢锁成功者执行完整流程：查DB → 写Redis（带随机TTL）→ 删除锁 → release()；异常时也要确保release()和删锁
结合本地状态减少无效等待
纯靠Semaphore+Redis锁，仍有少量请求会“抢到许可但没抢到锁”，白白消耗许可。可在内存加一层协调：
立即学习“Java免费学习笔记（深入）”；
- 用ConcurrentHashMap
标记某key是否已提交重建任务（true=已提交，false=未开始） - acquire成功后，先检查该map：若为true，直接release()并等待；若为false，则CAS设为true再抢锁
- 任务完成或失败后，清除map中对应项，避免长期占用内存
降级与熔断兜底不能省
当Semaphore许可耗尽或Redis不可用时，必须有明确退路：
- acquire超时或锁争抢失败，返回Caffeine本地缓存中的旧值（如有）、静态默认值，或直接抛出可识别的业务异常
- 配合Resilience4j配置熔断器：若连续5次重建失败，自动开启熔断，后续请求跳过重建逻辑，直走降级路径
- 所有异常需记录日志并上报监控（如Prometheus指标cache_reload_fail_total），便于快速定位雪崩源头
