Як зробити блок методу submit () ThreadPoolExecutor, якщо він насичений?

Я хочу створити ThreadPoolExecutorтаке, що коли він досяг максимального розміру і черга заповнена, submit()метод блокується при спробі додати нові завдання. Чи потрібно мені реалізувати RejectedExecutionHandlerдля цього користувацький звичай чи існує існуючий спосіб зробити це за допомогою стандартної бібліотеки Java?

Одне з можливих рішень, які я щойно знайшов:

public class BoundedExecutor {
    private final Executor exec;
    private final Semaphore semaphore;

    public BoundedExecutor(Executor exec, int bound) {
        this.exec = exec;
        this.semaphore = new Semaphore(bound);
    }

    public void submitTask(final Runnable command)
            throws InterruptedException, RejectedExecutionException {
        semaphore.acquire();
        try {
            exec.execute(new Runnable() {
                public void run() {
                    try {
                        command.run();
                    } finally {
                        semaphore.release();
                    }
                }
            });
        } catch (RejectedExecutionException e) {
            semaphore.release();
            throw e;
        }
    }
}

Чи є інші рішення? Я вважаю за краще щось на основі, RejectedExecutionHandlerоскільки це здається стандартним способом вирішення подібних ситуацій.

Ви можете використовувати ThreadPoolExecutor та блокуючу чергу:

public class ImageManager {
    BlockingQueue<Runnable> blockingQueue = new ArrayBlockingQueue<Runnable>(blockQueueSize);
    RejectedExecutionHandler rejectedExecutionHandler = new ThreadPoolExecutor.CallerRunsPolicy();
    private ExecutorService executorService =  new ThreadPoolExecutor(numOfThread, numOfThread, 
        0L, TimeUnit.MILLISECONDS, blockingQueue, rejectedExecutionHandler);

    private int downloadThumbnail(String fileListPath){
        executorService.submit(new yourRunnable());
    }
}

Вам слід скористатись тим CallerRunsPolicy, що виконує відхилене завдання у виклику. Таким чином, він не може подати виконавцю будь-які нові завдання до тих пір, поки це завдання не буде виконано, після чого з’являться кілька вільних ниток пулу або процес повториться.

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.CallerRunsPolicy.html

З документів:

Відхилені завдання

Нові завдання, представлені у методі Execute (java.lang.Runnable), будуть відхилені, коли Виконавець вимкнений, а також коли Виконавець використовує обмежені межі як для максимальних потоків, так і для ємності робочої черги, і є насиченим. У будь-якому випадку метод Execute викликає метод RejectedExecutionHandler.rejectedExecution (java.lang.Runnable, java.util.concurrent.ThreadPoolExecutor) методу його RejectedExecutionHandler. Надано чотири заздалегідь визначені політики обробника:

1. У програмі ThreadPoolExecutor.AbortPolicy за замовчуванням обробник кидає програму RejectedExecutionException за умови відхилення.
2. У ThreadPoolExecutor.CallerRunsPolicy нитка, яка викликає виконання, сама виконує завдання. Це забезпечує простий механізм контролю зворотного зв'язку, який уповільнить швидкість подання нових завдань.
3. У ThreadPoolExecutor.DiscardPolicy завдання, яке неможливо виконати, просто відкидається.
4. У ThreadPoolExecutor.DiscardOldestPolicy, якщо виконавець не вимкнений, завдання на чолі робочої черги опускається, а потім виконання повторюється (що може знову не вдатися, внаслідок чого це повториться.)

Також обов'язково використовуйте обмежену чергу, наприклад ArrayBlockingQueue, при виклику ThreadPoolExecutor конструктора. Інакше нічого не буде відхилено.

Редагувати: у відповідь на ваш коментар встановіть розмір черги ArrayBlockingQue, що дорівнює максимальному розміру пулу потоків, і використовуйте AbortPolicy.

Редагування 2: Гаразд, я бачу, до чого ти потрапляєш Що з цього приводу: замініть beforeExecute()метод, щоб перевірити, getActiveCount()чи не перевищує його getMaximumPoolSize(), і якщо він є, сплять і спробуйте ще раз?

У сплячому режимі BlockPolicyце просто і може робити те, що ви хочете:

Дивіться: Виконавці.java

/**
 * A handler for rejected tasks that will have the caller block until
 * space is available.
 */
