ガベージコレクタの概要
ガベージコレクタの組み合わせ
- 図ショー7ガベージコレクタ、シリアル、ParNew、パラレル清掃を、CMS、シリアル古い、パラレル古い、G1
- 集電体の代表的なリンクと組み合わせて使用することができます
- シリアル旧CMSは、失敗したバックアップ計画「同時モード故障」として表示されます
並行ガベージコレクションとガベージコレクションの間に並列違い
- 並列に実行並列ガベージコレクションスレッドの複数を意味するが、スレッドは、即ちユーザ待つガベージコレクタに対応する状態に世界を停止する必要がParNew、パラレルオールド、パラレルの清掃を有しています。
- コンカレントガベージコレクション必ずしも同時に行われず、スレッドとスレッドが同時に実行するユーザを指し、交互に行うことができる、対応するガベージコレクタは、CMS、G1を有しています。
マイナーGCとフルGC
マイナーGCは、新世代のガベージコレクションを表し、完全なGCは古いものと新しい世代のガベージコレクションは、主なGCのガベージコレクションは、古い時代を表します。
シリアルコレクター
- 機能
- 新世代のために、複製アルゴリズムを使用するには、コレクションをシングルスレッド
- ガベージコレクションは、すべての作業スレッド中断されます
シリアル/シリアル旧組み合わせコレクタは、以下のように図がある実行しました：
- シナリオ
- クライアントモードでのホットスポットのデフォルト、新世代のガベージコレクタ
- 単一CPU環境、コレクター（ハンドオーバ）オーバーヘッド相互作用シリアル番号スレッドを定義するため、最大の収集効率は、シングルスレッドを得ることができます
- パラメータの設定
- 「-XX：+ UseSerialGC」：明示的にこのパラメータは、シリアルガベージコレクタを追加します。
ParNewコレクタ
- 機能
- 新世代のために、複製アルゴリズムを使用するには、コレクションをマルチスレッド
- スレッドガベージコレクション時にすべてのユーザが停止します
ParNew /シリアル旧組み合わせコレクタは、以下のように図がある実行されます。
- シナリオ
- シリアルに加えて、それが現在唯一のCMSコレクタで動作するので、サーバーモードでは、ParNewコレクタは、コレクターの非常に重要な新世代です。
- しかし、単一CPU環境で、理由はオーバーヘッドスレッドの相互作用のSerailのコレクタよりも良い結果があるでしょう。
- パラメータの設定
- 「-XX：+ UseConcMarkSweepGCを」：CMSの使用を指定した後、コレクターの新世代としてParNewデフォルト
- "-XX：+ UseParNewGC"：使用ParNewを施行
- 「-XX：ParallelGCThreadsは」：ガベージコレクション指定されたスレッドの数は、ParNewのデフォルトのスレッド数とCPUが同じオープンを収集します
- なぜ唯一ParNewは、CMSコレクタと協働することができますか？
- CMSは、古いコレクターとしてですが、; CMSは、（同時）コレクタの最初の真の意味を導入JDK1.5に、初めてガベージコレクションスレッドを実現すると同時に、ユーザスレッド（本質的に）させたHotSpotによって複雑になります従来のコードGCコレクタフレームを使用していない並列の清掃（及びG1）などの他は、独立して実施しながら、;我々は、新世代のJDK1.4既存のコレクタ並列の清掃では動作できず、いくつかのコレクタの残りのシェアフレームのコード部と
パラレル清掃をコレクタ
- 機能
- 新世代のために、複製アルゴリズムを使用するには、コレクションをマルチスレッド
- CMSと他のコレクターフォーカスがスループットの制御を達成するために、可能な限り、ガベージコレクションの休止時間のユーザスレッド、およびパラレルスカベンジコレクターの目標があるときに短縮することである（スループット）
- シナリオ
- コードを実行するには、ユーザーが長い時間を取得することができ、ガベージコレクションの時間を削減するという目標スループットの高い、（ガベージコレクションの時間を短縮するために以下のユーザスレッドの休止時間を意味するものではありません）
- アプリケーションが複数のCPUを持っている上で実行されている場合、休止時間は、プログラムは主に、ユーザとのあまりの相互作用を必要とせずに、バックグラウンドで計算されていることを要件には特に高くはありません
- パラメータの設定
- 「-XX：MaxGCPauseMillis」：それはガベージコレクションにつながる可能性があるため、コントロール最大ガベージコレクションの休止時間、MaxGCPauseMillisを小さく設定し、滞留時間を短縮することができるが、それはスループットが低下することがあり、より頻繁に発生します。
- 「-XX：GCTimeRatio」：セット総ガーベッジコレクション期間の比が、0 <N <100の整数であり、スループットは、サイズGCTimeRatioを設定することと等価です
- 「-XX：+ UseAdptiveSizePolicy」：あなたは、このパラメータをオンにすると、手動で、このような新世代（-Xmn）の大きさとして、いくつかのパラメータの詳細を指定する必要はありません、エデンとサバイバー地域の割合（-XX：SurvivorRation）、プロモーション対象年齢老齢（-XX：PretenureSizeThreshold）と現在のシステム情報を監視JVM収集性能の操作に応じて、これらのパラメータは動的に最適滞留時間又は特定の最大値を提供するように調整され、同様に、この調整が呼び出され、適応制御戦略GC （GC Ergonomiscs）。
- スループット
- 時間/（ユーザコード実行時間+時間のガベージコレクション）を実行してスループット=ユーザコード
シリアル・オールド・コレクター
- 機能
- 古い時間のために、アルゴリズムを整理するためのタグの使用は、シングルスレッドのコレクションの
シリアル/シリアル・オールド・コレクタは、次のように図がある実行されます。
- シナリオ
- 主にクライアント・モード用
- JDK1.5前に（1）と、使用した並列スカベンジコレクタと（JDK1.6のコレクターがあるパラレル古いで使用することができます）で、CMSコレクタのバックアッププランとして（2）：サーバーモードでは2つの目的があります同時コレクションを使用している場合、同時モード故障が起こります
パラレルオールド・コレクター
- 機能
- 古い時間のために、アルゴリズムを整理するためのタグの使用は、マルチスレッドのコレクション
パラレル清掃を/パラレルオールド・コレクタは、次のように図がある実行されます。
- シナリオ
- JDK1.6以降では、特にサーバーモード、マルチCPUの場合には、古い時代のシリアル旧コレクターの代わりに使用します。
- パラメータの設定
- "-XX：+ UseParallelOldGC"：指定パラレルオールド・コレクター
CMSコレクタ
また、同時低い休止コレクタ（同時低ポーズコレクタ）または低レイテンシ（低遅延）ガーベジコレクタとして知られている同時マーククリーンアップ（並行マークスイープ、CMS）コレクタ。
- 機能
- 古い時間のために、最短休止時間の目標、同時コレクションを取得するために明確なラベリングアルゴリズムの使用は、より多くのメモリを必要とします。
- シナリオ
- 与用户交互较多的场景，希望系统停顿时间最短，注重服务的响应速度， 如常见WEB、B/S系统的服务器上的应用。
- 设置参数
- “-XX:+UseConcMarkSweepGC”：指定使用CMS收集器
- CMS收集器运作过程
(1)初始标记（CMS initial mark）,仅标记一下GC Roots能直接关联到的对象,速度很快,但需要"Stop The World"。
(2)并发标记（CMS concurrent mark）,进行GC Roots Tracing的过程,刚才产生的集合中标记出存活对象,应用程序也在运行,并不能保证可以标记出所有的存活对象。
(3)重新标记（CMS remark）,为了修正并发标记期间因用户程序继续运作而导致标记变动的那一部分对象的标记记录,需要"Stop The World"，且停顿时间比初始标记稍长，但远比并发标记短,采用多线程并行执行来提升效率。
(4)并发清除（CMS concurrent sweep）,回收所有的垃圾对象。
CMS收集器运行示意图如下：
- CMS收集器的缺点
- 对CPU资源非常敏感。并发收集虽然不会暂停用户线程，但因为占用一部分CPU资源，还是会导致应用程序变慢，总吞吐量降低，CMS的默认收集线程数量是=(CPU数量+3)/4。
- 无法处理浮动垃圾,可能出现"Concurrent Mode Failure"失败。在并发清除时，用户线程新产生的垃圾，称为浮动垃圾， 这使得并发清除时需要预留一定的内存空间，不能像其他收集器在老年代几乎填满再进行收集，也可以认为CMS所需要的空间比其他垃圾收集器大。如果CMS预留内存空间无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败，这时JVM启用后备预案：临时启用Serail Old收集器，而导致另一次Full GC的产生。
- 产生大量内存碎片。由于CMS基于"标记-清除"算法，清除后不进行压缩操作，产生大量不连续的内存碎片会导致分配大内存对象时，无法找到足够的连续内存，从而需要提前触发另一次Full GC动作。由于空间不再连续，CMS需要使用可用"空闲列表"内存分配方式，这比简单实用"碰撞指针"分配内存消耗大。
G1收集器
- 特点
- 并行与并发，能充分利用多CPU、多核环境下的硬件优势，可以并行来缩短"Stop The World"停顿时间，也可以并发让垃圾收集与用户程序同时进行。
- 分代收集，收集范围包括新生代和老年代 ，能独立管理整个GC堆（新生代和老年代），而不需要与其他收集器搭配，能够采用不同方式处理不同时期的对象。将整个堆划分为多个大小相等的独立区域（Region），新生代和老年代不再是物理隔离，它们都是一部分Region（不需要连续）的集合。
- 结合多种垃圾收集算法，空间整合，不产生碎片，从整体看，是基于标记-整理算法，从局部（两个Region间）看，是基于复制算法，都不会产生内存碎片，有利于长时间运行。
- 可预测的停顿：低停顿的同时实现高吞吐量，G1除了追求低停顿外，还能建立可预测的停顿时间模型，可以明确指定M毫秒时间片内，垃圾收集消耗的时间不超过N毫秒。
- 应用场景
- 面向服务端应用，针对具有大内存、多处理器的机器
- 最主要的应用是为需要低GC延迟，并具有大堆的应用程序提供解决方案。
- 设置参数
- “-XX:+UseG1GC”：指定使用G1收集器
- “-XX:InitiatingHeapOccupancyPercent”：当整个Java堆的占用率达到参数值时，开始并发标记阶段；默认为45
- “-XX:MaxGCPauseMillis”：为G1设置暂停时间目标，默认值为200毫秒
- “-XX:G1HeapRegionSize”：设置每个Region大小，范围1MB到32MB；目标是在最小Java堆时可以拥有约2048个Region
- 为什么G1收集器可以实现可预测的停顿？
G1可以建立可预测的停顿时间模型，是因为：可以有计划地避免在Java堆的进行全区域的垃圾收集，G1跟踪各个Region获得其收集价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region，这就保证了在有限的时间内可以获取尽可能高的收集效率。 - 一个对象被不同区域引用的问题
一个Region不可能是孤立的，一个Region中的对象可能被其他任意Region中对象引用，判断对象存活时，是否需要扫描整个Java堆才能保证准确？在其他的分代收集器，也存在这样的问题。
解决方法：
无论G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描。每个Region都有一个对应的Remembered Set，每次Reference类型数据写操作时，都会产生一个Write Barrier暂时中断操作，然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region （其他收集器：检查老年代对象是否引用了新生代对象）如果不同，通过CardTable(CardTable是Remembered Set的一种实现)把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中。当进行垃圾收集时，在GC根节点的枚举范围加入Remembered Set，就可以保证不进行全局扫描，也不会有遗漏。 - G1收集器运作过程
(1)初始标记（Initial Marking）。仅标记一下GC Roots能直接关联到的对象，且修改TAMS（Next Top at Mark Start）,让下一阶段并发运行时，用户程序能在正确可用的Region中创建新对象，需要"Stop The World"，但速度很快。
(2)并发标记（Concurrent Marking）。 进行GC Roots Tracing的过程，刚才产生的集合中标记出存活对象，耗时较长，但应用程序也在运行，并不能保证可以标记出所有的存活对象。
(3)最终标记（Final Marking）。为了修正并发标记期间因用户程序继续运作而导致标记变动的那一部分对象的标记记录，上一阶段对象的变化记录在线程的Remembered Set Log，这里把Remembered Set Log合并到Remembered Set中。需要"Stop The World"，且停顿时间比初始标记稍长，但远比并发标记短,采用多线程并行执行来提升效率。
(4)筛选回收（Live Data Counting and Evacuation）。首先排序各个Region的回收价值和成本,然后根据用户期望的GC停顿时间来制定回收计划,最后按计划回收一些价值高的Region中垃圾对象。回收时采用"复制"算法，从一个或多个Region复制存活对象到堆上的另一个空的Region，并且在此过程中压缩和释放内存，可以并发进行，降低停顿时间，并增加吞吐量。
G1收集器运行示意图如下：
[1]https://www.cnblogs.com/cxxjohnson/p/8625713.html
