ガベージコレクタを除いて、他に何がJavaを非リアルタイムプログラミング言語にしているのか）
ガベージコレクターを除いて、Javaでリアルタイムプログラミングに適さないようにするその他の機能は何ですか？ネット上では、Java vs C++については、リアルタイムプログラミングに関しては、言及されているのは常にガベージコレクタです。他に何かありますか？
すぐに覚えることができる項目が2つあります。
- JITコンパイル
- スレッド化の実装
リアルタイムでは、パフォーマンスの予測可能性がおそらく最も重要な要素です。そのため、予測不可能なGCサイクルによってJava=がリアルタイムに適さなくなります。
JITはパフォーマンスを向上させますが、プログラムの実行後、ある時点でリソースを消費し、システムの実行速度を変更します。 VMがその時点で「より良い」仕事ができると信じている場合は、後の段階で再び発生する可能性もあります。
スレッドに関する限り：これが言語設計の一部であるか、それとも非常に一般的な実装であるかは、現時点ではよく覚えていませんが、Javaは通常、スレッドの実行を正確に制御するツールを提供しません;たとえば、スレッドに10の「優先度」が指定されている場合、VMが実際にこれらの優先度を考慮する必要はありません。スレッドを停止および切り替えるための演算子も、定義されていないか、厳密ではありません。システムによって付着した。
JSR 1：Javaのリアルタイム仕様 にはいくつかの実装があります。1998年に承認された仕様です。この仕様は、標準のJavaリアルタイムには適していません。
おそらく5年前の時点で、Sun（現在のOracle）にはRTSJがありましたVM（これには名前がなかったため、AFAIK）、IBMにはWebSphere Real Timeがあり、JamaicaVMは無料でした（？）、プラットフォームに依存しないソリューションです。今日それらをグーグルすることは多くをもたらしません。
オペレーティングシステム
JavaがUnix、Windows、またはその他の「通常の」OSの上で動作する限り、リアルタイム性は保証されません。
リアルタイムアプリケーションを実行するには、リアルタイムOSが必須です。
技術的には、リアルタイムのJava（SK-logicのコメントが示唆するように）にすることは可能ですが、多くの非技術的な理由により一般的ではありません。
古い規格
これに関するリファレンスを見つけるのに苦労しているが、安全基準または安全基準適合のアドバイスを見たことがあると確信しているため、Javaを全面的に禁止した。 Javaは禁止されている場合）Javaは禁止されていることを意味します。
古い安全エンジニア
Javaを禁止しないようにするために必要な標準であっても、Javaの経験がない安全/品質監査人と協力することは、最も抵抗の少ない道をたどらないことを意味します。監査人にとっては通常ではないことですが、多くの質問が寄せられる可能性が高いため、選択を正当化するために多くの作業が必要になります。
コミュニティ
つまり、多くのパス依存性があり、現在のほとんどのリアルタイムエキスパートはC++、C、またはADAを完全に理解しているため、新しい作業を行うのは自然な選択です。
（注：上記では、リアルタイムと安全性をある程度融合させていますが、これは別の問題であり、安全基準でさえ2つを融合させることが多いためです）