Неможливо зробити кешований пул ниток з обмеженням розміру?

Здається, неможливо зробити кешований пул потоків з обмеженням кількості потоків, які він може створити.

Ось як статичний Executors.newCchedThreadPool реалізований у стандартній бібліотеці Java:

 public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable>());
}

Отже, використовуючи цей шаблон, щоб продовжити, щоб створити кешований пул потоків фіксованого розміру:

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new SynchronusQueue<Runable>());

Тепер якщо ви скористаєтесь цим і подасте 3 завдання, все буде добре. Якщо подати будь-які подальші завдання, це призведе до відхилених винятків виконання.

Спробуйте це:

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runable>());

У результаті всі потоки будуть виконані послідовно. Тобто пул потоків ніколи не складе більше ніж один потік для обробки ваших завдань.

Це помилка в методі Execute ThreadPoolExecutor? А може, це навмисно? Або є якийсь інший шлях?

Редагувати: я хочу щось точно схоже на пул кешованих ниток (він створює нитки на вимогу, а потім вбиває їх через деякий час очікування), але з обмеженням кількості потоків, які він може створити, і можливість продовжувати чергувати додаткові завдання після того, як у нього з'явиться досягти межі потоку. Відповідно до відповіді sjlee, це неможливо. Дивлячись на метод Execute () ThreadPoolExecutor, це справді неможливо. Мені потрібно підкласифікувати ThreadPoolExecutor і переосмислити Execute (), як SwingWorker, але те, що SwingWorker робить у його Execute (), є повним хаком.

ThreadPoolExecutor має наступні ключові форми поведінки, і ваші проблеми можуть бути пояснені цими поведінками.

Коли завдання подано,

1. Якщо пул потоків не досяг основного розміру, він створює нові потоки.
2. Якщо розмір основного ядра досягнуто, і в ньому немає порожніх потоків, вони ставлять черги із завданнями.
3. Якщо розмір основного ядра досягнуто, недіючі потоки відсутні, і черга стає повною, вона створює нові потоки (поки не досягне максимального розміру).
4. Якщо максимальний розмір досягнуто, недіючі потоки відсутні, і черга стає повною, починається політика відхилення.

У першому прикладі зауважте, що SynchronousQueue має по суті розмір 0. Тому, коли ви досягнете максимального розміру (3), політика відхилення починається (# 4).

У другому прикладі вибір черги - LinkedBlockingQueue, який має необмежений розмір. Тому ти зациклюєшся на поведінці №2.

Насправді не можна багато повозитися з кешованим або фіксованим типом, оскільки їх поведінка майже повністю визначена.

Якщо ви хочете мати обмежений і динамічний пул потоків, вам потрібно використовувати позитивний розмір ядра та максимальний розмір у поєднанні з чергою обмеженого розміру. Наприклад,

new ThreadPoolExecutor(10, // core size
    50, // max size
    10*60, // idle timeout
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<Runnable>(20)); // queue with a size

Додаток : це досить стара відповідь, і, схоже, JDK змінив свою поведінку, коли мова йде про розмір ядра 0. Оскільки JDK 1.6, якщо розмір ядра дорівнює 0 і пул не має жодних потоків, ThreadPoolExecutor додасть нитка для виконання цього завдання. Тому розмір ядра 0 - це виняток із правила, наведеного вище. Завдяки Steve для чого , що мою увагу.

Якщо я щось не пропустив, рішення оригінального питання просте. Наступний код реалізує бажану поведінку, як описано в оригінальному плакаті. Він породжує до 5 потоків для роботи над необмеженою чергою, а холості потоки припиняться через 60 секунд.

tp = new ThreadPoolExecutor(5, 5, 60, TimeUnit.SECONDS,
                    new LinkedBlockingQueue<Runnable>());
tp.allowCoreThreadTimeOut(true);

Мав те саме питання. Оскільки жодна інша відповідь не поєднує всі питання разом, я додаю своє:

Тепер це чітко написано в документах : Якщо ви використовуєте чергу, яка не блокує ( LinkedBlockingQueue) налаштування максимуму нитки не має ефекту, використовуються лише основні потоки.

так:

public class MyExecutor extends ThreadPoolExecutor {

    public MyExecutor() {
        super(4, 4, 5,TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>());
        allowCoreThreadTimeOut(true);
    }

    public void setThreads(int n){
        setMaximumPoolSize(Math.max(1, n));
        setCorePoolSize(Math.max(1, n));
    }

}

Цей виконавець має:

1. Немає поняття максимальних потоків, оскільки ми використовуємо необмежену чергу. Це добре, адже така черга може призвести до того, щоб виконавець створив величезну кількість непрофільних, зайвих потоків, якщо він дотримується звичної політики.

2. Черга з максимальним розміром Integer.MAX_VALUE. Submit()буде кинутий, RejectedExecutionExceptionякщо кількість очікуваних завдань перевищує Integer.MAX_VALUE. Не впевнений, що спочатку у нас залишиться пам'ять, або це станеться.

3. Можливо 4 основних потоків. Прості основні потоки автоматично виходять з режиму очікування протягом 5 секунд. Так, так, суворо за потребою потоки. Кількість можна змінити за допомогою setThreads()методу.

4. Переконайтесь, що мінімальна кількість основних потоків ніколи не менше однієї, інакше submit()відхилить кожне завдання. Оскільки основними потоками повинні бути> = max потоки, метод також setThreads()встановлює max потоки, хоча налаштування max потоку марно для безмежної черги.

У вашому першому прикладі наступні завдання відхиляються, оскільки AbortPolicyце за замовчуванням RejectedExecutionHandler. ThreadPoolExecutor містить такі політики, які можна змінити за допомогою setRejectedExecutionHandlerметоду:

CallerRunsPolicy
AbortPolicy
DiscardPolicy
DiscardOldestPolicy

Це здається, що вам потрібно кешований пул потоків з CallerRunsPolicy.

Жоден з відповідей тут не вирішив мою проблему, яка була пов'язана зі створенням обмеженої кількості HTTP-з'єднань за допомогою HTTP-клієнта Apache (версія 3.x). Оскільки мені знадобилося кілька годин, щоб з'ясувати гарне налаштування, я поділюся:

private ExecutorService executor = new ThreadPoolExecutor(5, 10, 60L,
  TimeUnit.SECONDS, new SynchronousQueue<Runnable>(),
  Executors.defaultThreadFactory(), new ThreadPoolExecutor.CallerRunsPolicy());

Це створює a ThreadPoolExecutor що починається з п'яти і вміщує максимум десять одночасно запущених потоків, що використовуються CallerRunsPolicyдля виконання.

Відповідно до Javadoc для ThreadPoolExecutor:

Якщо запущено більше, ніж corePoolSize, але менше максимального потокуPoolSize, новий потік буде створений, лише якщо черга заповнена . Встановивши corePoolSize та максимальнийPoolSize того самого, ви створюєте пул потоків фіксованого розміру.

(Наголос мій.)

Відповідь джиттера - це те, що ви хочете, хоча моя відповідає на ваше інше питання. :)

