（a）はJMMとガベージコレクションのアルゴリズムを学習JVM

個人ブログのプロジェクトアドレス

私は私に小さな星を与え、スターを指すよう支援することを願ってい✨

多くの場合、Javaを使用しますが、下のは非常にその使用に精通しているだけでなく、StackOverflowのかOOMの時代にはなかった、行くと動揺する理由を見つけることができませんでしたので、彼はJVMを学び始めました。

周志明は最近大きな神が「JVMの深い理解を」書くことという読み、彼は再びそれを読んだ後、再び良く吸収して理解されるであろうネットワーク上の記事と合わせて概念は、比較的深いであることを書きました。

まずは、Java仮想マシンのメモリモデルを見てみましょう（Javaのメモリモデル）

Java仮想マシンのメモリモデル（JMM）

Javaランタイムデータ領域は5つのエリアに分かれています。

これで、仮想マシンのスタック、ネイティブメソッドスタックとプログラムカウンタがあるスレッドにプライベートの、Javaヒープと方法領域がある共有メモリ領域のさまざまなスレッド。

以下は、これらの5つの分野の役割の概要を示します。

プログラムカウンタ：小さなメモリ空間であり、その役割は、現在の実行スレッドのインジケータバイトコードの行番号として見ることができます。あなたは通訳が仕事を所有する場合には、次に実行すべき命令を選択するために、カウンタの値を変更することです。
Java仮想マシン・スタック：そのライフサイクル同じスレッドと同時にスタック・フレーム（スタックフレーム）を作成するときに、それぞれの方法は、ローカル変数のテーブルを格納するための、実行され、スタック操作、動的リンカー、情報方法輸出。各メソッドは、実行処理が完了するまで呼ばれ、それをスタックにスタックから仮想マシンのスタックのスタックフレームに対応します。
ネイティブメソッドは、スタック：仮想マシンのスタックロックの役割は、Java仮想マシンのメソッドのための仮想マシンの実行スタックことを除いて、非常によく似ている（つまり、バイトコード）サービス、およびローカル・スタック方式は、ネイティブメソッドに仮想マシンを使用することですサービス。（ネイティブメソッドインタフェース呼び出しが++非JavaのJavaコード、例えば、CまたはCです）
ヒープ： Java仮想メモリの最大部分が管理しています。Javaヒープは、仮想マシンの起動時に作成されたメモリ領域内のすべてのスレッドで共有されています。唯一の目的のためにこのメモリ領域は、オブジェクトのインスタンスを格納することです。同時に、ヒープは、ガベージコレクタによって管理されるメイン領域であり、従って、しばしば「GCヒープ」（ヒープガベージコレクション）と呼びます。

その後、少し詳しいエデンスペースがサバイバースペースに、サバイバースペースから、そこにある、古いものと新しい世代の：Javaヒープのに細分化することができるようになりましコレクタは基本的に、ゾーニングコレクションアルゴリズムを採用しています。

メソッド領域： Javaヒープ、各スレッドは、インスタントコンパイラ後に仮想マシン、定数、静的変数、コード、等にロードされたクラス情報を格納するために使用される共有メモリ領域であるように（JIT）データ。

ガベージコレクタ

どのようなメモリは、リサイクルする必要がありますか？

ヒープオブジェクトの回復前に、我々は最初のオブジェクトが無効であるかを判断しなければなりません。これらのオブジェクトは、必ず何を「生きている」と（それはもはやオブジェクトへの任意の経路によって参照される）の「死亡した」いるようにする必要があります。

二つの方法の判断があります。

障害に言及する場合、カウンタ値が1だけデクリメントされる;参照カウントオブジェクトは、オブジェクトが別のオブジェクトまたは変数への言及は、カウンタがインクリメントされるカウンタに加算されていない任意の時間カウンタオブジェクトがもはやである0であります使用しています。
GCのルーツと直接的または間接的に到達可能性解析方法にリンクされているすべてのオブジェクトの有効なオブジェクトであり、オブジェクトはGCのルーツに関連付けられていないことは、無効なオブジェクトです。GCのルーツ手段：
Java仮想マシン・スタック（ローカル変数テーブルのスタックフレーム）の参照オブジェクト
メソッド領域静的プロパティクラスオブジェクト参照
メソッドのゾーンオブジェクトリテラルの参照
ネイティブメソッドは、JNI（Nativce法）によって参照されるオブジェクトスタック。

