我有一个 JFrame 可以接受顶级文件。但是，在发生丢弃之后，对框架的引用将无限期地保留在某些 Swing 内部类中。我相信处理框架应该释放它的所有资源，那么我做错了什么？

例子

import java.awt.datatransfer.DataFlavor;
import java.io.File;
import java.util.List;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.TransferHandler;

public class DnDLeakTester extends JFrame {
    public static void main(String[] args) {
        new DnDLeakTester();

        //Prevent main from returning or the jvm will exit
        while (true) {
            try {
                Thread.sleep(10000);
            } catch (InterruptedException e) {

            }
        }
    }
    public DnDLeakTester() {
        super("I'm leaky");

        add(new JLabel("Drop stuff here"));

        setTransferHandler(new TransferHandler() {
            @Override
            public boolean canImport(final TransferSupport support) {
                return (support.isDrop() && support
                        .isDataFlavorSupported(DataFlavor.javaFileListFlavor));
            }

            @Override
            public boolean importData(final TransferSupport support) {
                if (!canImport(support)) {
                    return false;
                }

                try {
                    final List<File> files = (List<File>) 
                            support.getTransferable().getTransferData(DataFlavor.javaFileListFlavor);

                    for (final File f : files) {
                        System.out.println(f.getName());
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }

                return true;
            }
        });

        setDefaultCloseOperation(DISPOSE_ON_CLOSE);
        pack();
        setVisible(true);
    }
}

要重现，请运行代码并将一些文件放在框架上。关闭框架以便将其丢弃。

为了验证泄漏，我使用 JConsole 进行堆转储并使用 Eclipse Memory Analysis tool 对其进行分析.它表明 sun.awt.AppContext 通过它的散列映射持有对框架的引用。看起来 TransferSupport 有问题。

image of path to GC root http://img402.imageshack.us/img402/4444/dndleak.png

我做错了什么？我是否应该要求 DnD 支持代码以某种方式自行清理？

我正在运行 JDK 1.6 更新 19。

最佳答案

虽然 DropHandler 没有从静态 AppContext 映射中删除，但这并不是真正的根本原因，而只是链中的原因之一。 (放置处理程序旨在成为一个单例，并且在 AppContext 类被卸载之前不会被清除，这在实践中永远不会。)单例 DropHandler 的使用是设计使然。

泄漏的真正原因是 DropHandler 设置了一个 TransferSupport 的实例，它被每个 DnD 操作重用，并且在 DnD 操作期间，为其提供对 DnD 中涉及的组件的引用。问题是它在 DnD 结束时不清除引用。如果 DropHandler 在 DnD 退出时调用了 TransferSupport.setDNDVariables(null,null)，那么问题就会消失。这也是最合乎逻辑的解决方案，因为只有在进行 DnD 时才需要引用组件。其他方法(例如清除 AppContext 映射)是在规避设计，而不是修复一个小疏忽。

但即使我们修复了这个问题，框架仍然不会被收集。不幸的是，似乎还有另一个问题:当我注释掉所有与 DnD 相关的代码，减少到只是一个简单的 JFrame 时，这也没有被收集。重新引用在 javax.swing.BufferStrategyPaintManager 中。有一个 bug report为此，尚未修复。

因此，如果我们修复 DnD，我们会遇到另一个重新绘制的保留问题。幸运的是，所有这些错误只存在于一帧(希望是同一帧!)，所以它并没有那么糟糕。处理框架，因此释放 native 资源，并且可以删除所有内容，允许释放内容，从而降低内存泄漏的严重性。

所以，最后回答你的问题，你没有做错任何事，你只是给了 JDK 中的一些 bug 一点时间!

更新:重绘管理器错误有一个快速修复 - 添加

-Dswing.bufferPerWindow=false

jvm启动选项避免了这个bug。修复此错误后，发布 DnD 错误的修复程序是有意义的:

要解决 DnD 问题，您可以在 importData() 的末尾添加对此方法的调用。

            private void cancelDnD(TransferSupport support)
            {
                /*TransferSupport.setDNDVariables(Component component, DropTargetEvent event) 
                Call setDNDVariables(null, null) to free the component.
*/
                try
                {
                    Method m = support.getClass().getDeclaredMethod("setDNDVariables", new Class[] { Component.class, DropTargetEvent.class });
                    m.setAccessible(true);
                    m.invoke(support, null, null);
                    System.out.println("cancelledDnd");
                }
                catch (Exception e)
                {
                }
            }

关于java - Swing 拖放导致内存泄漏，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2808582/