public static class BlockPolicy implements RejectedExecutionHandler {

    /**
     * Creates a <tt>BlockPolicy</tt>.
     */
    public BlockPolicy() { }

    /**
     * Puts the Runnable to the blocking queue, effectively blocking
     * the delegating thread until space is available.
     * @param r the runnable task requested to be executed
     * @param e the executor attempting to execute this task
     */
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
        try {
            e.getQueue().put( r );
        }
        catch (InterruptedException e1) {
            log.error( "Work discarded, thread was interrupted while waiting for space to schedule: {}", r );
        }
    }
}

BoundedExecutorВідповідь Наведений вище від Java Паралелізм на практиці працює тільки якщо ви використовуєте необмежену чергу для Виконавця, або семафор пов'язаний не більше , ніж розмір черги. Семафор поділяється між потоком, що подає, і потоками в пулі, що дозволяє наситити виконавця, навіть якщо розмір черги <пов'язаний <= (розмір черги + розмір пулу).

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

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

Я знаю, це хакер, але, на мій погляд, найчистіший злом між запропонованими тут ;-)

Оскільки ThreadPoolExecutor використовує блоку чергу "пропозиція" замість "поставити", дозволяє переосмислити поведінку "пропозиції" черзі блокування:

class BlockingQueueHack<T> extends ArrayBlockingQueue<T> {

    BlockingQueueHack(int size) {
        super(size);
    }

    public boolean offer(T task) {
        try {
            this.put(task);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
        return true;
    }
}

ThreadPoolExecutor tp = new ThreadPoolExecutor(1, 2, 1, TimeUnit.MINUTES, new BlockingQueueHack(5));

Я перевірив це і, здається, працює. Реалізація певної політики тайм-ауту залишається вправою для читання.

Наступний клас обертається навколо ThreadPoolExecutor і використовує Semaphore для блокування, тоді черга роботи заповнена:

public final class BlockingExecutor { 

    private final Executor executor;
    private final Semaphore semaphore;

    public BlockingExecutor(int queueSize, int corePoolSize, int maxPoolSize, int keepAliveTime, TimeUnit unit, ThreadFactory factory) {
        BlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>();
        this.executor = new ThreadPoolExecutor(corePoolSize, maxPoolSize, keepAliveTime, unit, queue, factory);
        this.semaphore = new Semaphore(queueSize + maxPoolSize);
    }

    private void execImpl (final Runnable command) throws InterruptedException {
        semaphore.acquire();
        try {
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    try {
                        command.run();
                    } finally {
                        semaphore.release();
                    }
                }
            });
        } catch (RejectedExecutionException e) {
            // will never be thrown with an unbounded buffer (LinkedBlockingQueue)
            semaphore.release();
            throw e;
        }
    }

    public void execute (Runnable command) throws InterruptedException {
        execImpl(command);
    }
}

Цей клас обгортки базується на рішенні, поданому в книзі Брайана Геца в книзі Java Concurrency in Practice. Рішення в книзі приймає лише два конструкторські параметри: a Executorі обмежений, що використовується для семафору. Це показано у відповіді, наданій Fixpoint. У цьому підході є проблема: він може потрапити в стан, коли нитки пулу зайняті, черга повна, але семафор щойно видав дозвіл. (semaphore.release() в остаточному блоці). У такому стані нове завдання може захопити щойно випущений дозвіл, але його відхилено, оскільки черга завдань заповнена. Звичайно, це не те, чого ти хочеш; ви хочете заблокувати в цьому випадку.

Щоб вирішити це, ми повинні використовувати необмежену чергу, як чітко згадує JCiP. Семафор діє як охорона, надаючи ефект розміру віртуальної черги. Це побічно впливає на те, що цілком можливо, що підрозділ може містити maxPoolSize + virtualQueueSize + maxPoolSizeзавдання. Чому так? Через те, semaphore.release()що, нарешті, блок. Якщо всі потоки пулу викликають цей вислів одночасно, тоді maxPoolSizeдозволу звільняються, дозволяючи однаковій кількості завдань входити в блок. Якби ми використовували обмежену чергу, вона все одно буде повною, що призведе до відхиленого завдання. Тепер, оскільки ми знаємо, що це відбувається лише тоді, коли нитка пулу майже виконана, це не проблема. Ми знаємо, що нитка пулу не блокується, тому незабаром буде взято завдання з черги.