両者の比較：参照カウント法は単純であるが、それは問題を解決することは困難であるが、各オブジェクト参照との間で循環されます。だから、一般的な到達可能性解析アルゴリズムです。

しかし、到達可能性解析アルゴリズムオブジェクト内の到達不能、「死ななければならない」ではない、この時間は、彼らがラベリングプロセスを通過するには、少なくとも二回、実際に対象の死を告げ知らせるために、「保護観察」段階で一時的になります。ファイナライズ（）メソッドとF-キューキューを伴うであろう、あなたは〜特別見つけるために適切な情報を見つけることができます子供の靴を理解したいです

ガベージコレクションのアルゴリズム

マーク-スイープアルゴリズムの最も基本的なコレクションアルゴリズムは、「マーク-スイープ」である（マークスイープ）アルゴリズム：2つの段階、第1のマークのすべてのオブジェクトは、すべてのオブジェクトがマークされて均一なリサイクルマークが完了した後、回復する必要があります。

また、2つの欠点があります：最初は、効率性、マーキングおよびクリアランスプロセスの効率は高くない。第二は、スペースの問題で、あまりにも多くのスペースデブリをクリアした後に個別のメモリの断片化のマークの多くを生成するプログラムを引き起こす可能性があり十分な連続したメモリを見つけることができませんが、その後の実行中に、大きなオブジェクトを割り当てられ、事前に別のガーベッジコレクション動作をトリガしなければならなかったする必要があります。
コピーアルゴリズムは効率の問題を解決するために、使用可能なメモリ容量は二つの等しいサイズに分割され、それによって、それらのみのいずれかを使用。このメモリのコピーが使い果たされる場合は、上記の別のものにまだ生きているオブジェクトになり、その後、メモリ空間はきれいに一度、その後、使用されてきました。利点は限りヒープポインタの移動トップとして、あなたは簡単で、効率的な動作を実現するためにメモリを割り当てることができるということですが、このアルゴリズムのコストは、良いよりも少し害を感じ、半分のメモリによって削減することです...

私は本の中で言及され、現在のJava仮想マシンのほとんどは、新しい世代を回復するために、このコレクションのアルゴリズムを使用しています。

それぞれ、大きく2つの小さなエデン生存者空間にメモリ空間を分割して1比が、メモリ空間：新世代は98％Chaosheng遅い死オブジェクト、それが1を必要としませんエデン利用とどこサバイバー。使い捨てサバイバースペースの別の部分をコピーし、そして最後にスペースエデンを一掃するために、エデンとサバイバーも生きているオブジェクトのリサイクルだけサバイバーを使用した場合。

HotSpot VMのデフォルトの1：サイズ比は、エデンとサバイバー8である、すなわち、中空空間のそれぞれの新しい世代が新世代（+ 10％80％）の総メモリ容量の90％です。もちろん、我々はすべての回復は、ライブオブジェクトの10％以上であることを保証することはできません、サバイバースペースが十分でないとき、の古い割り当て保証に依存する必要があります（推進ハンドル）。

マーク-照合アルゴリズムは、（マーク・コンパクト）コレクションアルゴリズムをコピーし、高い対象の生存でより多くのコピー操作を実行する必要があり、効率が低くなります。だから、複製歳コレクションアルゴリズムを使用していませんが、タグの使用は、アルゴリズム（マーク・コンパクト）を整理します。

まだラベリング処理と「マーク-スイープ」アルゴリズム同じですが、その後の工程は、直接クリーンアップするオブジェクトを再利用していないが、すべての存続のオブジェクトが最後に移動され、その後、境界の外側に直接メモリを一掃。

世代別コレクションアルゴリズム「世代のコレクションアルゴリズム」（世代Collectio）、あなたは各時代の特徴を採用することができるようにオブジェクトのメモリのライフサイクルに応じたが、いくつかの作品、通常は新世代へのJavaヒープと昔に分かれています最も適切なコレクションアルゴリズム。たとえば、新しい世代に、各ガベージコレクションは、選択アルゴリズムをコピーし、ほんの数が生き残る、死者多数のオブジェクトを持つことになり、唯一のコレクションを完了するために、ライブオブジェクトの少量の再生の費用を支払う必要があります。または「マーク - 仕上げ」リサイクルのためのアルゴリズム - オブジェクトの高い生存率で、余分なスペースがその保証に割り当てられていないがあるので、古い時代には、あなたは「クリーンアップマーク」を使用しなければなりません。

メモリモデルの最初のレコード、次のレコードガベージコレクタについての最初の記事。