静态集合导致内存泄漏的核心是强引用+不释放，解决关键在于让引用可回收、容量可控、生命周期可管理：优先用weakhashmap（key弱引用）、内置lru淘汰机制、提供显式清理方法、或改用局部变量/外部缓存。
静态集合导致的内存泄漏，核心在于“强引用 + 不释放”，不是集合本身有问题，而是它把本该被回收的对象死死拽住不放。解决的关键是让引用可回收、容量可控、生命周期可管理。
优先改用弱引用容器
如果缓存的 key 本身可以被回收（比如是临时创建的字符串、轻量级 DTO），WeakHashMap 是最直接的解法。它的 key 是弱引用，只要外部不再强引用这个 key，下次 GC 就会自动清理对应 entry。
- 适用场景：key 是业务中可能短期存在的对象，且不依赖其长期驻留
- 注意点：value 仍是强引用，若 value 很大或持有其他对象，仍需配合清理逻辑
- 不适用场景：key 必须长期有效（如全局配置 ID），否则 entry 会意外消失
内置淘汰机制，限制增长
用 LinkedHashMap 实现 LRU 或固定容量缓存，重写 removeEldestEntry() 方法，让集合自己“吐旧纳新”。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 示例：设置最大容量为 1000，超过后自动移除最久未使用的项
- 比手动定时清理更可靠，避免因任务失败或异常导致清理遗漏
- 适合对命中率有要求、但又不能无限堆积的业务缓存
提供显式清理入口并主动调用
静态集合不是不能用，而是必须有人管。给工具类加上 evictByKey()、clearByType()、expireAll() 等方法，并在业务逻辑的关键节点调用。
- 用户登出时清空其相关缓存
- 请求结束前清理本次请求生成的中间对象
- 定时任务每 5 分钟扫描过期项（配合时间戳字段）
多数时候根本不需要静态集合
很多所谓“全局缓存”，其实只是单次请求或单个服务实例内的临时数据。直接用局部变量 new ArrayList() 或 ConcurrentHashMap（非 static）更安全。
- 方法内 new 的集合随栈帧自然销毁，GC 无压力
- Service 层用成员变量（非 static）+ Spring scope 控制生命周期，比 static 更易测试和隔离
- 真要跨实例共享，交给 Redis 等外部存储，不把压力留在 JVM 堆里
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
