监听器与回调未注销是Java高频内存泄漏原因，表现为不该持有的引用长期存在，需通过堆转储分析GC Roots路径定位泄漏源，并在注册处配对注销逻辑，辅以LeakCanary等工具检测和WeakReference等写法加固。
监听器与回调未注销是 Java 中非常典型且高频的内存泄漏原因，尤其在事件驱动、GUI、Web 和 Android 开发中。它不表现为“对象没释放”，而是“不该持有的引用一直被持有着”，导致本该被回收的对象（如 Controller、Activity、Service）长期滞留堆中。
看引用链：从 GC Roots 追踪谁在强持监听目标
核心思路是确认“谁还引用着本该销毁的对象”。常用方法是抓取堆转储（heap dump），用 Eclipse MAT 或 VisualVM 分析：
- 打开 dump 文件后，定位到疑似泄漏对象（比如某个 Activity 实例或 Spring Controller）
- 右键 → “Path to GC Roots” → 选择 “with all references”
- 重点检查路径中是否出现：EventBus、RxJava Subscription、Spring ApplicationListener、自定义静态 listeners 列表、OkHttp Interceptor、Swing Listener 等
- 若发现某监听器集合（如
static List<Listener>）→ 监听器本身 → 外部类实例，就基本坐实了未注销问题
查代码：盯住注册点，反向确认有没有配套的注销逻辑
不是所有注册都要手动注销，但凡用了以下模式，必须人工保障清理闭环：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
全局事件总线：Guava EventBus、Otto、RxBus —— 注册（
register(this)）必须配对unregister(this)，且调用时机要在组件生命周期终点（如onDestroy()、destroy()、@PreDestroy） -
RxJava / Project Reactor：订阅后返回
Disposable或Cancellation，务必在 dispose()；使用CompositeDisposable统一管理更安全 -
Spring 事件监听：实现
ApplicationListener或用@EventListener的 Bean 若为 prototype 或短生命周期，需确认监听器 Bean 是否随上下文销毁 —— 否则监听器会持续持有事件源引用 -
自定义监听器容器：如知识库中示例的
EventManager类，若只有addListener()没有removeListener()，就是硬伤
用工具提前拦截：LeakCanary（Android）、Sentry（JVM）、或单元测试模拟生命周期
靠人工 review 容易漏，建议嵌入自动化防护：
立即学习“Java免费学习笔记（深入）”；
- Android 项目直接接入 LeakCanary，它会在 Activity 销毁后自动检测是否被监听器/Handler 持有，并生成带引用链的报告
- JVM 服务可用 Sentry JVM Profiling 或自定义
java.lang.ref.PhantomReference监听关键对象（如 Controller）的 finalize 状态，配合日志告警 - 写单元测试时，显式触发“注册 → 销毁 → 强制 GC → 检查对象是否可达”，例如用
WeakReference<MyController>验证销毁后是否为 null
写法加固：从源头降低泄漏风险
与其事后排查，不如让代码自带免疫能力：
- 优先用 WeakReference 包装监听器内部持有的目标对象，比如自定义监听器里不存
this.activity，而存new WeakReference<>(activity) - 选用生命周期感知组件：
LiveData.observe(this, ...)中的this是 LifecycleOwner，框架自动在ON_DESTROY时移除观察者 - 避免静态集合直接 hold 监听器实例；改用
WeakHashMap<Listener, Boolean>或带自动过期的缓存（如 Guava Cache）
