ガベージコレクターを除き、Javaを非リアルタイムプログラミング言語にするもの

ガベージコレクタを除き、リアルタイムプログラミングに適さないJavaのその他の機能は何ですか？ネット上では、Java vs C ++がリアルタイムプログラミングに関して議論されるときはいつでも、言及されるのは常にガベージコレクターです。他に何かありますか？

すぐに覚えられる2つの追加項目があります。

1. JITコンパイル
2. スレッドの実装

リアルタイムに関しては、パフォーマンスの予測可能性がおそらく最も重要な要素です。そのため、予測できないGCサイクルにより、Javaはリアルタイムに適さなくなります。

JITはパフォーマンスを改善しますが、プログラムの実行後のある時点で起動し、リソースを使用して、システムの実行速度を変更します。また、VMがその時点で「より良い」ジョブを実行できると考えている場合、後の段階で再び発生する可能性があります。

スレッドに関する限り：これが言語設計の一部であるか、非常に一般的な実装であるかは現時点ではよく覚えていませんが、Javaは通常、スレッドの実行を正確に制御するツールを提供しません。たとえば、スレッドには10個の「優先度」が指定されていますが、VMがこれらの優先度を実際に考慮する必要はありません。スレッドを停止および切り替えるための演算子も定義されていないか、システムによって厳密に遵守されていません。

JSR 1にはいくつかの実装があります。Real-timeSpecification for Java -1998年に承認された仕様。この仕様は、標準Javaをリアルタイムに適さないものにする問題を可能な限り解決します。

たぶん5年前の時点で、Sun（Now Oracle）にはRTSJ VMがありました（名前は知らなかったのですが）。IBMにはWebSphere Real Timeがありました。JamaicaVMは、プラットフォームに依存しない無料の（？）ソリューションでした。今日それらをグーグルで検索してもあまり意味がありません。

オペレーティングシステム

JavaがUnixまたはWindowsまたはその他の「通常の」OS上で実行されている限り、リアルタイムは保証されません。

リアルタイムアプリケーションを実行するには、リアルタイムOSが必須です。

技術的には、リアルタイムのjavaを使用することが可能です（SK-logicのコメントが示唆しているように）。ただし、多くの非技術的な理由で一般的ではありません。

古い基準

これに関するリファレンスを見つけるのに苦労していますが、私は安全基準、または安全基準適合のアドバイスを見たことがあると確信していますが、Javaを全面的に禁止しています。Javaが冗長であると言うものに準拠する必要がある場合、JavaはVerbotenです。

古い安全エンジニア

Javaを禁止しないために作業する必要がある標準であっても、Javaの経験がなくても安全性/品質監査員と協力することは、抵抗が最も少ない道をたどらないことを意味します。監査人にとって普通ではないことは、多くの質問を引き付ける可能性が高く、これは選択肢を正当化するための多くの作業を意味します。

コミュニティー

つまり、多くのパス依存関係があり、現在のリアルタイムエキスパートのほとんどはC ++、C、またはADAを完全に知っているので、新しい作業を行うのは自然な選択です。

（注：上記では、リアルタイムと安全性をいくらか混同しましたが、これは別の問題の一種です。安全基準でさえしばしば2つを混同します）