Функция отмены в java ThreadPool. Обнаружение определенного исполняемого файла в пуле и отмена его.

У меня есть ThreadPool в моем приложении для Android, где я запускаю в нем кучу потоков в разных ситуациях.

public class ThreadPoolExecuter {

    private final ExecutorService mExecuter;
    private static final int nThreads = 5;

    private ThreadPoolExecuter() { 
        this.mExecuter = Executors.newFixedThreadPool(nThreads);
    }

Java ThreadPool не имеет значения по умолчанию для отмены потока. Одним из решений, о котором я думал, было сохранение пар ключ-значение Future, когда я отправляю исполняемый файл.

public void add(Runnable runnable) {
    Future<?> future = this.mExecuter.submit(runnable);
    // Add future to my key-value pairs
    if(Constant.DEBUG) Log.d(TAG, "Task submitted.");
}

И затем есть функция отмены:

public boolean cancel(KEY) {
   Future<?> future = map.get(KEY)
   return future.cancel(mayInterruptIfRunning);
}

Скажем, HashMap. Значение — это будущее, а как насчет ключа? 1) Что вы предлагаете?

Map<Key, Future<?>> map = new HashMap()<key, Future<?>>;

Что касается ключа, я подумал о передаче идентификатора для каждого исполняемого файла следующим образом:

2) что вы думаете об этом решении?

Но я хотел бы упомянуть, что в моем классе runnable иногда я сталкивался с InterruptedException. Есть ли способ избежать этого?

class Runner implements Runnable {

    private int id;

    public Runner(int id) {
        this.id = id;
    }

    @Override
    public void run() {

        System.out.println("Starting " + id);
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            System.out.println("Crashed on:" + Thread.currentThread().getId());
        }
        System.out.println("ending " + id);
    }
}

3) В конце я хочу добавить, что для меня важно знать какое-либо лучшее решение, с вашей точки зрения, для разработки функции отмены в java ThreadPool?

Обратите внимание, что я не ищу замену своему ThreadPool, например AsyncTask в Android, который имеет отмену по умолчанию.


person Ali    schedule 30.05.2014    source источник
comment
Почему вы хотите иметь KEY вместо фактического Future?   -  person pingw33n    schedule 30.05.2014
comment
В пуле может быть куча потоков. this.mExecuter = Executors.newFixedThreadPool(nThreads); Я хочу обнаружить одну из них и отменить ее, пока другие работают нормально.   -  person Ali    schedule 30.05.2014
comment
Это то, для чего нужен экземпляр Future, вам не нужно добавлять еще один уровень косвенности, если вам не нужно выставлять его за пределы JVM.   -  person pingw33n    schedule 30.05.2014
comment
Хорошо, так что, может быть, я могу сохранить список Future (List‹Future‹?››) в своем классе ThreadPool. Иногда я сталкивался с InterruptedException, знаете, как его избежать? (это просто иногда)   -  person Ali    schedule 30.05.2014
comment
Почему вы хотите сохранить список? Вам в какой-то момент нужно отменить все задачи сразу? О том, как обрабатывать InterrputedException, см.: stackoverflow.com/questions/3976344/< /а>   -  person pingw33n    schedule 30.05.2014
comment
Да, возможно, единственный смысл вести список — отменить все задачи сразу. Но, возможно, shutdownNow будет лучшим вариантом. Спасибо за ссылку.   -  person Ali    schedule 30.05.2014
comment
Определенно shutdownNow с правильно обработанными InterrputedException - это то, что нужно.   -  person pingw33n    schedule 30.05.2014
comment
@ pingw33n, вы можете поделиться своим ответом, чтобы я мог отметить его как принятый.   -  person Ali    schedule 09.06.2014


Ответы (2)


Поскольку вашей основной потребностью является возможность одновременной отмены всех запущенных задач, вы должны иметь возможность использовать shutdownNow() из ExecutorService. Реализации ExecutorService по умолчанию будут вызывать Thread.interrupt(), чтобы прервать запущенные потоки, поэтому вы должны правильно обрабатывать InterrputedException (закрывая все используемые ресурсы и выходя из потока).

person pingw33n    schedule 11.06.2014

Как правило, отмена потоков из-за пределов самого потока сопряжена со всевозможными рисками, которые на первый взгляд не очевидны. Более безопасный подход состоит в том, чтобы поток при запуске проверял, нужно ли ему все еще работать.

person Tim B    schedule 30.05.2014