对象池与缓存技术若使用不当易致内存泄漏，须控制生命周期、设容量上限、配ttl/lru策略、确保借还闭环、避免弱/软引用滥用，并主动释放非堆资源。
对象池与缓存技术本身是为降低内存分配开销、提升性能而设计的，但若使用不当，反而会成为内存泄漏的“温床”。关键不在于禁用它们，而在于控制生命周期、限制规模、及时清理。
缓存必须设上限并带过期机制
无节制增长的缓存是最常见的泄漏源头。比如 Express 的 app.cache 虽默认启用 LRU 策略，但若未配置最大容量或 TTL，仍可能持续累积模板编译结果；Java 中 static Map<string object></string> 若不做 size 限制和淘汰逻辑，就会把所有历史请求数据钉在堆里。
- 始终设置缓存项的存活时间（TTL）或最后访问时间（LRU 最大条目数）
- 避免直接用
new HashMap()或new ArrayList()做全局缓存容器，优先选用ConcurrentHashMap+ 定时清理，或成熟的缓存库如 Caffeine、Guava Cache、.NET 的MemoryCache - 对视图模板、SQL 预编译语句等高频复用对象，启用框架内置缓存开关（如 Express 的
view cache）的同时，确认其底层是否已集成驱逐策略
对象池需严格管理借用与归还
对象池的核心契约是：借出必归还。一旦某个分支（如异常路径、早期 return、异步回调未执行）跳过了归还逻辑，该对象就脱离池管理，变成“孤儿实例”，长期占用内存。
- 池中对象应实现清晰的
reset()方法，在归还前重置状态，防止脏数据污染后续使用者 - 在 try-finally 或 try-with-resources 中强制归还，尤其在 I/O 或数据库操作后
- 监控池的“借出未归还”数量，可通过自定义池实现统计钩子，或使用 Apache Commons Pool 的 JMX 指标暴露
警惕弱引用与软引用的误用边界
WeakReference 和 SoftReference 常被当作“防泄漏缓存”的银弹，但它们有明确适用场景：前者适合临时绑定（如监听器与 UI 组件），后者适合可重建的缓存（如图片缩略图）。滥用会导致缓存命中率骤降或对象过早回收。
- 不要用
WeakReference存储核心业务对象——GC 可能在任意时刻回收，引发 NPE 或逻辑断裂 - 避免在 ThreadLocal 中存储强引用对象，尤其在线程池环境；若必须使用，务必在请求结束时调用
remove() - 静态集合类（如
public static List<x></x>）尽量改用WeakReference<x></x>包装，或直接替换为带自动清理能力的结构
主动释放优于依赖 GC
现代语言虽有自动垃圾回收，但 GC 不负责释放非堆资源（文件句柄、Socket、GPU 显存等），也不保证及时回收强引用对象。对象池和缓存中的对象往往关联着这些外部资源。
- 池对象实现
IDisposable（C#）、AutoCloseable（Java）或类似接口，确保 close/reset 在归还时执行 - Express 中
res.locals = Object.create(null)这类轻量初始化，虽不占大内存，但若在中间件中反复赋值大对象（如整个请求体 JSON），需手动清空或重置 - 定期触发缓存健康检查：扫描过期项、验证引用有效性、记录堆积趋势，而非等到 OOM 才响应
