問題タブ [futuretask]

Callable コードでは、シグナリングを使用して複数の終了動作を別のスレッドに通知します。Callable オブジェクトは、Executor の FutureTasks でキューに入れられます。また、お並びいただいた後、キャンセルさせていただく場合がございます。

さて、私の問題は、シグナリングが機能するために少なくとも開始されているタスクに依存していることですが、タスクを実行する機会が得られる前にキャンセルされたとマークされている場合、エグゼキューターはタスクをスキップするように見えます。

したがって、タスクが常に開始され、実行中に (InterruptedException によって) 常にキャンセルされることを保証する方法はありますか。

また、タスクが開始されずに失敗したかどうかを確認できますか?

私はCallableオブジェクトをに送信していますがThreadPoolExecutor、それらはメモリに残っているようです。

Eclipse用のMATツールでヒープダンプを見ると、CallableオブジェクトがFutureTask$Syncの呼び出し可能な変数によって参照されていることがわかります。これは、の同期変数FutureTask$Syncによって参照されます。これは、のthis$0変数によって参照されます。FutureTaskFutureTaskFutureTask$Sync

私はこれについて読んだことがあり（ここ、ここ、そしてSOで） 、呼び出し可能オブジェクトが's submit（）FutureTaskにラップされThreadPoolExecutor、呼び出し可能オブジェクトへの参照を永久に保持しているようです。

私が混乱しているのは、FutureTaskガベージコレクションを確実に取得して、呼び出し可能オブジェクトをメモリに保持し続けないようにし、呼び出し可能オブジェクトがメモリに保持している可能性のあるものを保持する方法です。

私の特定の状況について詳しく説明するためにThreadPoolExecutor、必要に応じて送信されたすべてのタスクをキャンセルできるように実装しようとしています。私はSOや他の場所で見つけたいくつかの異なる方法を試しました。たとえば、エグゼキュータを完全にシャットダウンし（などで）、先物のリストを保持し、それらすべてに対してキャンセルを呼び出してから、shutdown()先物のリストをクリアします。理想的には、シャットダウンする必要はなく、必要に応じてクリアする必要があります。shutdownNow()submit()cancel()

これらの方法のすべてが違いを生むわけではないようです。呼び出し可能オブジェクトをプールに送信すると、それが固執してしまう可能性が高くなります。

私は何が間違っているのですか？

ありがとう。

編集：

要求に応じて、これがThreadPoolExecutorのコンストラクターです。

さらにテストした後、ThreadPoolExecutorに送信されたタスクを終了させて​​も、リークがないことがわかります。とにかくそれらをキャンセルしようとすると：

または、将来への参照を保存し、後でキャンセルを呼び出す：

または、次のような方法でキューから削除します。

また

または先物への保存された参照をループして呼び出します：

これらのケースのいずれかにより、FutureTaskは上記のように固執します。

したがって、これらすべての本当の問題は、FutureTaskがガベージコレクションされ、永久にリークされないように、ThreadPoolExecutorからアイテムを適切にキャンセルまたは削除する方法です。

タスクを使用してを返すExecutorServiceことができるのでsubmit、タスクをラップしてメソッドを使用する必要があるのはなぜですか? どちらも同じことをしていると感じます。CallableFutureFutureTaskCallableexecute

ThreadPoolExecutorから取得したFutureTaskをキャンセルしたいのですが、スレッドプールのCallableが動作を停止したことを確認したいと思います。

FutureTask＃cancel（false）を呼び出してからget（）を呼び出すと（完了するまでブロックするため）、CancelledExceptionが発生します。この例外は、タスクの実行を停止した直後または停止した後にスローされますか？

I need to schedule some work to be done in the future. I can do it in 2 ways:

1. Create a TimerTask and execute timer.schedule(...);

2. Use Executors.newScheduledThreadPool(1):

   /li>

What is the difference between these 2 ways of scheduling the work in the future?

私は実行者サービスにまったく慣れていません。自分ですべてをやるのが好きでしたが、これらのサービスを信頼する時が来たと思います。

で手渡したいExecuterですRunnable。実行者はそれをaでラップし、FutureTaskそれを私に返します。ここで、polldone()メソッドを呼び出します。done()しかし、メソッドがtrueを返すときに通知を受け取りたいと思います。

get()が終了するまでブロックするメソッドがありますが、Runnableそれから、それがいつ終了するかを確認するために、すべてのジョブに追加のスレッドが必要になります。

Callableタスクの終了について通知を受け取るために、実行者に追加の情報を渡すことはできますか？

ここに行く方法は何ですか？runメソッドの最後にコードを追加することはできますが、done()それでもfalseになる可能性があります...

Java プログラムで、多くの Async Future Task Calls を次々と書きました。以下に1つのサンプルを与える

ここで、上記の 2 番目の呼び出しで意図的に例外を作成し、get() の 3 つの呼び出しすべてを 1 つの try/catch ブロック内に囲んでいると仮定します。例外が catch ブロックに来ることはなく、私の Java プログラムは静止しています。3 つのメソッド呼び出しはすべて同時に発生しています。

しかし、get() のそれぞれを個別の try catch ブロックで囲むと、それらをキャッチできます。なんで？また、各 get() メソッドを try catch ブロックで囲み始めた瞬間に、マルチスレッドが失われます。メソッド呼び出しは、コーディングされているように 1 つずつ発生しています。

例外をキャッチできるとマルチスレッドが失われ、マルチスレッドを生成できると例外が失われます。

例外を個別に処理し、同時にマルチスレッドを実現する方法についてのアイデア

送信したタスクをシリアル順に実行するために、singleThreadExecutor があります。つまり、タスクを 1 つずつ実行し、並列実行しません。

私はこのようなものになるrunnableを持っています

}

たとえば、MyRunnable の 3 つのインスタンスを前述のシングル スレッド エグゼキュータに送信すると、最初のタスクが実行されると予想されます。Thread.sleep には実行中のスレッドが TIMED_WAITING にあるためです (具体的には間違っている可能性があります)。州）。他の 2 つのタスクには、少なくとも最初のタスクが終了するまで、それらを実行するためのスレッドを割り当てないでください。

したがって、私の質問は、FutureTask API を介してこの状態を取得する方法、または何らかの方法でタスクを実行しているスレッドに到達する方法です (そのようなスレッドがない場合、タスクは実行または保留中を待機しています)。他の意味？

FutureTask は isCanceled() および isDone() メソッドのみを定義していますが、それらは Task の考えられるすべての実行ステータスを説明するには十分ではありません。

基本的に、次のスニペットがあります。

問題は時々キャンセルが機能しないことです.AFAICTキャンセルが原因で例外がスローされますが、コードの一部がそれをキャッチしますか? 将来のタスクをキャンセルする確実な方法はありますか?

fn は、基本的に一連の長時間実行される計算を実行する関数であるため、ブール値フラグのチェックをループすることはできません。