є ще один варіант. Замість використання нового SynchronousQueue ви можете також використовувати будь-яку іншу чергу, але ви повинні переконатися, що її розмір дорівнює 1, так що змусить виконавець служби створити новий потік.

Не схоже, що будь-який з відповідей насправді відповідає на питання - насправді я не бачу способу цього зробити, - навіть якщо ви підклас з PooledExecutorService, оскільки багато методів / властивостей є приватними, наприклад, щоб зробити addIfUnderMaximumPoolSize захищеним ви можете зробіть наступне:

class MyThreadPoolService extends ThreadPoolService {
    public void execute(Runnable run) {
        if (poolSize() == 0) {
            if (addIfUnderMaximumPoolSize(run) != null)
                return;
        }
        super.execute(run);
    }
}

Найближче мені це було - але навіть це не дуже вдале рішення

new ThreadPoolExecutor(min, max, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>()) {
    public void execute(Runnable command) {
        if (getPoolSize() == 0 && getActiveCount() < getMaximumPoolSize()) {        
            super.setCorePoolSize(super.getCorePoolSize() + 1);
        }
        super.execute(command);
    }

    protected void afterExecute(Runnable r, Throwable t) {
         // nothing in the queue
         if (getQueue().isEmpty() && getPoolSize() > min) {
             setCorePoolSize(getCorePoolSize() - 1);
         }
    };
 };

ps не перевірено вище

Ось ще одне рішення. Я думаю, що це рішення поводиться так, як ви цього хочете (хоча цим рішенням не пишаюся):

final LinkedBlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>() {
    public boolean offer(Runnable o) {
        if (size() > 1)
            return false;
        return super.offer(o);
    };

    public boolean add(Runnable o) {
        if (super.offer(o))
            return true;
        else
            throw new IllegalStateException("Queue full");
    }
};

RejectedExecutionHandler handler = new RejectedExecutionHandler() {         
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        queue.add(r);
    }
};

dbThreadExecutor =
        new ThreadPoolExecutor(min, max, 60L, TimeUnit.SECONDS, queue, handler);

Це те, що ти хочеш (принаймні, мабуть, так). Для пояснення перевірте відповідь Джонатана Фейнберга

Executors.newFixedThreadPool(int n)

Створює пул потоків, який повторно використовує фіксовану кількість потоків, що працюють поза спільною необмеженою чергою. У будь-якій точці, щонайбільше nThreads буде активним завданням обробки. Якщо додаткові завдання будуть подані, коли всі потоки активні, вони будуть чекати в черзі, поки нитка не буде доступною. Якщо будь-який потік припиняється через збій під час виконання перед відключенням, новий зайняє своє місце, якщо потрібно для виконання подальших завдань. Нитки в пулі існуватимуть до тих пір, поки воно не буде явно закрито.

