ThreadPoolExecutor submit（）メソッドが飽和している場合にブロックする方法は？
ThreadPoolExecutorを作成して、最大サイズに達し、キューがいっぱいになったときに、submit()メソッドblocksで新しいタスクを追加しようとします。そのためにカスタムRejectedExecutionHandlerを実装する必要がありますか、または標準のJavaライブラリを使用してこれを行う既存の方法はありますか？
私が見つけた解決策の1つ：
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とblockingQueueを使用できます。
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を使用する必要があります。この方法では、そのタスクが完了するまでエグゼキューターに新しいタスクを送信できません。その時点で、いくつかの空きプールスレッドが存在するか、プロセスが繰り返されます。
ドキュメントから：
拒否されたタスク
メソッドexecute（Java.lang.Runnable）で送信された新しいタスクは、エグゼキューターがシャットダウンされたとき、およびエグゼキューターが最大スレッドとワークキュー容量の両方に有限の境界を使用し、飽和したときに拒否されます。どちらの場合でも、executeメソッドは、RejectedExecutionHandlerのRejectedExecutionHandler.rejectedExecution（Java.lang.Runnable、Java.util.concurrent.ThreadPoolExecutor）メソッドを呼び出します。 4つの事前定義されたハンドラポリシーが提供されます。
- デフォルトのThreadPoolExecutor.AbortPolicyでは、ハンドラーは拒否時にランタイムRejectedExecutionExceptionをスローします。
- ThreadPoolExecutor.CallerRunsPolicyでは、実行自体を呼び出すスレッドがタスクを実行します。これにより、新しいタスクが送信される速度を遅くする単純なフィードバック制御メカニズムが提供されます。
- ThreadPoolExecutor.DiscardPolicyでは、実行できないタスクは単純にドロップされます。
- ThreadPoolExecutor.DiscardOldestPolicyでは、executorがシャットダウンされない場合、作業キューの先頭にあるタスクが削除され、実行が再試行されます（これは再び失敗し、これが繰り返される可能性があります）。
また、ThreadPoolExecutorコンストラクターを呼び出すときは、ArrayBlockingQueueなどの制限されたキューを使用してください。そうでなければ、何も拒否されません。
編集：コメントに応じて、ArrayBlockingQueueのサイズをスレッドプールの最大サイズに等しくなるように設定し、AbortPolicyを使用します。
編集2：わかりました、あなたが何を得ているかわかります。これについては：beforeExecute()メソッドをオーバーライドして、getActiveCount()がgetMaximumPoolSize()を超えないことを確認し、超えている場合はスリープしてから再試行しますか？
これを行うには、4つの選択肢をチェックしてください。 NotifyingBlockingThreadPoolExecutorの作成
HibernateにはBlockPolicyがあり、これは単純で、必要なことを実行できます。
参照： Executors.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 );
}
}
}
Java Concurrency in Practiceから引用されたBoundedExecutorの回答は、エグゼキュータに無制限のキューを使用する場合、またはセマフォのバインドがキューサイズ以下の場合にのみ正しく機能します。セマフォはサブミットスレッドとプール内のスレッド間で共有される状態であり、キューサイズ<バインド<=（キューサイズ+プールサイズ）であってもエグゼキューターを飽和させることができます。
CallerRunsPolicyの使用は、タスクが永久に実行されない場合にのみ有効です。その場合、送信スレッドはrejectedExecutionに永久に残り、タスクの実行に時間がかかる場合は悪い考えです。送信スレッドは、新しいタスクを送信したり、タスク自体を実行している場合は他のことを実行できないためです。
それが受け入れられない場合は、タスクを送信する前に、エグゼキューターの境界キューのサイズを確認することをお勧めします。キューがいっぱいの場合は、少し待ってから再度送信してください。スループットは低下しますが、提案されている他の多くのソリューションよりも単純なソリューションであり、タスクが拒否されないことが保証されています。
私は知っています、それはハックですが、私の意見では、ここで提供されているものの中で最もクリーンなハックです;-)
ThreadPoolExecutorは「put」ではなくブロッキングキュー「offer」を使用するため、ブロッキングキューの「offer」の動作をオーバーライドできます。
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をラップし、セマフォを使用してブロックすると、作業キューがいっぱいになります。
_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);
}
}
_このラッパークラスは、Brian Goetzの本Java Concurrency in Practiceに記載されているソリューションに基づいています。本のソリューションは、Executorとboundこのアプローチには問題があります。プールスレッドがビジーで、キューがいっぱいの状態になる可能性がありますが、セマフォは許可を解放したばかりです。 （最終ブロックのsemaphore.release()）。この状態では、新しいタスクはリリースされたばかりの許可を取得できますが、タスクキューがいっぱいであるため拒否されます。この場合はブロックします。
これを解決するには、JCiPが明確に言及しているように、nboundedキューを使用する必要があります。セマフォはガードとして機能し、仮想キューサイズの影響を与えます。これには、ユニットに_maxPoolSize + virtualQueueSize + maxPoolSize_タスクを含めることができるという副作用があります。何故ですか？ finallyブロックの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());
}
}
});
この拒否ポリシーは、エラスティック検索クライアントで見つけました。ブロッキングキューで呼び出し元スレッドをブロックします。以下のコード-
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;
}
}
@FixPointソリューションの問題を回避するため。 ListeningExecutorServiceを使用して、FutureCallback内でセマフォonSuccessおよびonFailureを解放できます。
このリンク（notifying-blocking-thread-pool） をご覧ください。これはいくつかのソリューションを要約し、最終的に通知付きのエレガントなソリューションを提供します。
過去にも同じニーズがありました。共有スレッドプールに支えられた各クライアントのサイズが固定された一種のブロッキングキューです。私は自分の種類のThreadPoolExecutorを書くことになりました。
UserThreadPoolExecutor（ブロックキュー（クライアントごと）+スレッドプール（すべてのクライアント間で共有））
参照： https://github.com/d4rxh4wx/UserThreadPoolExecutor
各UserThreadPoolExecutorには、共有ThreadPoolExecutorから最大数のスレッドが与えられます
各UserThreadPoolExecutorは次のことができます。
- クォータに達していない場合は、共有スレッドプールエグゼキューターにタスクを送信します。クォータに達すると、ジョブはキューに入れられます（CPUを待機する非消費型ブロッキング）。送信されたタスクの1つが完了すると、クォータが減分され、ThreadPoolExecutorへの送信を待機している別のタスクが許可されます。
- 残りのタスクが完了するまで待ちます
特に拒否されたタスクが「キューをスキップする」ことができ、以前に送信されたタスクの前に実行されるため、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ミリ秒）。さらに、このエグゼキューターは事実上再帰的に呼び出されるため、スレッドが使用可能になるまでの非常に長い待機（時間）により、スタックオーバーフローが発生する可能性があります。
それにもかかわらず、私は個人的にこの方法が好きです。コンパクトで理解しやすく、うまく機能します。
Java.util.concurrent.Semaphoreを使用してExecutor.newFixedThreadPoolの動作を委任することで、この問題を解決する非常にエレガントな方法があると思います。新しいexecutorサービスは、実行するスレッドがある場合にのみ新しいタスクを実行します。ブロッキングは、スレッドの数に等しい許可の数でセマフォによって管理されます。タスクが完了すると、許可を返します。
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();
}
});
}
私は最近、似たようなことを達成する必要がありましたが、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 と呼ばれます。
編集：このコードには issue があり、await（）メソッドにはバグがあります。 shutdown（）+ awaitTermination（）の呼び出しは正常に機能するようです。
最近、この質問に同じ問題があることがわかりました。 OPは明示的には言いませんが、サブミッターのスレッドでタスクを実行するRejectedExecutionHandlerは使用しません。これは、このタスクが長時間実行されている場合、ワーカースレッドを十分に活用できないためです。
すべての回答とコメント、特にセマフォを使用した欠陥ソリューションまたはafterExecuteを使用して、 ThreadPoolExecutor のコードを詳しく見て、抜け道があるかどうかを確認しました。 2000行以上の（コメント化された）コードがあり、その一部が dizzy のように感じられることに驚かされました。私が実際に持っているかなり単純な要件を考えて--- 1つのプロデューサー、複数のコンシューマー、コンシューマーが仕事を引き受けることができない場合、プロデューサーをブロックさせます---私は独自のソリューションを展開することにしました。これは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();
}
}
}
}
}
実行可能な残りの容量を常に返しながら、探しているブロッキング動作で、エグゼキューターが使用する独自のブロッキングキューを作成します（エグゼキューターがコアプールより多くのスレッドを作成したり、拒否ハンドラーをトリガーしたりしないようにします）。
これにより、あなたが探しているブロッキング動作が得られると思います。拒否ハンドラーは、実行者がタスクを実行できないことを示すため、決して法案に適合しません。そこで考えられるのは、ハンドラーで何らかの形式の「ビジーウェイト」を取得することです。それはあなたが望むものではありません、あなたは呼び出し元をブロックするエグゼキュータのキューが欲しい...