监听器未注销是Java内存泄漏的典型诱因，因短生命周期对象被长生命周期对象通过监听器强引用而无法回收，需注册与注销成对执行并采用稳定引用方式。
监听器未注销是Java内存泄漏的典型诱因之一。它不会立刻报错，但会让本该被回收的对象持续挂在引用链上，最终拖垮堆内存。
隐患核心：监听器让对象“死不掉”
当一个短生命周期对象（比如Activity、Fragment、Controller）注册了监听器到长生命周期对象（如静态工具类、单例、全局按钮、EventBus实例）后，若不主动注销，监听器会反向持有该短生命周期对象的强引用。GC Roots 顺着这条引用链就能触达它——哪怕业务逻辑早已结束，对象也无法回收。
- Android中常见表现：Activity销毁后仍驻留内存，引发OOM或ANR
- Swing/JavaFX中：窗口关闭后组件和监听器一起滞留，CPU与内存双升高
- Spring环境：@EventListener 注册在prototype Bean上却未配合@PreDestroy清理，导致Bean实例堆积
关键修正动作：注册与注销必须成对出现
不能只写addXXXListener，必须明确写出对应的removeXXXListener，并确保执行时机准确、引用一致。
- 在Android中，于onDestroy()或onDetachedFromWindow()中调用移除方法；Service则对应onDestroy()
- Swing/JavaFX中，在dispose()或窗口WindowEvent.WINDOW_CLOSING回调里清理
- 避免使用匿名内部类或Lambda直接注册：new ActionListener(){...} 或 () -> {...} 每次都生成新对象，remove时无法匹配原引用
- 改用具名方法引用或提前定义的稳定函数：例如 button.addActionListener(this::handleClick)，注销时用 button.removeActionListener(this::handleClick)
框架级防护建议
不同生态已有成熟约定，遵循即可大幅降低风险：
立即学习“Java免费学习笔记（深入）”；
- Spring @EventListener：搭配@PreDestroy或实现DisposableBean接口，在销毁前调用context.unpublishEvent(...)或自行维护监听器列表并清空
- Guava EventBus：注册时保存eventBus.register(this)返回的引用，销毁时调用eventBus.unregister(this)
- 自定义事件总线：监听器列表应为WeakReference<EventListener>包装，或提供显式clearAllListeners()兜底方法
- 日志辅助验证：在销毁逻辑末尾打印listeners.size()，上线前加断言确保为0
诊断小技巧
一旦怀疑泄漏，可快速验证：
- 用JDK自带jmap -histo:live <pid>观察监听器类实例数是否异常增长
- 触发一次Full GC后，用jmap -dump:format=b,file=heap.hprof <pid>导出堆快照，用VisualVM或Eclipse MAT分析“支配树”，查找持有Activity/Fragment等对象的监听器实例
- 重点关注java.awt.AWTEventMulticaster、javax.swing.Timer、org.springframework.context.event.ApplicationListenerMethodAdapter等高频泄漏点
