「サブクラスまたは実行可能」の下の次の行が何であるか理解できませんでした。
Runnableをスレッドプールで実行する場合、プールからのスレッドがアイドル状態になるまで、Runnableインスタンスを簡単にキューに入れることができます。
「サブクラスまたは実行可能」の下の次の行が何であるか理解できませんでした。
Runnableをスレッドプールで実行する場合、プールからのスレッドがアイドル状態になるまで、Runnableインスタンスを簡単にキューに入れることができます。
記事が指摘しているように、どちらも「機能」しますが、一般的には、サブクラス化するのではなく、Runnable
(または引数/結果が必要な場合Callable
は)を使用する必要があります。お気づきのように、これはより柔軟です-実行されるものと実行している人を分離します。スレッドを拡張すると、これら2つの概念が同じインスタンスで不必要に緊密に結合され、単一責任のオブジェクト指向の原則が破られます。Future
Thread
場合によっては、APIによって手が強制されたときに、実行可能コードをThreadのサブクラスとして実装する必要があります。たとえば、ランタイム。addShutdownHook(Thread)では、シャットダウン時に実行されるコードがThreadインスタンスとして登録されている必要があります。ただし、これらの特定のケースのいずれかを扱っていない場合は、常にを使用してRunnable
ください。
著者は、彼によれば、Runnablesはスレッドプールで使用する方が簡単であることを伝えたいだけです。スレッドプールの概念は、ジョブを取得するために待機するスレッドの数を固定することができるということです(たとえば10)。10個すべてがスレッドの実行でビジー状態の場合、プールからそれらのスレッドの1つが解放されるまで、未処理の作業をキューに入れることができます。
Jenkovは、サブクラスまたはRunnableのどちらの実装を選択するかは、他のどちらかが優先されるためであることを強調しています。
彼は、実行可能なインターフェイスの実装がより柔軟である理由の例として、スレッドプールパターンについて言及しています。私は彼の元の仮説を支持しますが、主にRunnableオブジェクトがThread以外のクラスをサブクラス化できるためです。
スレッドプールの構築が、Javaネイティブライブラリを使用するスレッドのサブクラスでどのように面倒に なるかはよくわかりません。java.util.concurrent.ThreadPoolExecutor。ジェンコフが例を提供してくれたらよかったのに...
Jenkovは、同時実行チュートリアルでさらに進んで、ExecutorServiceファクトリメソッドを使用して固定およびキャッシュされたスレッドプールについて説明します。ここを見てください:http://tutorials.jenkov.com/java-util-concurrent/executorservice.html。これらのスレッドプールを作成するJava同時実行ユーティリティを使用すると、ランナブルの使用が簡単になります。