Как обеспечить сбор мусора в FutureTask, который отправлен в ThreadPoolExecutor и затем отменен?

Question

Я отправляю Callable объектов в ThreadPoolExecutor, и они, кажется, торчат в памяти.

Глядя дампа кучи с помощью инструмента MAT Затмения увидеть, что Callable объекты которые ссылаются на отзывной переменной FutureTask$Sync «s. То, что FutureTask$Sync ссылается на переменную FutureTaskс переменной частотой. Это FutureTask ссылается на FutureTask$Syncэтой переменной $ 0.

Я прочитал вокруг этого (here, here, и на SO), и кажется, что FutureTask что вызываемый заворачивают в на ThreadPoolExecutor «s представить() содержит ссылку на Вызываемый навсегда.

В чем я смущен, так это то, как обеспечить, чтобы FutureTask собирал мусор, чтобы он не продолжал удерживать вызываемый в памяти и удерживать в памяти все, что вызываемый может содержать в памяти?

Чтобы подробно рассказать о моей конкретной ситуации, я пытаюсь реализовать ThreadPoolExecutor таким образом, чтобы все предоставленные задачи можно было отменить при необходимости. Я пробовал несколько разных методов, которые я нашел в SO и в других местах, например, полностью отключив исполнителя (с shutdown(), shutdownNow() и т. Д.), А также сохраняя список возвратов фьючерсов на submit() и вызывая отмену для всех них, а затем очищая список фьючерсы. В идеале я бы хотел не закрывать его, а просто cancel() и убирать при необходимости.

Все эти методы, похоже, не имеют значения. Если я отправлю вызываемый в пул, есть хороший шанс, что он в конце концов будет торчать.

Что я делаю неправильно?

Спасибо.

Edit:

В соответствии с просьбой, вот конструктор для ThreadPoolExecutor.

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

После дальнейшего тестирования я могу видеть, что если я позволяю задачи, которые были представлены до конца ThreadPoolExecutor, то нет никакой утечки.Если я пытаюсь отменить их в любом случае, такие как:

shutdownNow() 

или сохранить ссылку на будущее и призывая отменить на нее позже:

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

Или удаляя их из очереди с помощью методов, таких как:

getQueue.drainTo(someList) 

или

getQueue.clear() 

или Перебор сохраненных ссылок на фьючерсы и вызов:

getQueue.remove(task) 

Любой из этих случаев приводит к тому, FutureTask придерживаться вокруг, как описано выше.

Таким образом, реальный вопрос во всем этом - как правильно отменить или удалить элементы из ThreadPoolExecutor, чтобы FutureTask собирал мусор и не просачивался навсегда?

Answer 1

Я не мог получить что-нибудь работать, так что я придумал следующее решение. Вот приблизительный обзор: я создал массив в ThreadPoolExecutor, который отслеживал исполняемые файлы, которые были в очереди. Затем, когда мне нужно было отменить очередь, я зациклился и вызвал метод отмены для каждой из runnables. В моем случае все эти runnables были настраиваемым классом, который я создал, и их метод отмены просто установил отмененный флаг. Когда очередь запустила следующий процесс для обработки, в ходе запуска он увидел, что он был отменен и пропустил фактическую работу.

Таким образом, все рабочие столы затем просто быстро смываются один за другим, поскольку он видит, что он был отменен.

Возможно, это не самое большое решение, но оно работает для меня, и это не утечка памяти.

Answer 2

В работе вокруг вы могли бы сделать что-то вроде:

class ClearingCallable<T> implements Callable<T> { 
    Callable<T> delegate; 
    ClearingCallable(Callable<T> delegate) { 
     this.delegate = delegate; 
    } 

    T call() { 
     try { 
      return delegate.call(); 
     } finally { 
      delegate = null; 
     } 
    } 
} 

Answer 3

Согласно this post, вы можете позвонить по телефону purge об исполнителе.

Answer 4

См: https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html

Будущее представляет собой результат асинхронных вычислений. Если результат не будет получен с помощью метода get, произойдет утечка памяти!

Если вы не хотите использовать асинхронный результат, используйте Runnable install Callable.