Javaパフォーマンス第2版

第7章 ヒープメモリのベストプラクティス ヒープメモリのベストプラクティス

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

第5章と第6章では、ガベージ・コレクタがプログラミングにできるだけ影響を与えないようにチューニングする方法の詳細について説明した。ガベージ・コレクタのチューニングは重要だが、より良いプログラミング・プラクティスを利用することで、より良い性能向上が得られることも多い。この章では、Javaでヒープ・メモリを使用するためのベスト・プラクティスのアプローチについて説明する。

ここには相反する2つの目標がある。第一の一般化規則は、オブジェクトの作成は控えめにし、できるだけ早く破棄することである。 メモリの使用量を少なくすることは、ガベージ・コレクターの効率を向上させる最善の方法である。一方、ある種のオブジェクトを頻繁に再作成することは、（たとえGCのパフォーマンスが向上したとしても）全体的なパフォーマンスの悪化につながる可能性がある。これらのオブジェクトを再利用すれば、プログラミングのパフォーマンスが大幅に向上する。 オブジェクトは、スレッドローカル変数、特殊化オブジェクト参照、オブジェクトプールなど、さまざまな方法で再利用できる。 オブジェクトを再利用するということは、オブジェクトが長寿命になり、ガベージコレクタに影響を与えるということだが、適切に再利用すれば、全体的なパフォーマンスは向上する。

この章では、両方のアプローチとそのトレードオフについて説明する。 しかし、まずはヒープ内部で起こっていることを理解するためのツールについて見ていく。

ヒープ分析

GC ログと第 5 章で説明したツールは、GC がアプリケーションに与える影響を理解するのに最適で ある。このセクションで説明するツールは、アプリケーションが現在使用しているオブジェク トについての洞察を提供する。

ほとんどの場合、これらのツールはヒープ内のライブ・オブジェクトに対してのみ動作する。場合によっては、ツールは完全なGCを強制することでそれを達成するため、ツールの使用後にアプリケーションの振る舞いが影響を受ける可能性がある。 他のケースでは、ツールはヒープ内をウォークスルーし、途中でオブジェクトを解放することなく、ライブデータを報告する。しかし、いずれの場合も、ツールは時間とマシンリソースを必要とする。一般に、プログラムの実行測定中には役に立たない。

ヒープヒストグラム

メモリ使用量の削減は重要な目標であるが、ほとんどのパフォーマンスに関するトピックと同様に、利用可能な利点を最大化するための努力に的を絞ることが役立つ。この章の後半で、オブジェクトを初期化する例を見てみよう。Calendar オブジェクトを初期化する。これはヒープを640バイト節約することになるが、アプリケーションが常にこのようなオブジェクトを初期化するのであれば、パフォーマンスに測定可能な差は生じない。どの種類のオブジェクトが大量のメモリを消費しているのかを知るためには、分析を行う必要がある。

最も簡単な方法は、ヒープ・ヒストグラムを使うことである。 ヒープ・ヒストグラムは、ヒープ・ダンプを行わなくても、アプリケーション内のオブジェクトの数を調べることができる簡単な方法である（ヒープ・ダンプは分析に時間がかかり、ディスク容量を大量に消費するため）。 いくつかの特定のオブジェクト・タイプがアプリケーション内のメモリ圧迫の原因となっている場合、ヒープ・ヒストグラムはそれを発見する簡単な方法である。 ...