TOP > 技術メモ > Java > Javaチューニング（性能改善）

Javaチューニング（性能改善）

Javaのメモリ空間のイメージについて

Javaのメモリ（Serial Collector, Parallel Collector 方式）空間のイメージ

Javaのメモリ（Serial Collector, Parallel Collector 方式）空間のイメージ ※Nativeメモリ領域は、Cヒープ、スレッドスタック

Javaのメモリ（G1GC方式）空間のイメージ

Javaのメモリ（G1GC方式）空間のイメージ） ※Nativeメモリ領域は、Metaspace領域、Cヒープ、スレッドスタック ※Permanent領域が無くなっている

FullGCの抑制とそれによる影響について

FullGCを抑制するには、例えば以下のパラメータを設定する。

  • -XX:+UseParallelOldGC
  • -XX:NewRatio=1
  • -XX:SurvivorRatio=2
  • -XX:TargetSurvivorRatio=100
  • -XX:-UseAdaptiveSizePolicy
※ここでは Serial Collector, Parallel Collector 方式のGCを対象としています（Concurrent Mark-Sweep Collector方式やG1GC方式は対象外）。
GCの種類とシステム停止時間については「GCの種類と方式について」メモを参照。

Full GCを起こさないようにチューニングした際のメリデメですが、自分が思いつくのは以下。

メリット（2点）
  • 止まることが許されないクリティカルなシステムで使用できる
  • 「長時間の Stop the World（システム停止時間）」の頻度を下げることでの性能改善
デメリット（3点）
  • メモリリークが発生しやすい（FullGCで回収対象となるオブジェクトが残る）
  • Scavenge GCの実行回数が増え、実行時間も長くなり、性能劣化を招く
  • 実装アプリケーション以外の問題が起きやすい（Java自体やJava使用製品など）

「システムが止まることが許されないシステムで使用できる」と言っても
Scavenge GC も、システム停止は発生しているし、FullGCを抑えた場合、こちらの回数が増えたり、時間が長くなったりする場合が多い。
特に、FullGCが起きていた時には出なかった問題が、結構な頻度で出る（Java自体のバグ（RMIのメモリリークなど）や、Javaを使用した製品のバグ（これも大体はメモリリークやNativeな実装問題））
例えば、ちゃんとリソースを閉じなければ、Full GCされるまで残るし、
また、Nativeな重い処理をガンガンやっている場合、GC時に排他がかかり（Native処理の完了までGCがロックされる）JVMフリーズの原因となったりする。
なので、FullGCを抑制した際のデメリットも馬鹿にできない（現にハマりました）。

▲ページの先頭へ