如何避免回调中的内存泄漏？

发布于 2024-09-01 20:37:42 字数 273 浏览 2 评论 0原文

有效的Java 说：

内存泄漏的第三个常见来源是监听器和其他回调。如果你实现了一个 API，其中客户端注册回调但不注册明确取消注册它们，他们会积累，除非你采取一些行动。确保的最好方法是回调被垃圾收集即刻是只存储弱对它们的引用，例如仅将它们作为键存储在 WeakHashMap。

我是 Java 初学者。有人可以教我如何在回调中创建弱引用并告诉我他们如何解决内存泄漏问题吗？谢谢。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

最美的太阳 2024-09-08 20:37:42

阅读这篇文章的

要点是：

您可以将直接引用视为
不需要强引用
额外的编码来创建或访问
目的。其余三种类型
引用是子类
参考类中找到
java.lang.ref 包。软参考
由 SoftReference 提供
类，弱引用
WeakReference 类和幻像
参考文献来自 PhantomReference。
软引用就像数据缓存。
当系统内存不足时，垃圾
收集器可以任意释放
其唯一引用是软对象
参考。换句话说，如果有
没有对对象的强引用，
该对象是
发布。垃圾收集器是
需要释放任何软
抛出之前的参考文献
内存不足异常。
弱引用比软引用更弱
参考。如果仅参考
一个对象是弱引用，
垃圾收集器可以回收
任何时候对象使用的内存。
没有低要求
记忆情况。通常，记忆
对象使用的内容被回收
垃圾收集器的下一次传递。
与清理相关的虚拟引用
任务。他们提供了一个通知
紧邻垃圾之前
收集器执行终结
处理并释放对象。考虑
这是一种在内部执行清理任务的方法
对象。

接下来是 WeakListModel 列表，我不会发布该列表以避免使此响应混乱。

回复收藏 0 原文

饭团 2024-09-08 20:37:42

为了用一个快速（粗略）示例来说明这个概念，请考虑以下情况：

public interface ChangeHandler {
    public void handleChange();
}

public class FileMonitor {

    private File file;
    private Set<ChangeHandler> handlers = new HashSet<ChangeHandler>();

    public FileMonitor(File file) { 
        this.file = file;
    }

    public void registerChangeHandler(ChangeHandler handler) {
        this.handlers.add(handler);
    } 

    public void unregisterChangeHandler(ChangeHandler handler) {
        this.handlers.remove(handler);
    }

    ...
}

如果客户端类随后使用此 FileMonitor API，他们可能会这样做：

public class MyClass {

    File myFile = new File(...);
    FileMonitor monitor = new FileMonitor(myFile);

    public void something() {
        ...
        ChangeHandler myHandler = getChangeHandler();
        monitor.registerChangeHandler(myHandler);
        ...
    }
}

如果 MyClass 的作者> 然后在处理程序完成后忘记调用 unregisterChangeHandler()，FileMonitor 的 HashSet 将永远引用已注册的实例，使其保留在内存中，直到 FileMonitor 被销毁或应用程序退出。

为了防止这种情况，Bloch 建议使用弱引用集合而不是 HashSet，这样，如果您的 MyClass 实例被销毁，该引用将从监视器的收藏。

您可以将 FileMonitor 中的 HashSet 替换为 WeakHashMap 并使用处理程序作为键，因为当对该对象的所有其他引用都消失时，后者会自动从集合中删除处理程序。

To illustrate the concept with a quick (crude) example, consider the following:

public interface ChangeHandler {
    public void handleChange();
}

public class FileMonitor {

    private File file;
    private Set<ChangeHandler> handlers = new HashSet<ChangeHandler>();

    public FileMonitor(File file) { 
        this.file = file;
    }

    public void registerChangeHandler(ChangeHandler handler) {
        this.handlers.add(handler);
    } 

    public void unregisterChangeHandler(ChangeHandler handler) {
        this.handlers.remove(handler);
    }

    ...
}

If a client class then uses this FileMonitor API, they might do this:

public class MyClass {

    File myFile = new File(...);
    FileMonitor monitor = new FileMonitor(myFile);

    public void something() {
        ...
        ChangeHandler myHandler = getChangeHandler();
        monitor.registerChangeHandler(myHandler);
        ...
    }
}

If the author of the MyClass then forgets to call unregisterChangeHandler() when it's done with the handler, the FileMonitor's HashSet will forever reference the instance that was registered, causing it to remain in memory until the FileMonitor is destroyed or the application quits.

To prevent this, Bloch is suggesting using a weak-referencing collection instead of the HashSet, so that if your instance of MyClass is destroyed, the reference will be removed from the monitor's collection.

You might replace the HashSet in FileMonitor with a WeakHashMap and use the handlers as the keys, since the latter will automatically remove the handler from the collection when all other references to the object are gone.

回复收藏 0 原文