2

EventQueue で現在キューに入れられている Runnable の数を特定する方法はありますか?... システムの EventQueue、つまり EDT で実行されるすべての Runnable を意味します。そして、キューを台無しにしますか?

私がやりたいのは、GUI Runnables を優先することです... ユーザー主導の GUI イベントが発生した場合は、すぐに実行する必要があり、キューに入れられた Runnables の前にキューをジャンプします (ちなみに、これらはすべて変更に関係しています)。非表示の Swing コンポーネント 注意: 最新の Swing ガイドライン: すべての Swing コンポーネントは、非表示であっても EDT で変更する必要があります)。

「緊急」および「非緊急」Runnables を使用した単純で不自然なキューの可能性があります。各 Runnable は「観察可能な」AtomicInteger カウンターをインクリメントし、それぞれの実行によってそれをデクリメントできます...そして BlockingQueue はそれを保証します緊急でないランナブルは、BlockingQueue のサイズが 1 (または 2 または 0) に変更された場合にのみ「invokeLater」に送信されます。本能的には、そのような配置ではかなりのレイテンシーが発生すると思います。

さらに、EDT 自体のキューに直接干渉できると便利です。自分の EDT キューをロールする必要がありますか? それは可能ですか?

明らかに、EDT キューの状態の監視 (またはそのキューへの介入) は、非 EDT スレッドから行う必要があります。私が知っている限り、「スレッドの可視性」の問題があるかもしれません...

4

1 に答える 1

1

ありえないと思います。コードが利用可能です。これをオーバーライドして書き直すこともできますが、実際の EventQueue はシステムによって設定されます。いくつかの定義された方法を使用しない限り、それに到達することはできません。もちろん、独自の EQ をセットアップして使用することもできますが、すべての Swing コンポーネントは公式の EQ を使用するため、マルチスレッド Swing を実行することになります。(個人的な経験からすると、これは非常にうまく機能しますが、時折発生する、悪化する、説明のつかないちょっとした奇妙な動作を除きます。私のアドバイス: EventQueue を使用していない限り、Swing コンポーネントについて考えることさえしないでください。)

(実際に見てみると、1.4 の EventQueue クラスは美しいコードでした。1.7 では、古い待機/通知の代わりに、スレッドセーフでノンブロッキングのスキップ リストを使用しているようです。確かに高速ですが、コードはなんらかの理由で独自のキューを作成したい場合は、出発点として 1.4 コードを取得してみてください.Java には汎用の実行キュー クラスが必要ですが、私はまだ見つけていません.)

EventQueue のパフォーマンスに大きな問題はありません。毎秒 1 秒未満の CPU を使用する必要があります。CPU を集中的に使用するランナブルを大量にドロップしない限り、心配する必要はありません。もしそうなら、あなたはその仕事を別のスレッドに入れることを検討するかもしれません. (ときどき UI を遅くすることは、すべてを 1 つのスレッドに保持するために支払う代償としては小さいように思えます。) いずれにせよ、キューの順序を変更しても、おそらくあまり役​​に立ちません。すぐに処理したいランナブルは、何らかの大きな計算が開始された直後に到着するはずです。

独自のランナブルを順番に実行したい場合は、ランナブルのソートされたリストを保持するクラスを設定できます。InvokeLater を使用して EQ にドロップできる独自のランナブルを持ちます。実行すると、順番に、各ランナブルを希望の順序で実行できます。ただし、これは、独自の目的のためにランナブルをソートする必要がある場合にのみ役立ちます。

表示されているかどうかに関係なく、Swing コンポーネントのみを使用している場合は、すべてに InvokeLater で設計された EQ を使用して問題なく動作するでしょう。

于 2012-12-10T01:01:23.060 に答える