java内存泄漏主因是对象被意外强引用而无法回收，常见于静态集合、未注销监听器、threadlocal未清理及资源未关闭；需用弱引用、及时remove、try-with-resources等手段预防。

Java内存泄漏往往不是因为对象没被释放，而是因为引用链意外地把本该回收的对象拽住了。GC判断对象是否可回收，看的是能否从GC Roots（如线程栈、静态变量、本地方法栈等）出发，通过引用链到达该对象。只要存在一条可达路径，对象就“活”着，哪怕你再也没用过它。

静态集合类是常见“锚点”

静态变量的生命周期与类加载器一致，只要类没卸载，它持有的引用就一直有效。如果把对象放进static List、Map或Set里，又忘了移除，这些对象就会一直被强引用，无法回收。

• 避免直接用static集合缓存业务对象；确实需要缓存时，优先选WeakHashMap或ConcurrentHashMap配合软/弱引用
• 使用完后主动调用remove()或clear()，尤其在监听器注册/注销、回调注册场景中
• 注意内部类隐式持有外部类实例——若静态字段引用了内部类对象，可能间接持有了整个外部类

未注销的监听器和回调

GUI组件、EventBus、RxJava、Spring事件监听器等，常通过注册方式建立引用关系。注册后若不显式注销，监听器对象（及其所在对象）会持续被事件源持有。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 注册监听器的地方，对应写好注销逻辑，最好放在onDestroy()、destroy()或try-finally中
• 使用WeakReference包装监听器（部分框架支持），或选择支持自动解绑的API（如Android的LiveData.observeForever需手动removeObserver）
• 检查第三方库文档，确认其监听机制是否自动管理生命周期

线程与ThreadLocal陷阱

ThreadLocal本身不泄露，但它的value若被线程长期持有（比如线程池中的Worker线程复用），而value又强引用了大对象或外部类实例，就会导致泄漏。

• 每次使用完ThreadLocal后，务必调用remove()，不要只依赖set(null)
• 避免在线程池中让ThreadLocal引用Activity、Fragment、Service等有明确生命周期的对象
• 考虑用InheritableThreadLocal需更谨慎，子线程继承后同样要清理

资源未关闭导致关联对象滞留

InputStream、Connection、Session等资源对象常内部持有缓冲区、连接池句柄甚至回调引用。未close()不仅占系统资源，还可能让GC无法回收其关联的堆内对象（如ByteBuf、ResultSet等）。

• 一律使用try-with-resources语法，确保异常下也能释放
• 检查自定义资源类是否正确实现AutoCloseable，并在close()中清理内部引用
• 数据库连接池配置maxLifetime、idleTimeout，防止连接长期空闲却仍被池持有

定位这类问题，靠的是jstack看线程栈、jmap查对象引用链、MAT分析支配树——关键是顺着GC Roots反向追踪，找到那个不该存在的强引用节点。不复杂但容易忽略。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南