Java / Linuxスタックが「リアルタイム」に失敗する理由は何ですか？

開発者は、Javaが「リアルタイムを実行できない」、つまりLinuxで実行されているJavaアプリがRIOT-OSで実行されているものなどの確定的なリアルタイムシステムの要件を満たせないことを言及することをよく耳にします。

理由を理解しようとしています。私のSWAGによると、これはおそらくJavaのガベージコレクターによるものと思われます。Javaガベージコレクターはいつでも実行でき、システムを完全に一時停止できます。また、いわゆる「一時停止GC」はありますが、必ずしも広告を信じているわけではありません。また、趣味のプロジェクトに分岐するためのJVMインスタンスあたり$ 80Kもありません。

Linuxでのドローンソフトウェアの実行に関するこの記事も読んでいました。その記事で、著者はLinuxがドローンを車に衝突させそうになったシナリオについて説明しています。

Piで低レベル制御ループ（PID）を実行することを選択した後、ハードレッスンを学びました-巧妙にしようとして、デバッグのためにループの中央にログ書き込みを配置することを決めました-クワッドは最初はうまく飛んでいましたが、Linuxは決定しました1つのログエントリを書き込むのに2秒かかり、クワッドは私の車にほとんどクラッシュしました！

その著者はドローンソフトウェアをC ++で作成しましたが、Linux上で実行されているJavaアプリが同じ運命をたどる可能性が非常に高いと思います。

ウィキペディアによると：

操作の全体的な正確さが、その論理的な正確さだけでなく、実行される時間にも依存する場合、システムはリアルタイムであると言われます。

だから、私には、この手段は、「総正しさを論理的正当性と適時性を必要とする場合は、リアルタイムではありません。」

Javaアプリを書いて超高性能になり、いわば「レモンを絞る」ようになりましたが、それを（Javaで）速く書くことはできませんでした。

全体として、私の質問は次のとおりです。Linuxを実行しているJavaアプリが「リアルタイムアプリ」にならない理由のすべて/ほとんどの理由を説明してくれる人を探しています。つまり、Java / Linuxスタック上の「タイムリー」であることを妨げ、したがって「完全に正しい」ことを妨げるすべてのカテゴリは何ですか？前述のように、GCとLinuxのログフラッシュは実行を一時停止する可能性がありますが、Javaアプリ自体の外部には、タイミングやパフォーマンスが低下し、ハードデッドラインの制約を満たすものがもっとあるはずです。彼らは何ですか？

ソフトウェアは、可能な限り高速ではなくリアルタイムですが、特定のタイムスロット内でプロセスが完了することが保証されている場合です。ソフトリアルタイムシステムでは、これは保証されていますが、絶対に必要というわけではありません。たとえば、ゲームでは、フレームに必要な計算はフレームの期間内に完了する必要があります。そうしないと、フレームレートが低下します。これにより、ゲームプレイの品質が低下しますが、間違った結果にはなりません。たとえば、Minecraftは、ゲームがときどき途切れる場合でも楽しいです。

ハードリアルタイムシステムでは、そのような自由はありません。飛行制御ソフトウェアは一定の期限内に対応する必要があります。そうしないと、車両がクラッシュする可能性があります。また、ハードウェア、OS、およびソフトウェアが連携してリアルタイムをサポートする必要があります。

たとえば、OSには、どのスレッドを実行するかを決定するスケジューラがあります。リアルタイムプログラムの場合、スケジューラは十分に大きい、頻繁な十分なタイムスロットを保証する必要があります。そのようなスロットで実行したい他のプロセスは、リアルタイムプロセスを優先して中断する必要があります。これには、明示的なリアルタイムサポートを備えたスケジューラが必要です。

また、ユーザー空間プログラムは、カーネルへのシステムコールを実行します。リアルタイムOSでは、これらもリアルタイムでなければなりません。たとえば、ファイルハンドルへの書き込みはx時間単位を超えないように保証する必要があり、これによりログの問題が解決します。これは、そのようなシステムコールの実装方法、たとえばバッファの使用方法に影響します。また、必要な時間内に完了できない場合、呼び出しは失敗する必要があり、ユーザー空間プログラムはこれらのケースに対処する準備が必要であることも意味します。Javaの場合、JVMと標準ライブラリもカーネルに似ており、明示的なリアルタイムサポートが必要です。

リアルタイムであれば、プログラミングスタイルが変わります。無限の時間がない場合は、小さな問題に自分自身を制限する必要があります。すべてのループは、定数で区切られている必要があります。サイズには上限があるため、すべてのメモリを静的に割り当てることができます。無制限の再帰は禁止されています。これは多くのベストプラクティスに反しますが、リアルタイムシステムには適用されません。たとえば、ロギングシステムは、静的に割り当てられたリングバッファを使用して、ログメッセージが書き込まれたときにログメッセージを保存します。開始に達すると、古いログが破棄されるか、この状態がエラーになる可能性があります。

ウィキペディアから：

RTOSの重要な特徴は、アプリケーションのタスクを受け入れて完了するのにかかる時間に関する一貫性のレベルです。変動はジッターです。

重要なことは、システムがリアルタイムと見なされるためにジッタが定量化されることです。記事では、ジッタが通常制限される場合、システムはソフトリアルタイムであると述べています。ジッタが常に制限されている場合、システムはハードリアルタイムです。

使用しているJavaとLinuxのバージョンがジッターの観点から定量化されていない限り、それらはリアルタイムではありません。ガベージコレクションとログ書き込みは確かにジッタの原因ですが、（たとえば）ネットワークパケットの自律的な処理でさ​​え、プロセスにジッタを導入するとカウントされます。

まず第一に、バニラLinux自体はリアルタイムを実行できません。RTLinuxが開発されたのはそのためです。

RTLinuxでいくつかのJavaプロセスを実行するとしましょう。これらのプロセスはすべてカーネルによってスケジュールされているため、リアルタイムと見なされます。

現在、JavaプロセスがGreenスレッドを実行する場合、JVMはリアルタイムスケジューリングを行わないため、これらのスレッドの実行はリアルタイムではなくなります。