Java GUI内存泄漏主因是组件生命周期与引用不匹配：监听器未注销、静态缓存UI组件、模态对话框未dispose、线程持有UI引用。需显式移除监听器、避免static持有组件、及时dispose对话框、用弱引用解耦线程与UI。
Java GUI应用中，内存泄漏常源于组件生命周期与引用关系不匹配——界面元素本该随窗口关闭而释放，却因被长生命周期对象意外持有而滞留内存。
监听器未注销导致的组件驻留
Swing或JavaFX中注册事件监听器时，若监听器是内部类或匿名类，它会隐式持有外部GUI组件（如JFrame、JPanel）的引用。一旦监听器被注册到全局事件总线、定时器或后台线程，而窗口关闭时未显式移除，整个组件树就无法被GC回收。
- Swing示例：在JFrame中用
button.addActionListener(new ActionListener(){...})注册监听器后，需在WindowListener.windowClosed()中调用button.removeActionListener(...) - JavaFX示例：使用
scene.setOnKeyPressed(...)后，应在场景销毁前调用scene.setOnKeyPressed(null)或保存监听器引用以便显式清除 - 更安全做法：优先使用lambda表达式（无隐式外部类引用），或改用WeakReference包装监听器
静态UI容器或缓存持有组件引用
开发者有时为实现“快速切换视图”而将JPanel、JDialog等实例存入static Map或List中，误以为只是复用界面。但这些组件本身持有大量资源（图像、字体、事件队列、渲染上下文），且其内部又引用着父容器和监听器链，形成强引用闭环。
- 避免
private static Map<String, JPanel> cache = new HashMap<>();直接缓存组件实例 - 如需复用逻辑，应缓存数据模型或配置，而非UI组件；界面按需构建、用完即弃
- 确需缓存时，改用
WeakHashMap，让GC可在内存紧张时自动清理无强引用的组件
未正确处置模态对话框与资源绑定
showDialog()类方法创建的JDialog若未显式dispose()，不仅窗体对象残留，其关联的Graphics对象、InputContext、FocusManager监听器等底层资源也会持续占用内存。尤其在频繁弹出提示框的桌面应用中，问题会快速累积。
立即学习“Java免费学习笔记（深入）”；
- 所有
JDialog、JFileChooser、JColorChooser等在关闭后必须调用dispose() - 不要仅依赖
setDefaultCloseOperation(DISPOSE_ON_CLOSE)，需确保窗口真正关闭（监听WINDOW_CLOSED事件再确认） - 若对话框内含自定义组件（如带Timer的面板），需在
dispose()前手动stop timer、clear listeners
线程与UI组件的跨生命周期耦合
SwingWorker、Swing Timer或普通Thread中若直接持有JComponent引用并执行更新操作，当用户已关闭窗口，线程仍在运行并尝试label.setText()，不仅引发异常，更使组件因被线程栈引用而无法回收。
- 在
done()或finally块中检查组件是否isDisplayable()，再执行UI更新 - 使用
SwingUtilities.invokeLater()前先判断EventQueue是否仍活跃（可通过SwingUtilities.isEventDispatchThread()辅助判断） - 推荐模式：将UI更新逻辑封装为Runnable，由弱引用持有组件，避免强引用延长生命周期
