Map实现的热点感知API缓存代理通过实时访问计数与时间窗口识别高频key，自动延长其软过期时间并优先保留，结合ConcurrentHashMap元信息管理、滚动窗口统计及主动老化清理，在无外部依赖下达成轻量自适应缓存。
用 Map 实现带“热点感知”的 API 缓存代理层，核心不是简单存取，而是让缓存能自动识别哪些接口或键被高频访问，并优先保留、快速响应——同时避免冷数据长期占位。它适合轻量级网关、内部服务中转或原型验证场景，不依赖 Redis 等外部组件。
一、什么是“热点感知”在 Map 缓存里的体现
不是靠定时统计或后台线程扫描，而是通过请求过程中的实时行为反馈来判断：某 key 在单位时间（如 60 秒）内被访问 ≥5 次，就标记为热点；后续访问直接走内存快路径，且延长其逻辑存活时间（比如从 30 秒延到 120 秒），而普通 key 仍按原 TTL 清理。
关键点在于：热点判定与缓存读写耦合，不引入额外延迟；Map 本身不支持过期，需手动维护时间戳和访问计数。
二、基础结构设计：带元信息的 Map 缓存容器
不用裸 Map
- 定义缓存项类型：CacheEntry
{ value: T, lastAccess: long, hitCount: int, softExpireAt: long } - 主缓存容器：ConcurrentHashMap
> （保证多线程安全） - 另设一个 ConcurrentHashMap
记录每个 key 的“最近一次热点窗口起始时间”，用于滚动统计
三、热点识别与响应加速的关键逻辑
在代理层拦截请求（例如 Spring Boot 的 Filter 或自定义 WebClient 拦截器）时执行以下步骤：
- 根据请求路径 + 查询参数生成唯一 key（如 /api/user/profile?uid=1001 → hash("GET:/api/user/profile?uid=1001")）
- 查 Map 获取 CacheEntry；若存在，更新 lastAccess 和 hitCount，并检查是否进入热点窗口（当前时间 - 窗口起始时间
- 若 hitCount ≥ 5 且处于同一窗口，触发“热点升级”：设置 softExpireAt = System.currentTimeMillis() + 120_000，并重置该窗口起始时间为当前时间
- 响应时：若命中且未过期（System.currentTimeMillis() ），直接返回 value；否则走下游，成功后按热度等级设不同 TTL 再写入
四、清理与降级保障
Map 不自动清理，必须主动控制容量和老化：
- 设置最大条目数（如 10000），超限时按 lastAccess 倒序淘汰最久未访问的非热点项
- 对所有 entry 定期（如每 5 秒）扫描，清理 softExpireAt 的条目（可用 ScheduledExecutorService）
- 当 CPU 使用率 > 85% 或 GC 频繁时，自动关闭热点统计模块，退化为固定 TTL 缓存，防止反向拖慢
不复杂但容易忽略：热点感知的价值不在“多记几次数”，而在让缓存策略随流量脉动实时适应——Map 提供了足够低的延迟和可控的粒度，只要把时间、计数、状态三个维度串起来，就能跑出轻量却有效的代理层缓存效果。