Однак ви можете використовувати обмежену чергу. Просто переконайтесь, що його розмір дорівнює virtualQueueSize + maxPoolSize. Більший розмір марний, семафор не дозволить пускати більше предметів. Менші розміри призводять до відхилених завдань. Шанс відхилення завдань збільшується зі зменшенням розміру. Наприклад, скажіть, що ви хочете обмеженого виконавця з maxPoolSize = 2 та virtualQueueSize = 5. Потім візьміть семафор з 5 + 2 = 7 дозволів і фактичним розміром черги 5 + 2 = 7. Реальна кількість завдань, які можуть бути в підрозділі, становить 2 + 5 + 2 = 9. Коли виконавець заповнений (5 завдань у черзі, 2 у пулі потоків, тому доступно 0 дозволів) та ВСІ нитки пулу випускають свої дозволи, то рівно 2 дозволу можуть бути отримані завданнями, що надходять.

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

ви можете використовувати спеціальний RejectedExecutionHandler, як це

ThreadPoolExecutor tp= new ThreadPoolExecutor(core_size, // core size
                max_handlers, // max size 
                timeout_in_seconds, // idle timeout 
                TimeUnit.SECONDS, queue, new RejectedExecutionHandler() {
                    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
                        // This will block if the queue is full
                        try {
                            executor.getQueue().put(r);
                        } catch (InterruptedException e) {
                            System.err.println(e.getMessage());
                        }

                    }
                });

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

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

Щоб уникнути проблем із рішенням @FixPoint Можна використати ListeningExecutorService і випустити семафор onSuccess і onFailure всередині FutureCallback.

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

Читаючи всі відповіді та коментарі, зокрема хибне рішення семафору або використовуючи, afterExecuteя детальніше ознайомився з кодом ThreadPoolExecutor, щоб побачити, чи є вихід. Я був здивований, побачивши, що існує понад 2000 рядків (коментованого) коду, деякі з яких викликають запаморочення . Враховуючи досить просту вимогу, яку я насправді маю --- один виробник, кілька споживачів, нехай виробник блокує, коли жоден споживач не може взяти на роботу --- я вирішив прийняти власне рішення. Це не ExecutorServiceпросто, а просто Executor. І вона не пристосовує кількість ниток до робочого навантаження, а вміщує лише фіксовану кількість ниток, що також відповідає моїм вимогам. Ось код. Не соромтеся зважати на це :-)

package x;

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.Executor;
import java.util.concurrent.RejectedExecutionException;
import java.util.concurrent.SynchronousQueue;

/**
 * distributes {@code Runnable}s to a fixed number of threads. To keep the
 * code lean, this is not an {@code ExecutorService}. In particular there is
 * only very simple support to shut this executor down.
 */
public class ParallelExecutor implements Executor {
  // other bounded queues work as well and are useful to buffer peak loads
  private final BlockingQueue<Runnable> workQueue =
      new SynchronousQueue<Runnable>();
  private final Thread[] threads;

  /*+**********************************************************************/
  /**
   * creates the requested number of threads and starts them to wait for
   * incoming work
   */
  public ParallelExecutor(int numThreads) {
    this.threads = new Thread[numThreads];
    for(int i=0; i<numThreads; i++) {
      // could reuse the same Runner all over, but keep it simple
      Thread t = new Thread(new Runner());
      this.threads[i] = t;
      t.start();
    }
  }
  /*+**********************************************************************/
  /**
   * returns immediately without waiting for the task to be finished, but may
   * block if all worker threads are busy.
   * 
   * @throws RejectedExecutionException if we got interrupted while waiting
   *         for a free worker
   */
  @Override
  public void execute(Runnable task)  {
    try {
      workQueue.put(task);
    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
      throw new RejectedExecutionException("interrupt while waiting for a free "
          + "worker.", e);
    }
  }
  /*+**********************************************************************/
  /**
   * Interrupts all workers and joins them. Tasks susceptible to an interrupt
   * will preempt their work. Blocks until the last thread surrendered.
   */
  public void interruptAndJoinAll() throws InterruptedException {
    for(Thread t : threads) {
      t.interrupt();
    }
    for(Thread t : threads) {
      t.join();
    }
  }
  /*+**********************************************************************/
  private final class Runner implements Runnable {
    @Override
    public void run() {
      while (!Thread.currentThread().isInterrupted()) {
        Runnable task;
        try {
          task = workQueue.take();
        } catch (InterruptedException e) {
          // canonical handling despite exiting right away
          Thread.currentThread().interrupt(); 
          return;
        }
        try {
          task.run();
        } catch (RuntimeException e) {
          // production code to use a logging framework
          e.printStackTrace();
        }
      }
    }
  }
}

