Java虚拟机------垃圾收集器

深藏阁楼爱情的钟 2022-04-25 02:08 261阅读 0赞

JVM系列最核心的文章没有之一：

## 引用 ##

### 强引用 ###

只要引用存在,垃圾回收器就永远不会回收。当内存空足，Java虚拟机宁愿抛出**OutOfMemoryError**错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。

<table> 
 <tbody> 
  <tr> 
   <td><pre><span>1</span><br></pre></td> 
   <td><pre><span>Object obj = <span>new</span> Object();</span><br></pre></td> 
  </tr> 
 </tbody> 
</table>

//可直接通过obj取得对应的对象 如obj.equels(new Object());

而这样 obj对象对后面new Object的一个强引用，只有当obj这个引用被释放之后，对象才会被释放掉，这也是我们经常所用到的编码形式。

### 软引用 ###

如果一个对象只具有软引用，则**内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现**内存敏感的高速缓存\*\*

软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。非必须引用，内存溢出之前进行回收，可以通过以下代码实现

<table> 
 <tbody> 
  <tr> 
   <td><pre><span>1</span><br><span>2</span><br><span>3</span><br><span>4</span><br></pre></td> 
   <td><pre><span>Object obj = <span>new</span> Object();</span><br><span>SoftReference&lt;Object&gt; sf = <span>new</span> SoftReference&lt;Object&gt;(obj);</span><br><span>obj = <span>null</span>;</span><br><span>sf.get();<span>//有时候会返回null</span></span><br></pre></td> 
  </tr> 
 </tbody> 
</table>

### 弱引用 ###

弱引用与软引用的区别在于：只具有弱引用的对象拥有**更短暂**的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，**一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存**。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。  
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。

弱引用是在第二次垃圾回收时回收，**短时间内通过弱引用取对应的数据，可以取到**，当执行过第二次垃圾回收时，将返回null。  
弱引用主要用于监控对象是否已经被垃圾回收器标记为即将回收的垃圾，可以通过弱引用的isEnQueued方法返回对象是否被垃圾回收器标记。

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>生命周期</th> 
   <th>数据</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>软引用:</strong></td> 
   <td>内存空间足够，垃圾回收器就不会回收它</td> 
   <td>内存空间足够是都可以取到.(<strong>存敏感的高速缓存</strong>)</td> 
  </tr> 
  <tr> 
   <td><strong>弱引用</strong>()</td> 
   <td>不管当前内存空间足够与否，都会回收它</td> 
   <td>回收短时间内通过弱引用取对应的数据，可以取到,执行过第<strong>二次垃圾回收</strong>时，将返回null。</td> 
  </tr> 
 </tbody> 
</table>

### 虚引用 ###

“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。  
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。

对被引用对象的生存时间不影响；无法通过虚引用来取得一个对象实例；为一个对象设置虚引用关联的**唯一目的**就是能在这个对象被收集器回收时收到一个系统通知；jdk提PhantomReference类来实现虚引用。

## 对象的可达性分析 ##

判断对象存活，常用的方式是**引用计数算法、可达性分析**：主流的商用程序语言的主流实现中是通过可达性分析；

引用计数算法基本思想：给对象中添加一个引用计数器，每当对象被一个地方引用，计数器便+1；当引用失效时，计数器-1。当对象的计数器为0时，该对象便是一个不被使用的对象，即“死亡”。

### 引用计数法 ###

