weakhashmap 与 softreference 不应混用，而应分层协作：一级用 concurrenthashmap/lru 缓存热数据，二级用 weakhashmap 缓存依附瞬时对象的元数据，三级用 softreference+referencequeue 管理可丢弃大块数据，各司其职并协同升降级。
WeakHashMap 本身不直接与 SoftReference 结合使用，二者定位不同、机制冲突——WeakHashMap 的 key 是弱引用，value 是强引用；而 SoftReference 通常用于包装 value，但若强行混用，反而破坏 WeakHashMap 的自动清理逻辑，也削弱 SoftReference 的内存敏感特性。真正合理的多级缓存设计，是让它们各司其职、分层协作。
一级：强引用 LRU 缓存（高频热数据）
用 ConcurrentHashMap 或 LruCache（Android）作为主缓存层，设置明确容量上限和访问排序策略：
- 所有新加载的数据先写入此层，保证低延迟响应
- 命中即返回，不穿透下层
- 满时按 LRU 踢出最久未用项，主动释放内存，避免被动 GC 干预
二级：WeakHashMap 缓存（短生命周期元数据）
专用于缓存“依附于瞬时对象”的衍生数据，例如：
- 某个
User实例对应的权限计算结果（key 是 User 对象本身） - 临时 UI 组件绑定的渲染状态（key 是 View 或 Fragment）
- 类加载器隔离下的反射方法缓存（key 是 Class 对象）
关键约束：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- key 必须是业务中可能被回收的对象，且不能是 String 或 Integer 等常量池对象
- key 类必须正确重写
equals()和hashCode() - value 保持强引用，但体积要小；若 value 是大数组或敏感数据，需手动清零（如
Arrays.fill(bytes, (byte)0)）
三级：SoftReference + ReferenceQueue 管理的大块缓存
不直接用 HashMap<k softreference>></k>，而是封装为带队列监听的结构：
- 主缓存结构仍是
ConcurrentHashMap<k softreference>></k> - 每个
SoftReference构造时传入共享ReferenceQueue - 后台线程定期调用
queue.poll()，拿到已回收的SoftReference，提取其 key 并从主 map 中移除 - 读取时先
get()，再判空；为空则重建并重新 put
适用场景：
- 图片缩略图、报表模板解析结果、JSON Schema 编译对象
- 重建成本可控，且允许在内存紧张时丢弃
- 配合 JVM 参数
-XX:SoftRefLRUPolicyMSPerMB=1000调整软引用保留策略
兜底与协同策略
多级不是简单 fallback，而是有协同逻辑：
- 从 WeakHashMap 或 SoftReference 层读到数据后，立即提升到一级 LRU 缓存（“热数据升权”）
- 一级缓存淘汰时，若该数据在二级或三级中仍存在，可降级保留，避免完全重建
- 所有层级都不承担强一致性责任；涉及会话、库存、订单等，必须交由 Redis 或数据库保障
- 上线前实测：构造仅被 WeakHashMap key 引用的对象 → 置 null →
System.gc()→ 检查 entry 是否消失
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