Я вважаю, що існує досить елегантний спосіб вирішити цю проблему за допомогою java.util.concurrent.Semaphoreта делегування поведінки Executor.newFixedThreadPool. Нова служба виконавця виконує нове завдання лише тоді, коли для цього є потік. Блокування управляється Semaphore з кількістю дозволів, рівним кількості потоків. Коли завдання закінчено, він повертає дозвіл.

public class FixedThreadBlockingExecutorService extends AbstractExecutorService {

private final ExecutorService executor;
private final Semaphore blockExecution;

public FixedThreadBlockingExecutorService(int nTreads) {
    this.executor = Executors.newFixedThreadPool(nTreads);
    blockExecution = new Semaphore(nTreads);
}

@Override
public void shutdown() {
    executor.shutdown();
}

@Override
public List<Runnable> shutdownNow() {
    return executor.shutdownNow();
}

@Override
public boolean isShutdown() {
    return executor.isShutdown();
}

@Override
public boolean isTerminated() {
    return executor.isTerminated();
}

@Override
public boolean awaitTermination(long timeout, TimeUnit unit) throws InterruptedException {
    return executor.awaitTermination(timeout, unit);
}

@Override
public void execute(Runnable command) {
    blockExecution.acquireUninterruptibly();
    executor.execute(() -> {
        try {
            command.run();
        } finally {
            blockExecution.release();
        }
    });
}

У мене була така ж потреба в минулому: свого роду блокування черги з фіксованим розміром для кожного клієнта, підкріпленого спільним пулом потоків. Я закінчив писати власний вид ThreadPoolExecutor:

UserThreadPoolExecutor (блокування черги (на клієнта) + нитка путівки (спільне для всіх клієнтів))

Дивіться: https://github.com/d4rxh4wx/UserThreadPoolExecutor

Кожному UserThreadPoolExecutor надається максимальна кількість потоків із спільного ThreadPoolExecutor

Кожен UserThreadPoolExecutor може:

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

Я знайшов цю політику відхилення в еластичному пошуку клієнта. Він блокує нитку абонента в черзі блокування. Код нижче-

 static class ForceQueuePolicy implements XRejectedExecutionHandler 
 {
        public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) 
        {
            try 
            {
                executor.getQueue().put(r);
            } 
            catch (InterruptedException e) 
            {
                //should never happen since we never wait
                throw new EsRejectedExecutionException(e);
            }
        }

        @Override
        public long rejected() 
        {
            return 0;
        }
}

Нещодавно у мене виникла потреба домогтися чогось подібного, але на меті ScheduledExecutorService .

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

Інші методи ScheduledThreadPoolExecutorдля виконання або подання завдання на внутрішній виклик, #scheduleякий все ще в свою чергу викликає переосмислені методи.

import java.util.concurrent.*;

public class BlockingScheduler extends ScheduledThreadPoolExecutor {
    private final Semaphore maxQueueSize;

    public BlockingScheduler(int corePoolSize,
                             ThreadFactory threadFactory,
                             int maxQueueSize) {
        super(corePoolSize, threadFactory, new AbortPolicy());
        this.maxQueueSize = new Semaphore(maxQueueSize);
    }

    @Override
    public ScheduledFuture<?> schedule(Runnable command,
                                       long delay,
                                       TimeUnit unit) {
        final long newDelayInMs = beforeSchedule(command, unit.toMillis(delay));
        return super.schedule(command, newDelayInMs, TimeUnit.MILLISECONDS);
    }

    @Override
    public <V> ScheduledFuture<V> schedule(Callable<V> callable,
                                           long delay,
                                           TimeUnit unit) {
        final long newDelayInMs = beforeSchedule(callable, unit.toMillis(delay));
        return super.schedule(callable, newDelayInMs, TimeUnit.MILLISECONDS);
    }

