　Javaテクノロジが登場してから早20年以上経過しますが、その動作原理は大きくは変わっていません。クラウド化に伴い、マシンリソースのスケールアップやスケールアウトが臨機応変に、場合によっては自動でできるようになってはいますが、アプリケーションレイヤやプラットフォームレイヤにおいては、実利用に際しての調整はやはり必要です。お金で解決？いえいえ、むやみやたらとお金を使えばいいというわけではありません。Java の原理をしっかりと学んだ上で、ぜひSave your moneyな運用を実践しましょう。

オブジェクト指向言語固有の懸念事項

Java の原理をご紹介していく前に、オブジェクト指向とは何でしょうか？
オブジェクト指向とは、現実世界をオブジェクト中心にモデル化する考え方です。これによる恩恵は数多く存在し、こと顧客要求が随時変化する、または完全に定まらない状況下で、システム開発を強いられる現状においての適用度は、非常に高いといわれております。

とはいえ、実開発や運用においては無数に存在するオブジェクトの管理に頭を悩ませられるケースも多いようで、しばしばメモリリークの原因となったり、深刻なパフォーマンス劣化の原因となったりするケースがあります。

オブジェクトを生成すると、システム上（JVM内のヒープ）のリソースを消費します。生成されたオブジェクトはいつか不要になり、適切なタイミングで破棄する必要があります。

オブジェクトのライフサイクルとスコープ

プログラム実行時に生成されるオブジェクトの種類は多岐にわたり、コード内で生成されるオブジェクトに関わらず、アプリケーションサーバが生成するもの、利用しているフレームワークによって生成されるもの、JVM 自身が生成するものがあり、それぞれによって特性が異なります。

これら全てのオブジェクトについては、JVM 内部の実行時データ領域であるヒープ領域に割り当てられます。ヒープ領域に割り当てられたオブジェクトはどのオブジェクトからも参照されなくなると、ガベージコレクションによって回収されます。その後、別のオブジェクトを割り当てることができるようにその領域は解放されます。

ガベージコレクションが動作するタイミングは、JVM 仕様では明確に決められておらず、HotSpot や、JRockit 等のJVM 実装に委ねられています。

ガベージコレクションの動作１ – 基本形 –

ガベージコレクションの動作には様々なアルゴリズムがありますが、基本は Mark-Sweep-Compaction になります。
Mark-Sweep-Compaction

Mark　　　　　　参照可能なオブジェクトにフラグを付ける
Sweep　　　　　オブジェクトの使用している領域を解放する
Compaction　　連続したヒープ領域にオブジェクトが配置されるようにして圧縮する

しかしながら、この動作は動作コストが大きく、一度発生するとアプリケーションの応答が停止することが知られています（Stop-The-World）。
また、この停止時間はヒープのサイズが大きければ大きいほど長くなり（数十秒～数分）、Javaシステムの性能用件上の大きな問題としてしばしば話題にあがります。ヒープサイズが小さく常にオーバーフローと隣り合わせの状況ではその頻発によりアプリケーションの動作がほとんど行われない状況に陥る可能性もあります。

オブジェクトの世代を考慮しないガベージコレクタ