Javaはコンパイル時に中間の「バイトコード」にコンパイルされます。これは、コンパイル時にマシン言語にコンパイルされるCなどの言語とは対照的です。 Javaバイトコードは、コンパイルされたCコードのようにハードウェアで直接実行することはできません。代わりに、実行するために、実行時にバイトコードをJVM（Java仮想マシン）が解釈する必要があります。 Cのような言語の主な欠点は、コンパイルされたときに、そのバイナリファイルが1つの特定のアーキテクチャ（x86など）でしか機能しないことです。
PHPのような解釈された言語は、実質的にシステムに依存せず、システムおよびアーキテクチャ固有のインタープリターに依存しています。これにより、移植性が大幅に向上します（同じPHPスクリプトはWindowsマシンやLinuxマシンなど）。ただし、この解釈はパフォーマンスの大幅な低下につながります。PHPなどの高水準言語は、マシン固有の命令よりも解釈に時間がかかります。ハードウェア。
Javaは、純粋にコンパイルされた言語（移植性のない）と純粋に解釈された言語（非常に遅い）の間の妥協点を見つけようとします。これは、コードを機械語に近い形式にコンパイルすることでこれを実現します（実際には、Javaバイトコードは単にJava Virtualマシン）ですが、アーキテクチャ間で簡単にトランスポートできます。Javaは実行にソフトウェアレイヤー（JVM）を必要とするため、インタープリター言語です。ただし、インタープリター（JVM）は生のソースファイルではなくバイトコードと呼ばれる中間形式。このバイトコードは、コンパイル時にJavaコンパイラによって生成されます。したがって、JavaはJavaはこのように操作することで、コンパイルされた言語の利点の一部を得ると同時に、インタプリタ言語の利点の一部も得ます。しかし、それはまた両方の制限を継承しますこれらの言語。
Bozhoが指摘するように、ジャストインタイム（JIT）コンパイルを使用してJavaコード（および.Netのような他のバイトコード言語））のパフォーマンスを向上させるためのいくつかの戦略があります。実際のプロセス要件に基づいて実装ごとに異なりますが、最終結果として、元のコードはコンパイル時にバイトコードにコンパイルされますが、実行前に実行時にコンパイラを介して実行されます。これにより、コードネイティブに近い速度で実行できます。一部のプラットフォーム（.Netはこれを行うと思います）は、JITコンパイルの結果を保存してバイトコードを置き換えます。これにより、プログラムの今後のすべての実行は、プログラムがネイティブであるかのように実行されます最初からコンパイル。
Javaはコンパイルされ解釈された言語です。
ソースコード（.Javaファイル）はコンパイルされてバイトコード（.classファイル）その後、Java Virtual Machine （JVMとも呼ばれます）によって（=）解釈されます（JVMはさらに最適化できますが、これは別の話です）。
これに対する利点は何ですか（コンパイル/解釈されます）
移植性。 sameバイトコードは、JVMがインストールされている限り、どのプラットフォームでも実行できます（「一度コンパイルすると、どこでも実行できます」）。
これは長いトピックなので、 [〜＃〜] jit [〜＃〜] について読むほうがよいでしょう。つまり、Javaはバイトコードにコンパイルされ、バイトコードは後で（JVMで）マシンコードにコンパイルされます。
コードはcompiledからバイトコード形式に変換され、次にJava仮想マシン（JVM）によって実行されるため、Javaは「コンパイル済み」言語と見なされます。これにより、コードの正確性を保証することは言うまでもなく、パフォーマンスとコード最適化の領域。
バイトコードがコンパイルされた後、JVMがインストールされているすべてのマシンで実行できるため、「解釈された」言語と見なされます。 Javaは、ほとんどの場合、実行されているプラットフォームに依存しないという点でインタプリタ言語に似ています。この動作はPerl、Python、PHPなどの他の解釈言語.
Javaプログラムはソースコードがなくても任意のシステムで実行できるという事実の理論的な欠点の1つは、この配布方法によってクロスプラットフォームの互換性が保証される一方で、開発者には1つ少ない理由があります。彼らのソースコードをリリースし、「クロスプラットフォーム」と「オープンソース」というフレーズのイデオロギー的意味の間のくさびを駆り立てます。
Javaはバイナリではなくバイトコードにコンパイルされます。バイトコードは直接実行可能ではありません。ジャストインタイムでコンパイルし、実行時にそれらを再度マシンコードにコンパイルするには、Java仮想マシンが必要です。
非常に基本的なレベルでは、JVMが動作するローカルマシンからプログラマーが作成するコードを分離するため、移植性が向上します。バイトコードにコンパイルすると、ジャストインタイムコンパイルのパフォーマンスが向上し、ファイルサイズが小さくなり、多かれ少なかれ実際のコードを隠すことができます。 （また、いくつかのコンパイル時エラーを排除します）
コンパイル済み：プログラムは構文的に正しいJavaプログラム、プログラムが開始する前のプログラムです。
解釈：異なるプラットフォームで同じ（バイト）コードを実行します。
コンパイル済み：プログラムが正しくコンパイルされたら、ソフトウェアのバグの80％を制御できるはずです。また、コードブロックなどを正しく閉じていないため、コードは停止しません。
解釈：アプレットとは何か知っていますか？ Javaが出たとき、それは「キラー」アプリケーションでした。ブラウザはWebサイトからアプレットをダウンロードし、ブラウザでアプレットコードを実行します。それはそれほどクールではありません。しかし、同じアプレットが実行されます。 Windows、Linux、Mac、Solarisなどでは、中間言語であるバイトコードを実行/解釈します。
静的コンパイラは、ソースコードを直接、ターゲットプラットフォームで直接実行できるマシンコードに変換します。ハードウェアプラットフォームが異なると、異なるコンパイラが必要になります。
Javaコンパイラは、JavaソースコードをポータブルJVMバイトコードに変換します。これは、JVMの「仮想マシン命令」です。最初の世代のJVMは完全に解釈されました。次世代のJVMは、Just-In-Time（JIT）コンパイラを使用して実行を高速化しました
HotSpotの実行プロセスは、解釈、プロファイリング、および動的コンパイルを組み合わせたものです。 HotSpotは、実行前にすべてのバイトコードをマシンコードに変換するのではなく、まずインタープリターとして実行され、「ホット」コード（最も頻繁に実行されるコード）のみをコンパイルします。
詳細はこちら- https://www.ibm.com/developerworks/Java/library/j-jtp12214/