监听器未及时移除是java内存泄漏最常见原因。对象注册监听器后若未在生命周期结束时反注册，监听器持有的强引用会阻止gc回收；需严格配对add/remove操作，并可借助weakreference或工具如leakcanary定位问题。
Java内存泄漏中，监听器未及时移除是最常见的原因之一。当对象注册了监听器但生命周期结束时没有反注册，监听器持有的引用会阻止目标对象被GC回收，导致内存持续增长。
监听器持有外部对象强引用
多数监听器（如Swing事件监听、Android View点击监听、自定义回调）在内部保存了对注册对象的引用。若注册对象（比如Activity、Fragment、Service或某个业务组件）已不再使用，而监听器仍存在于事件源（如按钮、定时器、广播接收器）中，该对象就无法被回收。
- 典型场景：Activity中为Button设置OnClickListener，但Activity销毁时未清理；
- 常见误区：认为“匿名内部类监听器用完自动释放”，实际它隐式持有了外部Activity的引用；
- 关键点：监听器本身不释放，等于延长了其所引用对象的生命周期。
注册与注销必须成对出现
监听器添加和删除不是可选操作，而是资源管理契约。任何addXXXListener()调用，都应在对应时机执行removeXXXListener()，且确保调用发生在同一对象实例上。
- Swing：addMouseListener()后，在窗口关闭或组件销毁时调用removeMouseListener()；
- Android：onCreate()中注册，onDestroy()或onStop()中反注册（注意避免在onDestroy()中操作已销毁的View）；
- 自定义事件总线（如EventBus）：register()必须配对unregister()，推荐在onStart()/onResume()注册、onPause()/onStop()反注册以兼顾生命周期安全。
使用弱引用或静态内部类规避引用泄漏
若监听器逻辑简单且无需访问外部类成员，可改用静态内部类 + WeakReference方式，切断强引用链。
- 将监听器声明为static class，并通过WeakReference持有外部对象；
- 避免在监听器中直接调用外部Activity.this.xxx()，改为通过弱引用安全获取；
- 注意：弱引用不能解决所有问题——如果事件源本身长期存活且持续触发，监听器仍可能因业务逻辑反复创建而堆积，本质仍是未清理。
借助工具定位泄漏源头
仅靠代码检查易遗漏，需结合工具验证：
- Android：使用LeakCanary，它能捕获Activity/Fragment泄漏并展示引用链，一眼看出是哪个监听器没删；
- Java SE：用VisualVM或JProfiler抓堆快照，按“exclude weak/soft/phantom references”过滤，查找Listener接口实现类的实例及它们持有的对象；
- 关键技巧：对比两次快照，观察监听器实例数是否随操作（如反复打开关闭页面）持续增加。
监听器泄漏不难预防，核心就是“谁注册、谁注销”，并在设计阶段明确监听器生命周期边界。写完add之后，立刻补上对应的remove——这不是多此一举，而是内存安全的基本守则。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
