Java / Linuxスタックが「リアルタイム」にならない理由は何ですか？
開発者がJavaは "do Real Time"はできない、Java Linuxで実行されているアプリは、RIOT-OSで実行されているものなど、確定的リアルタイムシステムの要件を満たすことができません。
なぜなのか理解しようとしています。私の Swag は、これはおそらくいつでも実行でき、システムを完全に一時停止できるJavaのガベージコレクターが主な原因であることを示しています。そして、いわゆる「一時停止のないGC」は世の中にありますが、私はそれらの広告を必ずしも信じているわけではありません。また、趣味のプロジェクトに分岐するために、JVMインスタンスあたり80Kドルも持っていません！
私も読んでいました Linuxでのドローンソフトウェアの実行に関するこの記事 。その記事の中で、著者はLinuxが彼のドローンを車に衝突させようとしたシナリオを説明しています。
Piで低レベル制御ループ（PID）を実行することを選択した後、私はハードレッスンを学びました-賢くしようとして、デバッグのためにループの真ん中にログ書き込みを置くことにしました-クワッドは最初はうまく飛んだが、その後Linuxが決定しました1つのログエントリを書き込むのに2秒かかり、クワッドが車に衝突しそうになりました。
筆者はドローンソフトウェアをC++で作成しましたが、JavaアプリをLinuxで実行すると、同じ運命をたどる可能性が非常に高いと思います。
ウィキペディアによると：
操作の全体的な正確さがその論理的な正確さに依存するだけでなく、実行される時間にも依存する場合、システムはリアルタイムであると言われます。
つまり、私にとって、これは「完全な正確性が論理的な正確さと適時性を必要とする場合、リアルタイムではありません。」という意味です。
私がJavaアプリを非常に高性能であると書いて、いわば「レモンを絞って」しましたが、それを（Javaで）合理的に書き込むことができなかったとしましょうより速くなる。
全体として、私の質問は：Java n Linuxを実行するアプリが「リアルタイムアプリ」にならない理由のほとんどすべての理由を説明してくれる人を探しています。 "。意味、Java/Linuxスタック上の「タイムリー」になることを妨げる、つまり「完全に正しい」ことを妨げるすべてのカテゴリは何ですか "？前述のように、GCとLinuxのログフラッシュは実行を一時停止できるようですが、Javaタイミング/パフォーマンスの低下を引き起こし、厳しい期限の制約を満たすアプリ自体それらは何ですか？
ソフトウェアはリアルタイムであり、可能な限り高速ではありませんが、プロセスが特定のタイムスロット内で完了することが保証されている場合です。ソフトリアルタイムシステムでは、これが保証されていることは良いですが、絶対に必要というわけではありません。例えば。ゲームでは、フレームに必要な計算がフレームの期間内に完了する必要があります。そうしないと、フレームレートが低下します。これにより、ゲームプレイの品質が低下しますが、ゲームが不正になることはありません。例えば。 Minecraftは、ゲームが時々途方に暮れても楽しいです。
ハードリアルタイムシステムでは、そのような自由はありません。フライトコントロールソフトウェアは期限内に反応する必要があります。また、ハードウェア、OS、およびソフトウェアは、リアルタイムをサポートするために連携して機能する必要があります。
たとえば、OSには、どのスレッドを実行するかを決定するスケジューラがあります。リアルタイムプログラムの場合、スケジューラは十分に大きく、十分な頻度のタイムスロットを保証する必要があります。このようなスロットで実行したい他のプロセスは、リアルタイムプロセスを優先して中断する必要があります。これには、明示的なリアルタイムサポートを備えたスケジューラが必要です。
また、ユーザー空間プログラムはカーネルへのシステムコールを実行します。リアルタイムOSでは、これらもリアルタイムでなければなりません。例えば。ファイルハンドルへの書き込みは、ログの問題を解決するx時間単位以上をとらないことが保証される必要があります。これは、このようなシステムコールを実装する方法に影響を与えます。バッファの使用方法。また、必要な時間内に完了できない場合は呼び出しが失敗する必要があり、ユーザー空間プログラムはこれらのケースに対処する準備ができている必要があることも意味します。 Javaの場合、JVMと標準ライブラリもカーネルに似ており、明示的なリアルタイムサポートが必要になります。
リアルタイムのものは何でも、プログラミングスタイルが変わります。無限の時間がない場合は、小さな問題に限定する必要があります。すべてのループは、定数によって制限されている必要があります。サイズに上限があるため、すべてのメモリを静的に割り当てることができます。無制限の再帰は禁止されています。これは多くのベストプラクティスに反しますが、リアルタイムシステムには適用されません。例えば。ロギングシステムは、静的に割り当てられたリングバッファを使用して、ログメッセージの書き込み時にログメッセージを保存する場合があります。開始に達すると、古いログが破棄されるか、この状態がエラーになる可能性があります。
wikipedia から：
RTOSの主な特徴は、アプリケーションのタスクを受け入れて完了するのにかかる時間に関する一貫性のレベルです。変動はジッターです。
重要なことは、システムがリアルタイムと見なされるようにジッターが定量化されることです。記事はさらに、ジッターが通常に制限されている場合、システムはソフトリアルタイムであると述べています。ジッタがalwaysに制限されている場合、システムはhard real-timeです。
Javaおよび使用しているLinuxのバージョンがジッターで定量化されていない限り、それらはリアルタイムではありません。ガベージコレクションとログ書き込みは確かにジッターの原因ですが、yourプロセスにジッターを導入すると、ネットワークパケットの自律処理でさえカウントされます。