7

このドキュメントをざっと読んだ後、Java 1.4 と Java 6 の間には大きなパフォーマンスの違いがあると思います。

私の質問ですが、Java 6 ランタイムは、実行する必要があるバイトコードが 1.4 でコンパイルされた場合でも、その魔法を手に入れることができますか?

「なぜその質問をするのか」の背景 はこちらです。

4

4 に答える 4

9

はい、ほとんどの最適化は実行時に JVM によって行われるため、コンパイラは最適化に関してほとんど何もしていません。したがって、古い Java コンパイラでコンパイルされたコードは、新しい JVM の恩恵を受けます。

Stringただし、連続した連結をに置き換えるなど、コンパイル時に実行される最適化がいくつかありますStringBuilder。

于 2012-04-26T10:57:48.893 に答える
2

Tomasz Nurkiewicz が指摘しているように、ほとんどの最適化は JIT コンパイラーによって行われ、Java 1.4 ではなく Java 6 で実行することでパフォーマンスが向上するはずです。ただし、これは最良の結果が得られることを保証するものではありません。低速な (古い) バリアントのデータ構造を使用している場合でも、利点を逃す可能性があります。たとえば、StringBuilder の代わりに StringBuffer、LinkedList の代わりに Vector、HashMap の代わりに Hashtable など...

javac の -deprecated フラグを使用してコンパイルすることも検討できます。通常、同じことを達成するために利用できるよりパフォーマンスの高い代替手段があることを意味するため、非推奨のメソッドを置き換えたいと思うでしょう。

于 2012-04-27T04:19:38.707 に答える
1

Javaのほぼすべての最適化はjitで行われるため、アプリケーションを実行しているjvmバージョンのみに依存します。javacバイトコードコンパイラは、可能な限り最も単純なバイトコードを出力します。StringBuilder/を使用した文字列の連結を除いて、この段階では最適化はないと思いますStringBuffer。

Java 6以降では、ターゲットバージョン6でコンパイルされたクラスに対して、より高速で単純なバイトコードベリファイアを使用できます。javacコンパイラは、ベリファイアが検証する必要のある各スタックスロットのデータ型に関する追加情報を作成します。以前のバージョンでは、ベリファイアはこれらのタイプを推測する必要がありましたが、これはより複雑です。この変更はクラスのロードを高速化するだけであり、実際にバイトコードを実行するときに影響を与えることはありません。

バージョン5または6のバイトコードに対する別の変更は、クラスファイルの定数プールがクラスとインターフェイスを参照できることだと思います。繰り返しますが、これはおそらくクラスの読み込みにのみ影響します。

于 2012-04-26T13:32:08.480 に答える
0

パフォーマンスが大幅に向上するだけでなく、Java 6 のバージョン間でも大きな違いがあります。Java 6 のマイナー リリースを 18 か月間追跡したところ、15 ～ 20% の高速化が見られました。

ところで、Java 7 が出ており、推奨される製品バージョンです。そのバージョンに行きたくない理由はありますか?

ああ、最後にもう 1 つ。管理に対する利益を証明する必要がある場合は、Java アプリケーションのパフォーマンス測定について多くのことを読む必要があります。Oracle の Java マガジンの 2012 年 5 月 / 6 月号に記事があります。これは非常にわかりにくい題材なので、よく読んでおかないと、非常に誤解を招く数字が表示される可能性があります。

于 2012-04-27T03:01:33.597 に答える