1

この質問が少し曖昧であると申し訳ありませんが、デバッグから有用な情報を得ることができませんでした。

new Thread（）。Startを使用して呼び出すスレッドがあります。その後、短時間実行され、次のメッセージが表示されます。

キャッチされない例外：アプリケーション「myappname（201）」が応答していません。プロセスが終了しました

イライラするのは、同じプロセスをスレッドなしで実行できることです。これにより、アプリケーションがロックされますが、Eclipseコンソールからエラーなしで動作していることがわかります。だから私はそれらが私がスレッドで使用している関数のエラーではないことを知っています。

「InvokeLater」関数を使用してGUIをスレッドの進行状況で更新することに問題があるのではないかと思いました。これをかなり激しくスパムしており、スレッドが破壊されるのではないかと心配しています。

助言がありますか？

私の投稿を拡張するために、問題は私が他のスレッドからこのコードをALOTと呼んだことが原因でした：-

 invokeLater(new Runnable() 
        {
            public void run() 
            {
                _output.setText(_output.getText() + "\n" + msg);
            }
        });

これは、私のアプリケーションをすぐにクラッシュさせるキューを構築していました。

このオプションに対する私の解決策は、このコードを関数に追加してイベントスレッドを使用することでした：-

   synchronized(Application.getEventLock()) {
       _output.setText("new text " + System.currentTimeMillis());
   }
4

3 に答える 3

1

時間のかかる処理を実行中にスレッド内のオブジェクトを同期する場合、UI スレッドが同じオブジェクトを同期しようとすると、ロックが解除されるまでブロックされます。

于 2011-05-16T20:50:23.533 に答える
1

あなたはまさに正しいです：

おそらく問題は、「InvokeLater」関数を使用して GUI をスレッドの進行状況に合わせて更新することにあるのではないかと考えました。

InvokeLater を呼び出すとすぐに戻り、UI スレッドが実行されるようにキューが機能します。問題は、そのキューが大きくなりすぎると、UI がキューにサービスを提供していないところまで行き詰まったと想定して、OS がアプリを強制終了することです。

過去にこれを回避するために使用した解決策は、UI スレッドに送信される作業をチャンクすることです。ある種のアキュムレータ オブジェクト、ブール フラグ、およびロックを作成します。次に、ワーカー スレッドがロックを取得し、アキュムレータに作業を追加します。boolean フラグは、将来、UI ワーカー コードがアキュムレータを空にするようにスケジュールされているかどうかを示します。そうでない場合は、UI 更新コードをスケジュールします。

UI 更新コードでは、ロックを取得してアキュムレータからできるだけ早くデータを移動し、ブール値を false としてマークして、アキュムレータを空にする予定の UI ワーカーがなくなったことを示します。

于 2011-05-16T23:49:23.247 に答える
0

特にタイムアウトを延長してもまだ表示される場合は、デッドロックの可能性があります。スレッド ダンプを取得して、UI スレッドが何をしているかを確認できます。ロックを取得するのを待っている場合は、おそらくこの方向に掘り下げる必要があります。

于 2011-05-17T01:43:20.137 に答える