1. Ви можете використовувати, ThreadPoolExecutorяк запропонував @sjlee

   Ви можете динамічно контролювати розмір пулу. Погляньте на це питання для більш детальної інформації:

   Динамічний басейн з нитками

   АБО

2. Ви можете використовувати API APIWWWSSTALINGPool , який був представлений з java 8.

   public static ExecutorService newWorkStealingPool()

   Створює пул потоків крадіжок роботи, використовуючи всі доступні процесори як його цільовий рівень паралелізму.

За замовчуванням рівень паралелізму встановлюється на кількість ядер CPU на вашому сервері. Якщо у вас є 4-х основний сервер центрального процесора, розмір пулу потоків буде дорівнює 4. Цей API повертає ForkJoinPoolтип ExecutorService і дозволяє працювати з крадінням порожніх потоків шляхом крадіжки завдань із зайнятих потоків у ForkJoinPool.

Проблема була зведена так:

Я хочу щось точно схоже на пул кешованих потоків (він створює нитки на вимогу, а потім вбиває їх через деякий час очікування), але з обмеженням кількості потоків, які він може створити, і можливістю продовжувати чергувати додаткові завдання, як тільки вдарив межа потоку.

Перш ніж вказати на рішення, я поясню, чому такі рішення не працюють:

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new SynchronousQueue<>());

Це не стане чергою жодних завдань, коли буде досягнуто ліміт 3, оскільки SynchronousQueue, за визначенням, не може містити жодних елементів.

new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>());

Це не створить більше одного потоку, тому що ThreadPoolExecutor створює лише теми, що перевищують corePoolSize, якщо черга заповнена. Але черга LinkedBlockingQue ніколи не заповнена.

ThreadPoolExecutor executor = new ThreadPoolExecutor(3, 3, 60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<Runnable>());
executor.allowCoreThreadTimeOut(true);

Це не використовуватиме повторно теми, поки не буде досягнуто corePoolSize, оскільки ThreadPoolExecutor збільшує кількість потоків, поки не буде досягнуто corePoolSize, навіть якщо існуючі потоки не працюють. Якщо ви можете жити з цим недоліком, то це найпростіше рішення проблеми. Це також рішення, описане в "Конкурсі Java на практиці" (виноска на с. 172).

Єдиним повним рішенням описаної проблеми, здається, є те, що включає переосмислення offerметоду черги та написання а, RejectedExecutionHandlerяк пояснено у відповідях на це питання: Як змусити ThreadPoolExecutor збільшити нитки до max перед чергою?

Це працює для Java8 + (та інших, поки що ..)

     Executor executor = new ThreadPoolExecutor(3, 3, 5, TimeUnit.SECONDS,
                new LinkedBlockingQueue<>()){{allowCoreThreadTimeOut(true);}};

де 3 - обмеження кількості потоків, а 5 - тайм-аут для непрацюючих потоків.

Якщо ви хочете перевірити, чи працює він самостійно , ось код, який потрібно виконати:

public static void main(String[] args) throws InterruptedException {
    final int DESIRED_NUMBER_OF_THREADS=3; // limit of number of Threads for the task at a time
    final int DESIRED_THREAD_IDLE_DEATH_TIMEOUT=5; //any idle Thread ends if it remains idle for X seconds

    System.out.println( java.lang.Thread.activeCount() + " threads");
    Executor executor = new ThreadPoolExecutor(DESIRED_NUMBER_OF_THREADS, DESIRED_NUMBER_OF_THREADS, DESIRED_THREAD_IDLE_DEATH_TIMEOUT, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>()) {{allowCoreThreadTimeOut(true);}};

    System.out.println(java.lang.Thread.activeCount() + " threads");

    for (int i = 0; i < 5; i++) {
        final int fi = i;
        executor.execute(() -> waitsout("starting hard thread computation " + fi, "hard thread computation done " + fi,2000));
    }
    System.out.println("If this is UP, it works");

    while (true) {
        System.out.println(
                java.lang.Thread.activeCount() + " threads");
        Thread.sleep(700);
    }

}

static void waitsout(String pre, String post, int timeout) {
    try {
        System.out.println(pre);
        Thread.sleep(timeout);
        System.out.println(post);
    } catch (Exception e) {
    }
}

Вихід коду вище для мене - це

1 threads
1 threads
If this is UP, it works
starting hard thread computation 0
4 threads
starting hard thread computation 2
starting hard thread computation 1
4 threads
4 threads
hard thread computation done 2
hard thread computation done 0
hard thread computation done 1
starting hard thread computation 3
starting hard thread computation 4
4 threads
4 threads
4 threads
hard thread computation done 3
hard thread computation done 4
4 threads
4 threads
4 threads
4 threads
3 threads
3 threads
3 threads
1 threads
1 threads