19

最近、上級開発者から、Thread.join() を使用して別のスレッドが終了するまで待機しないように言われました。私はまた、SO で代理参加を求めるいくつかのそのような質問を見てきました。

私の調査では、join() に問題は見つかりませんでした。実際、広く使われています。

join() を使用しない理由を知りたいですか? それの何が問題なのですか？貧弱なプログラミングやアーキテクチャを促進しますか?

4

4 に答える 4

33

に問題はありませんjoin()。それはそれが得るのと同じくらい良いです。

ただし、結合に依存するようにアプリケーションを設計してはならない理由は次のとおりです。Java では、タスクを実行するための主要な抽象化はスレッドではなくなりました。ですExecutor。つまり、同時実行タスクを としてラップし、実行の詳細を気にせずCallableに に送信するだけです。Executorこれが仕組みExecutorです。YousubmitまたはexecuteaCallableまたはRunnableそれぞれ Thread を指定する必要はありません。

join() を使用しない理由を知りたいですか?

それでは、あなたの理由は次のとおりです。Executor の世界でスレッドを作成または操作しないため、を使用しても意味がありませんjoin。ほとんどすべてのものを別のもの ( 、、など)joinに置き換えることができます。Future.getCountDownLatchLocks

注: Executor を使用するときにスレッドを操作する必要がないと言っているのではありません。場合によっては、独自の Thread サブクラスを作成し、 Executor で を介して使用する方がよい場合がありますThreadFactory。

于 2013-05-13T01:42:01.360 に答える
11

一般に Thread.join を使用しても問題はありませんが、細心の注意を払い、スレッドがどこから来ているかを知る必要があります。スレッド プールからのものである場合は、プールが終了して複数のワーカー間で共有されるまでそのようなスレッドが実行されているため、実際に問題が発生します。

于 2013-05-13T01:42:17.843 に答える
2

Fork/Joinフレームワークは Java 7 で導入されました。Thread.join() の代わりに使用することを検討してください。一般に、可能な場合はパッケージ java.util.concurrent.* のクラスを使用し、同期ブロック、待機/通知、結合などの元の同期技術の使用を最小限に抑える必要があります。java.util.concurrent を使用すると、柔軟性が大幅に向上します。

于 2013-05-13T06:30:38.653 に答える
1

IMOは、参加することに何の問題もありません。待機しているスレッドがすべての状況で確実に終了するように注意する必要があります。そうしないと、実行が永久に停止する可能性があるためです。そのため、join を使用してメイン スレッドを特定のスレッドで待機させ、そのスレッドが終了しないと、アプリケーション全体がフリーズする可能性があります。

于 2013-05-13T01:38:18.223 に答える