問題タブ [java.util.concurrent]

Java でパーティ数が動的なバリアが必要です。Phaserに出くわしましたが、このソリューションは Java 7 用であり、残念ながら使用できません。

Java 6の解決策はありますか.可変数のウェイターを持つバリアを持つ必要性をどのように満たす必要がありますか?

OpenJDKのLinkedBlockingQueueの実装（java.util.concurrent）のNodeクラスの構造に少し混乱しています。

以下にノードクラスの説明を再現しました。

具体的には、nextの2番目の選択肢（「このノード、後継者はhead.nextを意味します」）で混乱しています。

これは、次のようなdequeueメソッドに直接関連しているようです。

そのため、現在のヘッドを削除し、次のヘッドを「GCを支援」するように設定しています。

これはGCにどのように役立ちますか？GCにとってどれほど役に立ちますか？

次のキャストが機能しない理由について、私は非常に混乱しています。

ScheduledThreadPoolExecutor は、ScheduledExecutorService を実装します。実際のクラスで使用できない場合、このエグゼキューター呼び出しのポイントは何ですか。

私はそれを間違って使用していますか（おそらく）、誰かがガイダンスを提供してもらえますか？

のソースコードをThreadPoolExecutor調べたところ、時間がkeepAliveTimeの設定値に達し、allowCoreThreadTimeOutがtrueになると、アイドル状態のすべてのワーカーに割り込みが発生することがわかりました。

runState> = SHUTDOWNの場合にのみ割り込みメソッドを呼び出すことができるのは、私には少し奇妙です。

以下のコードは、のメソッドからのものgetTask()ですThreadPoolExecutor。

これは、runState> = SHUTDOWN（SHUTDOWN、STOP、またはTERMINATED）の場合にのみ、すべてのアイドルスレッドを中断できることを意味しますか？つまり、状態がRUNNINGのときに中断されることはありません。

私は単純なプロデューサーを探しています-Javaでのコンシューマー実装であり、車輪の再発明をしたくありません

新しい同時実行パッケージといずれかのPipedクラスの両方を使用する例が見つかりませんでした

PipedInputStreamと新しいJava同時実行パッケージの両方をこのために使用する例はありますか？

そのようなタスクにPipedクラスを使用しないより良い方法はありますか？

CountDownLatchを使用して、サイズ 1の を待機している複数のコンシューマ スレッドがありawait()ます。countDown()正常に終了したときに呼び出す単一のプロデューサー スレッドがあります。

これは、エラーがない場合にうまく機能します。

ただし、プロデューサーがエラーを検出した場合は、エラーをコンシューマー スレッドに通知できるようにしたいと考えています。理想的には、プロデューサーに次のようabortCountDown()に呼び出して、すべてのコンシューマーに InterruptedException またはその他の例外を受け取るようにさせることができます。を呼び出したくありませんcountDown()。これには、すべてのコンシューマー スレッドが への呼び出しの後に、成功を確認するために手動で追加のチェックを行う必要があるためawait()です。私はむしろ、彼らがすでに処理方法を知っている例外を受け取ることを望んでいます。

でアボート機能が利用できないことを知っていますCountDownLatch。CountDownLatchカウントダウンの中止をサポートするを効果的に作成するために簡単に適応できる別の同期プリミティブはありますか?

専用スレッドで実行するタスクを定期的に送信するアプリケーションがあります。これらのタスクFutureTask<V>とスレッドは、ジョブがキューに入るときにジョブを実行し、空の場合はスリープ状態になる無限ループにすぎません。

計算の結果を待つ必要がある場合もあるので、FutureTask の get() メソッドを呼び出します。これは、何か問題が発生した場合にも例外をスローします。しかし、結果がどうであったとしても気にしない場合がありますが、タスクの実行中に何らかの障害があったかどうかを知る必要があります (ログ、printStackTrace() など)。

必要のない get() を待たずにこれを達成する方法はありますか?

前もって感謝します！

UPDATE : タスクの実行後にランナー スレッドで get() を呼び出すことは、他の誰も結果を待たない場合に例外をキャッチする唯一の方法のように思われました。

もう 1 つの解決策は、FutureTask クラスを拡張して、Java リフレクションを介して sync.exception プライベート フィールドを公開するメソッドを提供することです。

size()で呼び出されるメソッドが通常のHashMapConcurrentHashMapのメソッドと同じ複雑さであるかどうか疑問に思います。size()

より多くのカスタマイズができることはわかっていますが、同時実行ライブラリ クラスを使用することで、ストックの AsyncTask を使用したり、スレッドを作成して run を呼び出したりするよりもパフォーマンス (メモリ/速度) が向上しますか?