問題タブ [event-dispatch-thread]

私はこのアクションリスナーを持っています:

}

refreshScreen() が機能していないようです。それらは明らかにイベント ディスパッチャー スレッドで実行されており、加えられた変更はアクション リスナーの実行が終了したときにのみ表示されます。EDT 上にないため、MokkiGUI() コンストラクターから呼び出すと正常に動作します。

SwingでUIを実装しています。1つのコンポーネントが作業を行うため、時間がかかる場合があるため、を使用しますSwingUtilities.invokeLater。しかし、私はいくつかの古いコードを読んでいて、これをActionListener：で見つけました

code XEDTから分離しているので理にかなっていると思いました。しかし、何度か使用したことがあり、どちらの場合もelseパーツを忘れてしまったため、エラーが発生しやすいことがわかりました。

問題は、SwingUtilities.isEventDispatchThread()チェックが必要かどうかです。または、私はEDTに参加しておらず、常に使用していると想定invokeLaterできますか？

どうもありがとう。

Swingコンポーネントで呼び出されたメソッドがイベントディスパッチスレッドで呼び出されていることを確認するためのコードをインストルメント化するライブラリはありますか？これを行うための基本的なコードを書くのはおそらくそれほど難しいことではありませんが、他の人が扱ったエッジケースなどがあると確信しています。ただし、単体テストではなく、実行時にこれを探しています。

(以下のコード例は自己完結型で実行可能です。試してみてください。システムがクラッシュすることはありません:)

Tom Hawtin は、ここの質問についてコメントしました:なぜ人々はイベント キューで Java GUI を実行するのですか?

それ：

EDT がクラッシュする可能性は低いです。EDT ディスパッチでスローされた未チェックの例外がキャッチされ、ダンプされ、スレッドが続行されます。

誰かがここで何が起こっているのか説明してもらえますか ( 「チェックされていない例外をスローする」ボタンをクリックするたびに、意図的にゼロ除算が実行されます):

次のメッセージが表示されます（これは私が期待するものです）：

私にとって、これは未チェックの例外ですよね？

クラッシュをトリガーするたびに、スレッド ID が増加していることがわかります。

では、チェックされていない例外がスローされるたびに EDT が自動的に再起動されますか、またはTom Hawtin がコメントしたように、チェックされていない例外が「キャッチされ、ダンプされ、スレッドが続行されます」 ?

ここで何が起こっているのですか？

いくつかのメソッドを持つ Swing コンポーネントを作成しました。このクラスのすべてのメソッドを Swing イベント ディスパッチ スレッド (EDT) で実行し、呼び出し側はワーカー スレッドで実行したいと考えています。現在私の頭にある唯一の解決策はこれです：

このクラスの各メソッドについて:

名前を次のように変更する必要があります。

別のメソッドを追加します。

でもこれ、まずくないですか？どうすればいいですか？

多くの複雑な対話を伴う、かなり大規模な Swing GUI の保守と構築を支援しています。コードの別の場所で何らかの競合状態が発生して奇妙な状態になった結果、バグを修正していることに気付くことがよくあります。

コード ベースが大きくなるにつれて、どのメソッドにスレッド化の制限があるかをドキュメントで指定する方法の一貫性が失われていることがわかりました。最も一般的なのは、Swing EDT で実行する必要があるメソッドです。同様に、仕様によって EDT でどの (カスタム) リスナーに通知されるかを知り、静的な認識を提供すると便利です。

そのため、これはアノテーションを使用して簡単に適用できるものであるべきだと思いました。驚いたことに、少なくとも 1 つの静的分析ツールCheckThreadが存在し、アノテーションを使用してこれを実現しています。特定のスレッド (最も一般的には EDT) に限定されるメソッドを宣言できるようで、そのスレッドに限定されていると宣言せずにそのメソッドを呼び出そうとするメソッドにフラグを立てます。

したがって、表面的には、これは、ソースとビルド サイクルへの簡単な追加であり、巨大なゲインのように見えます。私の質問は次のとおりです。

