java内存泄漏最常被忽视的是静态集合类、单例、非静态内部类及未关闭资源导致短命对象无法回收。需用weakhashmap、weakreference、try-with-resources等机制及时断开引用。
Java内存泄漏里，最常被忽视又最容易复现的，就是静态集合类和长生命周期对象“拖住”短命对象的问题。它不是JVM坏了，而是引用关系没及时断开，让GC以为这些对象还在用。
静态集合类：缓存变“黑洞”
static HashMap、ArrayList 等一旦声明，就活到应用结束。往里面 put 或 add 的对象，哪怕业务逻辑早已不用，只要没手动 remove 或 clear，就会一直驻留。
- 别直接用 static 集合做缓存；真要用，必须配清理机制——按时间（TTL）、按访问频次（LRU），或提供显式清理入口
- 临时数据优先用局部变量或 ThreadLocal，避免升级为全局引用
- 如果 key 是临时对象，考虑用 WeakHashMap：key 只被它引用时，GC 可正常回收
单例与全局管理器：隐性“强绑定”
单例、Application、全局事件总线等，生命周期和 App 一样长。一旦它们持有了 Activity、Fragment、监听器这类短命对象的强引用，后者就跟着“卡住”不释放。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 注册监听器后，务必在对应生命周期终点解注册（如 onDestroy、onDestroyView）
- 对可能短命的对象，用 WeakReference 包一层，比如 WeakReference
或 WeakReference - 避免在单例中直接持有 UI 组件或回调实例，改用接口回调 + 弱引用组合
非静态内部类：悄悄拽住外部类
Handler、AsyncTask 匿名子类、线程任务等，如果写成非静态内部类，会隐式持有外部类（比如 Activity）的强引用。一旦这个内部类被投递到主线程消息队列或线程池里长期待命，Activity 就无法回收。
- 改为 static 内部类，通过 WeakReference 持有外部实例
- Handler 创建时传入 Looper.getMainLooper()，并确保在 Activity 销毁时 removeCallbacksAndMessages(null)
- 异步任务完成后，检查是否还持有上下文，必要时清空引用
资源未关闭：不只是堆内存问题
Connection、InputStream、Socket、Cursor 这些对象背后连着操作系统资源（文件句柄、socket 描述符）。不 close，不仅堆内对象不释放，更可能先耗尽系统级资源，引发 IOException 或崩溃。
- 所有可关闭资源，必须放在 try-with-resources 中，或至少保证 finally 块里调用 close()
- 自定义资源类实现 AutoCloseable，close() 方法需幂等、可重入
- 连接池（如 HikariCP）能缓解压力，但不能替代代码层的 close 责任
不复杂但容易忽略。关键不在“设 null”，而在让引用待在该待的地方、及时松手。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
