Javaパフォーマンス第2版

序文

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

オライリーからJavaのパフォーマンス・チューニングに関する本の執筆を打診されたとき、私は迷った。Javaのパフォーマンスなんて、もういいじゃないか、と。たしかに、私は今でもJava（やその他の）アプリケーションのパフォーマンス改善に日々取り組んでいるが、Javaのチューニングに直接関係することよりも、アルゴリズムの非効率性や外部システムのボトルネックに対処することにほとんどの時間を費やしていると思いたい。

少し考えてみると、私は（いつものように）自分自身をからかっているのだと確信した。エンド・ツー・エンドのシステム・パフォーマンスに多くの時間を取られているのは事実だし、時々、OpenGLを使うコードに出くわすこともある。 $O\left(n^2\right)$のアルゴリズムを使うことができる。それでも、ガベージ・コレクション（GC）のパフォーマンスやJVMコンパイラのパフォーマンス、Java APIから最高のパフォーマンスを得る方法について、毎日考えていることがわかった。

それは、過去20年以上にわたってJavaとJVMの性能にもたらされた大きな進歩を最小限に抑えるためではない。私がサンのJavaエバンジェリストだった1990年代後半、利用可能な唯一の本格的な「ベンチマーク」は、Pendragon software社のCaffeineMark 2.0だった。さまざまな理由から、そのベンチマークの設計はすぐにその価値を制限してしまった。しかし当時、私たちはJava 1.1.8の性能は、そのベンチマークに基づくJava 1.0の性能よりも8倍速いと、みんなに好んで話していた。そしてそれは本当だった。Java 1.1.8には実際のジャストインタイム・コンパイラがあったのに対し、Java 1.0はほとんど完全にインタプリタだったのだ。

その後、標準化委員会はより厳密なベンチマークを開発し始め、Javaの性能はそれを中心とするようになった。その結果、JVMのすべての領域（ガベージ・コレクション、コンパイル、API内）で継続的な改善が行われるようになった。もちろんそのプロセスは今日も続いているが、パフォーマンス作業に関する興味深い事実の1つは、それが次第に難しくなっていくということだ。ジャスト・イン・タイム・コンパイラを導入することで8倍の性能向上を達成したのは、エンジニアリングの単純な問題だった。ガベージ・コレクタの並列化は大きな性能向上だったが、最近の変更はよりインクリメント的なものだ。

プロジェクトの初期には、アーキテクチャの変更（またはコードのバグ）を発見するのは簡単で、それに対処することでパフォーマンスが大幅に向上する。成熟したアプリケーションでは、そのような性能向上を発見することはまれである。

エンジニアリングの世界では、Javaの性能はもういいのではないか、というのが私の当初の懸念だった。いくつかのことが、私が間違っていたことを確信させた。第一に、JVMのあれやこれやが特定の状況下でどのように動作するのかについて、私が毎日目にする質問の数である。Javaには常に新しいエンジニアがやってくるし、JVMの振る舞いはある分野では十分に複雑なままであるため、その演算子に関するガイドは今でも有益である。第二に、コンピューティングの環境変化が、今日エンジニアが直面するパフォーマンス上の懸念を変化させているようだ。

ここ数年、性能に関する懸念は二極化している。一方では、非常に大きなヒープを持つJVMを実行できる非常に大きなマシンが、今や当たり前になっている。JVMは新しいガベージ・コレクタ（G1）でその懸念に対処するようになったが、これは新技術であるため、従来のコレクタよりも少し手作業でのチューニングが必要になる。 ...