• CheckThread または同様のライブラリを使用してスレッド化の制約を適用する人々の成功例はありますか? 失敗談は？ なぜ成功/失敗したのですか？
• これは理論的には良いですか？ 理論上の欠点はありますか？
• これは実際に良いですか？ その価値はありますか？ それはどのような価値をもたらしましたか？
• 実際に機能する場合、これをサポートするための優れたツールは何ですか? CheckThread を見つけたばかりですが、同じことを行う他のツールを見つけるために何を探しているのか完全にはわかりません。

それが私たちにとって正しいかどうかは、私たちのシナリオ次第です。しかし、実際にこのようなものを使用している人は聞いたことがありません。正直なところ、一般的なブラウジングではあまり定着していないようです。だから私はなぜだろうと思っています。

JFrameを作成した場合、ウィンドウの小さな「終了ボタン」で閉じるまでプログラムが実行されるのはなぜですか？

私はこの答えを探しましたが失敗しました。私が推測した唯一のことは、それnew JFrame()が特別なもののようnewであり、EDT内のオブジェクトの参照を保持するため、常に参照され（匿名の「新規」であったとしても）、によって削除されることはないということです。ガベージコレクター。次に、ウィンドウを閉じるイベントがトリガーされるとすぐに、オブジェクトは逆参照されて破棄されます。

デスクトップの Java 1.5 アプリケーション (多くの MacOS X マシンで実行する必要があるため、Apple の方針により 1.6 VM が表示されることはありません) では、EDT の外で長い計算を実行する正しい方法は何ですか?

たとえば、ユーザーが操作を開始するボタンをクリックすると、EDT で通知を受け取り、何らかのメソッド (たとえばcrunchData()) を実行したいとします。

これを行う1つの方法は次のとおりです。

つまり、これは私が望むことですが、ユーザーが長時間実行される可能性のあるタスクを開始するたびに、上記のイディオムを使用します。そして、私は常に不必要に多くのタスクを作成しているように感じます (さらに、操作が長くなる場合もあれば、長くならない場合もあり、このような場合はアプリにできるだけ責任を負わせたいと思います)。

それを行う別の方法は、別の (非 EDT) スレッド (またはスレッドのプール) を常に実行し、たとえばブロッキング キューで待機し、Runnableを実行することです。手術。

これに対処する正しい方法は何ですか？

編集:インストールが簡単なものを処理する正しい方法はありますSwingWorkerか? SwingWorker来る前に、人々はこれにどのように対処していましたか (これはかなり基本的なことのように思えます) 。

Swingコンポーネントを構築し、イベントを処理するすべてのコードは、イベントディスパッチスレッドによって実行される必要があることを読みました。この方法を使用することで、これがどのように達成されるかを理解していSwingUtilities.invokeLater()ます。mainGUIの初期化がメソッド自体で行われる次のコードについて考えてみます。

このコードが完全に機能するのはどうしてですか？JFrameメインスレッドで他の多くのメソッドを構築して呼び出しています。ここでEDTが正確にどこに現れているのかわかりません（どのコードが実行されていますか？）。クラスのコンストラクターGridBagLayoutTesterもメソッドから呼び出されてmainいます。これは、EDTがクラスを実行していないことを意味します。

要するに

1. EDTはいつ開始されますか？（このコードの実行中にEDTが開始された場合、JVMはmainメソッドとともにEDTを開始しますか？）
2. ボタンのイベントハンドラーコードはEDTで実行されますか？

私がやろうとしているのは、プログラムが何かをロードしているときに小さなスプラッシュ画面を表示させることです。これは私が持っているものです：

showSplashScreen（）メソッドが行うのは、画面の中央に新しいJWindowを作成し、それを表示することだけです。

このコードはイベントディスパッチスレッドから呼び出されるため、showSplashScreen（）メソッドが呼び出されると、スレッドが終了するまでJWindowが表示されません。それまでは、ウィンドウは必要ありません。私が待っている間にこのスプラッシュ画面を表示するための最良の方法は何でしょうか？