\[![计数法][izjqxJ.md.png]

引用计数器实现简单，效率高。然而难以解决对象之间相互循环引用的问题（两个失效对象相互保存了对方的指针）。故JVM判定对象是否存活，并没有使用引用计数器，而是使用可达性分析算法。

可达性分析基本思想：通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（即不可达）时，则证明此对象是不可用的。

GC Roots对象：

1.  虚拟机栈（栈帧中的本地变量表）中引用的对象。
2.  方法区中类静态属性引用的对象。
3.  方法区中常量引用的对象。
4.  本地方法栈中JNI（Java Native Interface即一般说的Native方法）引用的对象。

\[![izjHGF.md.png][]

目前可达性分析算法已是主流算法，原因是，引用计数器算法无法解决**对象互相引用**的问题

### 对象的生死 ###

不可达的对象真正死亡**需要两次标记**

可达性分析判断过程:

对对象进行可达性分析之后，发现他没有**任何引用链相连**，则对他进行**第一次标记\*，并进行一次筛选，筛选条件是是否需要执行finalize()方法，当对象没有覆盖finalize方法或已经finalize方法已经被调用过，则认为没有必要执行，如果判断为有必要执行，则会将他放入一个叫做F-Queue的队列中，稍后JVM会**自动建立一个低优先级\*\*的finalizer线程去执行这些对象的finalize方法，Finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中重新与引用链上的任何一个对象建立关联那么他被移除出“即将回收”的集合，否则就被回收了。

<table> 
 <tbody> 
  <tr> 
   <td><pre><span>1</span><br><span>2</span><br><span>3</span><br><span>4</span><br><span>5</span><br><span>6</span><br><span>7</span><br></pre></td> 
   <td><pre><span><span>@Override</span></span><br><span></span><br><span>  <span><span>protected</span> <span>void</span> <span>finalize</span><span>()</span> <span>throws</span> Throwable </span>{
         </span><br><span></span><br><span>  System.out.println(<span>"finalized"</span>);</span><br><span></span><br><span>  }</span><br></pre></td> 
  </tr> 
 </tbody> 
</table>

## 垃圾收集器-GC算法 ##

*  **最基础**的收集算法是“标记-清除”（Mark-Sweep）算法，此方法分为两个阶段：标记、清除。
    
    标记所有要回收对象,标记完成后,统一回收所有被标记的对象
    
    不足:一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

![izj7PU.png][]

*  **复制算法**:它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

**无内存碎片**，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。缺点：实际可用内存缩小为了原来的一半。

大多数的对象(98%)存活时间很短,不需要1:1划分两个区域

1块较大的Eden和2快较小的Survivor空间,每次使用eden和一块survivor之后,将保存存活的对象复制到另外一块survivor区域里

survivor空间不够需要老年代进行分配担保

**HotSpot虚拟机默认Eden和Survivor的大小比例是8:1:1；浪费10%。**

![复制算法][izjb24.jpg]

*  **标记-整理算法**
    
    标记需要回收的对象,将存活对象移动到一段,然后将端边界以外的内存回收
    
    ![izjo5T.md.png][]

*  **分代收集算法(当前商业虚拟机采用的垃圾收集算法)** 
    
        将堆分为新生代和老年代
                  新生代每次都有少量对象存活,用复制算法,只需付出付出少量存活对象的成本
                  老年代对象存活率高,用标记-清除-或者标记整理算法(没有额外空间进行分配担保)

## 垃圾收集器-GC方式: ##

Minor GC：从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。每次 Minor GC 会清理年轻代的内存。

Major GC 是清理老年代或者永久代。

Full GC 是清理整个堆空间—包括年轻代和老年代或者永久代。

<table> 
 <thead> 
  <tr> 
   <th style="text-align:center;"></th> 
   <th style="text-align:center;">清理</th> 
   <th style="text-align:center;">线程</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="text-align:center;">Major GC</td> 
   <td style="text-align:center;">老年代或者永久代</td> 
   <td style="text-align:center;">并发的处理而不用停掉</td> 
  </tr> 
  <tr> 
   <td style="text-align:center;">Full GC</td> 
   <td style="text-align:center;">清理整个堆空间</td> 
   <td style="text-align:center;">停掉所有(stop-the-world)</td> 
  </tr> 
 </tbody> 
</table>

## 内存分配策略 ##

对象优先在Eden分配：大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够大的连续空间进行分配时，虚拟机将发起一次Minor GC，此时对象会进如survivor区，当对象满足一些条件后会进入老年代。

三种方式进入老年代：

长期存活的对象将进入老年代：虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的**年龄增加到一定程度**（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。

如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

大对象:需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组

**大对象直接进入老年代：**虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。

**空间分配担保：**在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。

如果不成立，则虚拟机会查看XX:HandlePromotionFailure设置值是否允许担保失败。

如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。

## 垃圾收集器———收集器 ##

收集器就是内存回收的具体实现。

java虚拟机规范没有对收集器应该如何实现有任何规定，因为不同版本、不同厂商的虚拟机提供的垃圾收集器都可能会有很大的差异。

目前讨论jdk1.7之后的hotspot虚拟机（这个版本正式提供了商用的G1收集器，之前都是实验状态）。

### 垃圾收集器———并行和并发 ###

并行（Parallel）：指多条垃圾收集线程并行工作，但是此时：**用户线程**仍然处于**线程等待**状态。

并发（Concurrent）：指用户线程和垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在**继续运行**，而垃圾收集程序运行于另一个cpu上。

### 垃圾收集器-Serial ###

Serial收集器是最基础、历史最悠久的新生代的收集器。

特点：单线程、stop-the-world 、复制算法

缺点：影响用户响应时间

优点：回收时简单高效、对于限定单个cpu环境下，serial收集器由于没有线程交互的开销，专心做垃圾收集，可以获得最高的单线程收集效率。

所以：serial 收集器 对于运行在client模式下的虚拟机来说，是一个很好的选择。

SerialOld收集器是Serial的**老年代收集器**，采用“标记-整理”

![izjIaV.md.png][]

### 垃圾收集器-ParNew ###

ParNew收集器其实是Serial的多线程版本，除了他是使用多条线程来进行垃圾回收之外和Serial是完全一样的。新生代收集器

特点：多线程、stop-the-world

缺点：单个cpu下，运行效果甚至没Serial好。

优点点：回收时简单高效、对于限定多个cpu环境下，效果比serial好，相比其它多线程收集器它可以和CMS收集器配合使用。

所以：parnew收集器是运行在server模式下的首选收集器。

![izjg2Q.md.jpg][]

### 垃圾收集器-Parallel Scanvenge ###

Parallel Scanvenge收集器是一个新生代收集器，采用复制算法。

特点：收集新生代，复制算法，多线程，高吞吐、自适应

1、与其它的收集器侧重垃圾回收时用户的停顿时间不同，它主要侧重与吞吐量，吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。

停顿时间越短就越适合需要与用户交互的程序，高吞吐量则是可以高效率地利用cpu时间尽快完成任务。

2、他有一个自适应开关(-XX:+UseAdaptiveSizePolicy)：打开后，用户只需要把基本的内存数据（堆最大，初始量）设置好，然后设置更关注最大停顿时间或者更关注吞吐量，收集器会把细节参数自动调节。

Parallel Old 老年代收集器，采用标记-整理算法。

![izjWKs.jpg][]

### 垃圾收集器-CMS ###

CMS（concurrent mark sweep）收集器是一个以获取最短回收停顿时间为目标的老年代收集器。

特点：并发收集、低停顿。

基于 标记-清除算法实现，但是整个过程比较复杂一些。过程分为4步：

1.  初始标记：仅仅标记GCRoot能直接关联到的对象。速度很快，“stop the world”
2.  并发标记：GCRoot Tracing。耗时长和用户线程同步。
3.  重新标记：修正并发标记时，由于用户程序运行导致的标记变动。“stop the world”停顿稍长一些。
4.  并发清除：耗时长，和用户线程同步。

缺点：吞吐量会变低、浮动垃圾无法处理、标记-清除的碎片（设置参数是 fullgc前开启碎片整理功能，gc停顿时间延长）。

![izjhbq.jpg][]

### 垃圾收集器-G1 ###

G1（Garbage-First）收集器是当今收集器领域最前沿成果之一。2004年sun发表第一篇G1论文，10年后才开发出G1的商用版本。

hotspot开发团队赋予它的使命：未来替调CMS收集器。

特点：

1.  并行与并发：利用多cpu缩短stop-the-world的时间，使用并发方式解决其它收集器需要停顿的gc动作。
2.  分代收集：新老代收集区分对待。
3.  空间整合：G1从整理看是基于标记-整理，但是局部看是基于复制算法实现的，不会产生碎片。
4.  可预测的停顿：能够让使用者指定在M毫秒的时间片段上，消耗在垃圾回收的时间不得超过N毫秒。

过程：初始标记、并发标记、最终标记、筛选回放。前三个和CMS一致，筛选回放是根据用户设置的停顿目标来选择回收价值最高的进行回收。

![izj5V0.md.jpg][]

## 垃圾回收器比较 ##

<table> 
 <thead> 
  <tr> 
   <th>GC器</th> 
   <th>特点</th> 
   <th>优点</th> 
   <th>缺点</th> 
   <th>应用场景</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Serial</td> 
   <td>单线程、stop-the-world 、复制算法</td> 
   <td>回收时简单高效、对于限定单个cpu环境下，serial收集器由于没有线程交互的开销，专心做垃圾收集，可以获得最高的单线程收集效率。</td> 
   <td>stop the world给用户带来不良体验，如计算机每运行一段时间就暂停下来响应几分钟处理垃圾收收集。</td> 
   <td>client模式下的默认新生代收集器。</td> 
  </tr> 
  <tr> 
   <td><strong>ParNew**</strong>收集器*</td> 
   <td>多线程、stop-the-world</td> 
   <td>回收时简单高效、对于限定多个cpu环境下，效果比serial好，相比其它多线程收集器它可以和CMS收集器配合使用。</td> 
   <td></td> 
   <td>运行在Server模式下的VM首选新生代收集器。</td> 
  </tr> 
  <tr> 
   <td><strong>Parallel Scavenge</strong></td> 
   <td>收集新生代，复制算法，多线程，高吞吐、自适应</td> 
   <td>更关注吞吐量，即吞吐量</td> 
   <td>牺牲停顿时间，交互性差；</td> 
   <td>适用于后台运算而不需要太多的交互的任务。</td> 
  </tr> 
  <tr> 
   <td>CMS</td> 
   <td>并发收集、低停顿。</td> 
   <td>并发收集；低停顿。</td> 
   <td>吞吐量会变低、浮动垃圾无法处理、标记-清除的碎片（设置参数是 fullgc前开启碎片整理功能，gc停顿时间延长）。</td> 
   <td>在互联网站或者B/S系统的服务端上，<strong>重视服务的响应速度</strong>，希望系统停顿时间最短，给用户带来较好的体验。</td> 
  </tr> 
  <tr> 
   <td>G1</td> 
   <td></td> 
   <td>1.并发与并行；2.分代收集；3.空间整合；4.可预测的停顿。</td> 
   <td></td> 
   <td>面向服务端应用。</td> 
  </tr> 
 </tbody> 
</table>

[izjqxJ.md.png]: /images/20220210/9b1ba7ec4ff249f5ac38b19dd6e2706a.png
[izjHGF.md.png]: /images/20220210/94dede2ce3ce4fc2a357ad6483b627ca.png
[izj7PU.png]: /images/20220210/1e81dec6e7b249fb9735b5abe8a65338.png
[izjb24.jpg]: /images/20220210/a30b2c1d6c664bec95f9f2c50f6c3149.png
[izjo5T.md.png]: /images/20220210/f1ab32b8af5f48d5b66c20117f5c38c5.png
[izjIaV.md.png]: /images/20220210/3139a03c9d944e9589c458599869e0a9.png
[izjg2Q.md.jpg]: /images/20220210/b7307e1f36bb43c89274da589f7aee48.png
[izjWKs.jpg]: /images/20220210/b05cc17594ac4e8ab8fc8856121891be.png
[izjhbq.jpg]: /images/20220210/144dddb06a83460590aac2d1e2f7470b.png
[izj5V0.md.jpg]: /images/20220210/51f91edd17ef4902a2b5dd46d8c2f6e3.png