如何确保提交给ThreadPoolExecutor然后取消的FutureTask的垃圾收集？ [英] How to ensure garbage collection of a FutureTask that is submitted to a ThreadPoolExecutor and then cancelled?

问题描述

我将 Callable 对象提交到 ThreadPoolExecutor ，它们似乎在内存中存在。

I am submitting Callable objects to a ThreadPoolExecutor and they seem to be sticking around in memory.

使用MAT工具查看堆转储，看到 Callable 对象被<$ c $引用c> FutureTask $ Sync 的可调用变量。那个 FutureTask $ Sync 由 FutureTask 的 sync 变量引用。那个 FutureTask 被 FutureTask $ Sync 的这个$ 0 变量引用。

Looking at the heap dump with the MAT tool for Eclipse see that the Callable objects are being referenced by a FutureTask$Sync's callable variable. That FutureTask$Sync is referenced by a FutureTask's sync variable. That FutureTask is referenced by the FutureTask$Sync's this$0 variable.

我已经读过这篇文章（这里，这里，以及SO）似乎 FutureTask 将可调用包装在 ThreadPoolExecutor 上提交（）持有对可调用的永久引用。

I have read around about this (here, here, and on SO) and it seems like the FutureTask that the callable is wrapped in upon the ThreadPoolExecutor's submit() holds a reference to the callable forever.

我很困惑的是如何确保 FutureTask 获取垃圾，因此它不会继续保持内存中的可调用内容，并保存可调用内容可能保留在内存中的任何内容？

What I am confused about is how to ensure that the FutureTask gets garbage collected so it doesn't continue to hold the callable in memory, and hold anything the callable might be holding in memory?

只是为了提供更多详细信息关于我的特殊情况，我试图以允许所有提交的t的方式实现 ThreadPoolExecutor 要求在需要时取消。我在SO和其他地方尝试了几种不同的方法，例如完全关闭执行程序（使用 shutdown（）， shutdownNow（）等）并保留期货收益清单 submit（）并在所有货币上调用取消，然后清算期货清单。理想情况下，我不想关闭它，只需 cancel（）并在需要时清除。

Just to give more details about my particular situation, I am trying to implement the ThreadPoolExecutor in a way that allows all of the submitted tasks to be canceled if needed. I have tried several different methods I found on SO and elsewhere, such as completely shutting the executor down (with shutdown(), shutdownNow() etc) and also keeping a list of the futures return by submit() and calling cancel on all them and then clearing the list of futures. Ideally I would like not to have to shut it down, and just cancel() and clear out when needed.

所有这些方法似乎没有什么区别。如果我向游泳池提交一个可调用的游戏，很有可能它最终会坚持下去。

All of these methods don't seem to make a difference. If I submit a callable to the pool, there is a good chance it will end up sticking around.

我做错了什么？

谢谢。

修改：

按要求提供，这是ThreadPoolExecutor的构造函数。

As requested, here is the constructor for the ThreadPoolExecutor.

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
    super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue);
}

经过进一步测试后，我可以看到，如果我让已经提交的任务到ThreadPoolExecutor完成，然后没有泄漏。如果我尝试取消它们，例如：

After further testing I can see that if I let the tasks that have been submitted to the ThreadPoolExecutor finish, then there is no leak. If I try to cancel them in anyway such as:

shutdownNow()

或者保存对未来的引用并稍后调用取消：

Or saving a reference to the future and calling cancel on it later:

Future referenceToCancelLater = submit(task);
...
referenceToCancelLater.cancel(false);

或者通过以下方法将其从队列中删除：

Or by removing them from the queue with methods like:

getQueue.drainTo(someList)

或

getQueue.clear()

或
循环保存对期货的参考并致电：

or Looping through saved references to the futures and calling:

getQueue.remove(task)

任何这些情况都会导致FutureTask如上所述。

Any of those cases causes the FutureTask to stick around as described above.

所有这一切的真正问题是如何正确地取消或删除ThreadPoolExecutor中的项目，以便FutureTask被垃圾收集而不会永远泄露？

So the real question in all of this is how to I properly cancel or remove items from a ThreadPoolExecutor so that the FutureTask is garbage collected and not leaked forever?

推荐答案

我无法工作，所以我提出了以下解决方案。这是一个粗略的概述：我在ThreadPoolExecutor中创建了一个数组，用于跟踪队列中的runnable。然后，当我需要取消队列时，我循环并在每个runnable上调用cancel方法。我的情况是，所有这些runnable都是我创建的自定义类，他们的cancel方法只是设置了一个取消的标志。当队列启动下一个要处理的队列时，在runnable的运行中它会看到它被取消并跳过实际的工作。

I couldn't get anything to work so I came up with the following solution. Here is a rough overview: I created an array in the ThreadPoolExecutor that kept track of the runnables that were in the queue. Then when I needed to cancel the queue, I looped through and called a cancel method on each of the runnables. I my case, all of these runnables were a custom class I created and their cancel method simply set a cancelled flag. When the queue brought up the next one to process, in the run of the runnable it would see it was cancelled and skip the actual work.

所以所有的runnables然后只要它看到它被取消就一个接一个地快速冲出来。

So all of the runnables then just get flushed out quickly one by one as it sees it was cancelled.

可能不是最好的解决方案，但它适用于我并且它不会泄漏内存。

Probably not the greatest solution, but it works for me and it doesn't leak memory.

这篇关于如何确保提交给ThreadPoolExecutor然后取消的FutureTask的垃圾收集？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！