10

次のコード:

long msBefore = System.currentTimeMillis();
//Thread.currentThread().setPriority(Thread.MAX_PRIORITY);
try
{Thread.sleep(200);
} catch (InterruptedException e){}
System.out.println("Time: " + (System.currentTimeMillis() - msBefore));

版画 :

Time: 578
Time: 594
Time: 625
Time: 640
Time: 641
Time: 609
Time: 625
Time: 625
Time: 610
Time: 609
Time: 625
Time: 625
Time: 422
Time: 625
Time: 594
Time: 609
Time: 625
Time: 594
Time: 594
Time: 625

どこが問題？？

4

5 に答える 5

8

1 秒あたり n メッセージを送信する必要がありますが、待機/通知は適切ではないと思います。

厳しいタイミング要件がある場合は、リアルタイム Java実装を使用する必要があります。主流の SE および ME Java 実装は、ハード リアルタイム アプリケーションには適していません。

「ほとんどの場合」そのような要件を満たすために使用できるさまざまなトリックがあります...しかし、アプリケーション/システムが過負荷になると、必要なメッセージレートを逃し始める可能性があります.

本当の問題は、タイマーの精度ではなく、非リアルタイム スケジューラが、タイマーが切れるとすぐに実行するようにスレッドをスケジュールすることを保証しない (そしてできない) という事実です。

于 2011-05-23T10:19:10.747 に答える
7

ここでは問題ありません。javadoc から:

システムとスケジューラーの精度に左右されます。

通常、スリープ間隔はシステムや JVM 実装によって異なる可能性があるため、スリープ間隔に依存するのは適切な設計ではありません。代わりに wait() と notify() を使用するか、より良い - java.util.concurrent パッケージを使用してください。

于 2011-05-23T10:10:12.363 に答える
0

処理にかかる時間を考慮していません。

    try {
        long processingStart = System.currentTimeMillis();

        long processingFinish = System.currentTimeMillis();
        long processTime = 600 - (processingFinish - processingStart);
        Thread.sleep(processTime);

    } catch (InterruptedException ex) {

    }
于 2012-02-26T06:07:02.727 に答える
0

固定メッセージレートが本当に必要な場合は、スピンロックのようなものを実装してください。単一の CPU コアを消費しますが、それに近づきます。

long nextTime = System.currentTimeMillis() + interval;
while (keepRunning) {
   while (nextTime - System.currentTimeMillis() > 0)
       ;
   sendMessage();
   nextTime += interval;
}
于 2012-06-18T20:37:29.750 に答える