    @Override
    public ScheduledFuture<?> scheduleAtFixedRate(Runnable command,
                                                  long initialDelay,
                                                  long period,
                                                  TimeUnit unit) {
        final long newDelayInMs = beforeSchedule(command, unit.toMillis(initialDelay));
        return super.scheduleAtFixedRate(command, newDelayInMs, unit.toMillis(period), TimeUnit.MILLISECONDS);
    }

    @Override
    public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command,
                                                     long initialDelay,
                                                     long period,
                                                     TimeUnit unit) {
        final long newDelayInMs = beforeSchedule(command, unit.toMillis(initialDelay));
        return super.scheduleWithFixedDelay(command, newDelayInMs, unit.toMillis(period), TimeUnit.MILLISECONDS);
    }

    @Override
    protected void afterExecute(Runnable runnable, Throwable t) {
        super.afterExecute(runnable, t);
        try {
            if (t == null && runnable instanceof Future<?>) {
                try {
                    ((Future<?>) runnable).get();
                } catch (CancellationException | ExecutionException e) {
                    t = e;
                } catch (InterruptedException ie) {
                    Thread.currentThread().interrupt(); // ignore/reset
                }
            }
            if (t != null) {
                System.err.println(t);
            }
        } finally {
            releaseQueueUsage();
        }
    }

    private long beforeSchedule(Runnable runnable, long delay) {
        try {
            return getQueuePermitAndModifiedDelay(delay);
        } catch (InterruptedException e) {
            getRejectedExecutionHandler().rejectedExecution(runnable, this);
            return 0;
        }
    }

    private long beforeSchedule(Callable callable, long delay) {
        try {
            return getQueuePermitAndModifiedDelay(delay);
        } catch (InterruptedException e) {
            getRejectedExecutionHandler().rejectedExecution(new FutureTask(callable), this);
            return 0;
        }
    }

    private long getQueuePermitAndModifiedDelay(long delay) throws InterruptedException {
        final long beforeAcquireTimeStamp = System.currentTimeMillis();
        maxQueueSize.tryAcquire(delay, TimeUnit.MILLISECONDS);
        final long afterAcquireTimeStamp = System.currentTimeMillis();
        return afterAcquireTimeStamp - beforeAcquireTimeStamp;
    }

    private void releaseQueueUsage() {
        maxQueueSize.release();
    }
}

Я маю тут код, буду цінувати будь-які відгуки. https://github.com/AmitabhAwasthi/BlockingScheduler

Ось рішення, яке, здається, працює дуже добре. Це називається NotifyingBlockingThreadPoolExecutor .

Демонстраційна програма.

Редагувати: Виникла проблема з цим кодом, метод await () - помилка. Виключення виклику () + awaitTermina (), здається, працює добре.

Мені не завжди подобається CallerRunsPolicy, тим більше, що це дозволяє відхиленому завданню "пропустити чергу" і виконувати перед завданнями, які були подані раніше. Крім того, виконання завдання в потоці виклику може зайняти набагато більше часу, ніж очікування, коли перший слот стане доступним.

Я вирішив цю проблему за допомогою користувацького RejectedExecutionHandler, який просто блокує викликовий потік на деякий час, а потім знову намагається подати завдання:

public class BlockWhenQueueFull implements RejectedExecutionHandler {

    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {

        // The pool is full. Wait, then try again.
        try {
            long waitMs = 250;
            Thread.sleep(waitMs);
        } catch (InterruptedException interruptedException) {}

        executor.execute(r);
    }
}

Цей клас можна просто використовувати у виконанні пулових потоків як RejectedExecutinHandler, як і будь-який інший, наприклад:

executorPool = new ThreadPoolExecutor(1, 1, 10,
                                      TimeUnit.SECONDS, new SynchronousQueue<Runnable>(),
                                      new BlockWhenQueueFull());

Єдиний недолік, який я бачу, - це те, що виклична нитка може заблокуватися трохи довше, ніж суворо необхідно (до 250 мс). Більше того, оскільки цього виконавця ефективно викликають рекурсивно, дуже довге очікування появи потоку (години) може призвести до переповнення стека.

Тим не менш, мені особисто подобається цей метод. Це компактний, легкий для розуміння та добре працює.