垃圾回收相关概念
前言
什么是垃圾
- 垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾。
- 如果不及时对内存中的垃圾进行清理，这些垃圾对象所占的内存空间会一直保留到应用程序结束，被保留的空间无法被其他对象使用。甚至可能导致内存溢出。
为什么需要GC
- 对于高级语言来说，一个基本认知是如果不进行垃圾回收，内存迟早都会被消耗完
- 除了释放没用的对象，垃圾回收也可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端，以便JVM将整理出的内存分配给新的对象。
- 随着应用程序所应付的业务越来越庞大、复杂，用户越来越多，没有GC就不能保证应用程序的正常进行。而经常造成STW的GC又跟不上实际的需求，所以才会不断地尝试对GC进行优化。
Java垃圾回收机制
- 自动内存管理，无需开发人员手动参与内存的分配与回收，这样降低内存泄漏和内存溢出的风险
- 没有垃圾回收器，java也会和cpp- 样，各种悬垂指针，野指针，泄露问题已。
- 自动内存管理机制，将程序员从繁重的内存管理中释放出来，可以更专心地专注于业务开发
- oracle官网关于垃圾回收的介绍
回收频率
- Java堆是垃圾收集器的工作重点。
- 垃圾回收器可以对年轻代回收，也可以对老年代回收，甚至是全堆和方法区的回收。
- 从次数上讲:
- 频繁收集新生区
- 较少收集老年区
- 基本不动方法区
System.gc()的理解
- 在默认情况下，通过System.gc()实则是调用Runtime.getRuntime().gc()，会显式触发Full GC， 同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
- 然而System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用。
- JVM实现者可以通过System.gc()调用来决定JVM的GC行为。而-一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，如我们正在编写一个性能基准，我们可以在运行之间调用System.gc()。
GC例子分析
/**
* -XX:+PrintGCDetails
*/
public class LocalVarGC {
public void localvarGC1() {
byte[] buffer = new byte[10 * 1024 * 1024];//10MB
System.gc();//同一方法栈无法回收buffer
}
public void localvarGC2() {
byte[] buffer = new byte[10 * 1024 * 1024];
buffer = null;
System.gc();//回收了buffer
}
public void localvarGC3() {
{
byte[] buffer = new byte[10 * 1024 * 1024];
}
System.gc();//同一方法栈无法回收buffer
}
public void localvarGC4() {
{
byte[] buffer = new byte[10 * 1024 * 1024];
}
int value = 10;
System.gc();//现在可以回收buffer，在局部变量表中value已经占用了buffer的槽
}
public void localvarGC5() {
localvarGC1();
System.gc();//可以回收，因为栈帧已经结束，buffer引用已经销毁
}
public static void main(String[] args) {
LocalVarGC local = new LocalVarGC();
local.localvarGC1();
}
}
运行参数：-XX:+PrintGCDetails,大对象直接进入老年代
- localvarGC1方法运行结果
同一栈帧，buffer还是强引用，无法回收
[GC (System.gc()) [PSYoungGen: 14141K->10728K(75776K)] 14141K->10912K(249344K), 0.0042372 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 10728K->0K(75776K)] [ParOldGen: 184K->10822K(173568K)] 10912K->10822K(249344K), [Metaspace: 3025K->3025K(1056768K)], 0.0042254 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 75776K, used 1951K [0x000000076b600000, 0x0000000770a80000, 0x00000007c0000000)
eden space 65024K, 3% used [0x000000076b600000,0x000000076b7e7c68,0x000000076f580000)
from space 10752K, 0% used [0x000000076f580000,0x000000076f580000,0x0000000770000000)
to space 10752K, 0% used [0x0000000770000000,0x0000000770000000,0x0000000770a80000)
ParOldGen total 173568K, used 10822K [0x00000006c2200000, 0x00000006ccb80000, 0x000000076b600000)
object space 173568K, 6% used [0x00000006c2200000,0x00000006c2c91b58,0x00000006ccb80000)
Metaspace used 3046K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 331K, capacity 388K, committed 512K, reserved 1048576K
- localvarGC2方法运行结果
buffer无引用，被回收
[GC (System.gc()) [PSYoungGen: 14141K->872K(75776K)] 14141K->880K(249344K), 0.0004764 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 872K->0K(75776K)] [ParOldGen: 8K->585K(173568K)] 880K->585K(249344K), [Metaspace: 3070K->3070K(1056768K)], 0.0034283 secs] [Times: user=0.17 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 75776K, used 1951K [0x000000076b600000, 0x0000000770a80000, 0x00000007c0000000)
eden space 65024K, 3% used [0x000000076b600000,0x000000076b7e7c68,0x000000076f580000)
from space 10752K, 0% used [0x000000076f580000,0x000000076f580000,0x0000000770000000)
to space 10752K, 0% used [0x0000000770000000,0x0000000770000000,0x0000000770a80000)
ParOldGen total 173568K, used 585K [0x00000006c2200000, 0x00000006ccb80000, 0x000000076b600000)
object space 173568K, 0% used [0x00000006c2200000,0x00000006c2292710,0x00000006ccb80000)
Metaspace used 3102K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 337K, capacity 388K, committed 512K, reserved 1048576K
- localvarGC3方法运行结果
buffer在代码块中，在同一栈帧中GC无法回收buffer，老年区还是10826K
[GC (System.gc()) [PSYoungGen: 14141K->840K(75776K)] 14141K->11088K(249344K), 0.0042873 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 840K->0K(75776K)] [ParOldGen: 10248K->10826K(173568K)] 11088K->10826K(249344K), [Metaspace: 3071K->3071K(1056768K)], 0.0052585 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 75776K, used 1951K [0x000000076b600000, 0x0000000770a80000, 0x00000007c0000000)
eden space 65024K, 3% used [0x000000076b600000,0x000000076b7e7c68,0x000000076f580000)
from space 10752K, 0% used [0x000000076f580000,0x000000076f580000,0x0000000770000000)
to space 10752K, 0% used [0x0000000770000000,0x0000000770000000,0x0000000770a80000)
ParOldGen total 173568K, used 10826K [0x00000006c2200000, 0x00000006ccb80000, 0x000000076b600000)
object space 173568K, 6% used [0x00000006c2200000,0x00000006c2c92808,0x00000006ccb80000)
Metaspace used 3108K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 337K, capacity 388K, committed 512K, reserved 1048576K
- localvarGC4方法运行结果
现在可以回收buffer，同一栈帧中，在局部变量表中value已经占用了buffer的槽，buffer已无引用。
[GC (System.gc()) [PSYoungGen: 14141K->840K(75776K)] 14141K->848K(249344K), 0.0005299 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 840K->0K(75776K)] [ParOldGen: 8K->584K(173568K)] 848K->584K(249344K), [Metaspace: 3058K->3058K(1056768K)], 0.0036757 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 75776K, used 1951K [0x000000076b600000, 0x0000000770a80000, 0x00000007c0000000)
eden space 65024K, 3% used [0x000000076b600000,0x000000076b7e7c68,0x000000076f580000)
from space 10752K, 0% used [0x000000076f580000,0x000000076f580000,0x0000000770000000)
to space 10752K, 0% used [0x0000000770000000,0x0000000770000000,0x0000000770a80000)
ParOldGen total 173568K, used 584K [0x00000006c2200000, 0x00000006ccb80000, 0x000000076b600000)
object space 173568K, 0% used [0x00000006c2200000,0x00000006c22922f8,0x00000006ccb80000)
Metaspace used 3079K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 335K, capacity 388K, committed 512K, reserved 1048576K
- localvarGC5方法运行结果
可以回收，因为栈帧已经结束，buffer引用已经销毁
[GC (System.gc()) [PSYoungGen: 14141K->10744K(75776K)] 14141K->10940K(249344K), 0.0045774 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[Full GC (System.gc()) [PSYoungGen: 10744K->0K(75776K)] [ParOldGen: 196K->10822K(173568K)] 10940K->10822K(249344K), [Metaspace: 3026K->3026K(1056768K)], 0.0041189 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (System.gc()) [PSYoungGen: 0K->0K(75776K)] 10822K->10822K(249344K), 0.0002469 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 0K->0K(75776K)] [ParOldGen: 10822K->582K(173568K)] 10822K->582K(249344K), [Metaspace: 3026K->3026K(1056768K)], 0.0037200 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
PSYoungGen total 75776K, used 1951K [0x000000076b600000, 0x0000000770a80000, 0x00000007c0000000)
eden space 65024K, 3% used [0x000000076b600000,0x000000076b7e7c88,0x000000076f580000)
from space 10752K, 0% used [0x0000000770000000,0x0000000770000000,0x0000000770a80000)
to space 10752K, 0% used [0x000000076f580000,0x000000076f580000,0x0000000770000000)
ParOldGen total 173568K, used 582K [0x00000006c2200000, 0x00000006ccb80000, 0x000000076b600000)
object space 173568K, 0% used [0x00000006c2200000,0x00000006c2291bd8,0x00000006ccb80000)
Metaspace used 3048K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 331K, capacity 388K, committed 512K, reserved 1048576K
内存溢出与内存泄漏
-
内存泄漏（memory leak） :是指程序在申请内存后，无法释放已申请的内存空间（即使对象不再使用了，但是虚拟机没有释放），一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。
-
内存溢出（out of memory） :指程序申请内存时，没有足够的内存供申请者使用，并且垃圾收集器也无法提供更多内存。此时就会报错OOM,即所谓的内存溢出。
内存泄漏的分类
- 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
- 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
- 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
- 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
内存泄漏案例
-
单例模式：单例的生命周期和应用程序是一样长的，所以单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。
-
一些提供close的资源未关闭导致内存泄漏数据库连接(dataSourse.getConnection())，网络连接(socket)和io连接必须手动close，否则是不能被回收的。
内存溢出原因
- 1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
- 2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
- 3.代码中存在死循环或循环产生过多重复的对象实体；
- 4.使用的第三方软件中的BUG；
- 5.启动参数内存值设定的过小
内存溢出的解决方案
- 第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数调整)
- 第二步，检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。
- 第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。
- 第四步，使用内存查看工具动态查看内存使用情况
- 重点排查以下几点：
-
1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
-
2.检查代码中是否有死循环或递归调用。
-
3.检查是否有大循环重复产生新对象实体。
-
4.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
-
5.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。
-
Stop The World
Stop-the-World，简称STW，指的是GC事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为STW。
-
可达性分析算法中枚举根节点(GC Roots)会导致所有Java执行线程停顿。
- 分析工作必须在一个能确保一致性的快照中进行
- 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
- 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证
-
被STW中断的应用程序线程会在完成GC之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少STW的发生。
-
STW事件和采用哪款GC无关，所有的GC都有这个事件。
-
哪怕是G1也不能完全避免Stop-the-world 情况发生，只能说垃圾回收器越来越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
-
STW是JVM在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
-
开发中不要用System.gc(),会导致Stop-the-world的发生。
垃圾回收的并行与并发
- 并发： 多个事件在同一时间段发生
- 在操作系统中，是指一个时间段中有几个程序都处于已启动运行到运行完毕之间，且这几个程序都是在同一个处理器上运行。
- 并发不是真正意义上的“同时进行”，只是CPU把一个时间段划分成几个时间片段(时间区间)，然后在这几个时间区间之间来回切换，由于CPU处理的速度非常快，只要时间间隔处理得当，即可让用户感觉是多个应用程序同时在进行。
- 并行： 多个的事件在同一时间点发生
- 当系统有一个以上CPU时，当一个CPU执行一个进程时，另一个CPU可以执行另一个进程，两个进程互不抢占CPU资源，可以同时进行，我们称之为并行(Parallel)。其实决定并行的因素不是CPU的数量，而是CPU的核心数量，比如一个CPU多个核也可以并行。
并行，并发，串行
在谈论垃圾收集器的上下文语境中，它们可以解释如下:
- 并行(Parallel) :指多条垃圾收集线程并行工作，但此时用户线程仍处于等待状态。
- 如ParNew、 Parallel Scavenge、 Parallel 0ld;
- 串行(Serial)
- 相较于并行的概念，单线程执行。
- 如果内存不够，则程序暂停，启动JVM垃圾回收器进行垃圾回收。回收完，再启动程序的线程。
- 并发(Concurrent) :指用户线程与垃圾收集线程可能会交替执行，
- 如: CMS、G1
安全点与安全区域
安全点
-
程序执行时并非在所有地方都能停顿下来开始GC，只有在特定的位置才能停顿下来开始GC，这些位置称为“安全点(Safepoint)”
-
Safe Point的选择很重要，如果太少可能导致GC等待的时间太长，如果太频繁可能导致运行时的性能问题。大部分指令的执行时间都非常短暂,通常会根据“是否具有让程序长时间执行的特征”为标准。比如:选择一些执行时间较长的指令作为SafePoint，如方法调用、循环跳转和异常跳转等。
抢先式中断和主动式中断
如何在GC发生时，检查所有线程都跑到最近的安全点停顿下来呢?
-
抢先式中断:(目前没有虚拟机采用了)首先中断所有线程。如果还有线程不在安全点，就恢复线程，让线程跑到安全点。
-
主动式中断:设置一个中断标志，各个线程运行到Safe Point的时候主动轮询这个标志，如果中断标志为真，则将自己进行中断挂起。
安全区域
Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint 。但是，程序“不执行”的时候呢?
例如线程处于Sleep状态或Blocked状态，这时候线程无法响应JVM的中断请求，“走” 到安全点去中断挂起，JVM也不太可能等待线程被唤醒。对于这种情况，就需要安全区域(Safe Region)来解决。
-
安全区域是指在一段代码片段中，对象的引用关系不会发生变化，在这个区域中的任何位置开始GC都是安全的。我们也可以把Safe Region 看做是被扩展了的Safepoint。
-
当线程运行到Safe Region的代码时，首先标识已经进入了Safe Region,如果这段时间内发生GC，JVM会忽略标识为Safe Region状态的线程;
-
当线程即将离开Safe Region时，会检查JVM是否已经完成GC，如果完成了，则继续运行，否则线程必须等待直到收到可以安全离开SafeRegion的信号为止;
引用
在JDK 1.2版之后，Java对引用的概念进行了扩充，将引用分为强引用 (Strong Reference)、软引用(Soft Reference) 、弱引用(Weak Reference) 和虚引用(Phantom Reference) 4种，这4种引用强度依次逐渐减弱。
除强引用外，其他3种引用均可以在java.lang.ref包中找到它们的身影。如下图，显示了这3种引用类型对应的类，开发人员可以在应用程序中直接使用它们。
Reference子类中只有终结器引用是包内可见的，其他3种引用类型均为public,可以在应用程序中直接使用
-
强引用(StrongReference)：最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“0bject obj=new object()"这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。 -
软引用(SoftReference):在系统将要发生内存溢出之前，将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。 -
弱引用(WeakReference):被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。 -
虚引用(PhantomReference):一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设置虛引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
强引用-不回收
- 强引用可以直接访问目标对象。
- 强引用所指向的对象在任何时候都不会被系统回收，虚拟机宁愿拋出OOM异常，也不会回收强引用所指向对象。
- 强引用可能导致内存泄漏。
最常见的引用类型是强引用(普通系统99%以上都是强引用)，也就是我们最常见的普通对象引用，也是默认的引用类型。
当在Java语言中使用new操作符创建一个新的对象 并将其赋值给一个变量的时候，这个变量就成为指向该对象的一个强引用。
强引用的对象是可触及的，垃圾收集器就永远不会回收掉被引用的对象。 对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应(强)引用赋值为null,就是可以当做垃圾被收集了，当然具体回收时机还是要看垃圾收集策略。
相对的，软引用、 弱引用和虚引用的对象是软可触及、弱可触及和虛可触及的，在一定条件下，都是可以被回收的。所以，强引用是造成Java内存泄漏的主要原因之一。
/**
* 强引用的测试
*/
public class StrongReferenceTest {
public static void main(String[] args) {
StringBuffer str = new StringBuffer ("Hello");
StringBuffer str1 = str;
str = null;
System.gc();
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(str1);
}
}
输出结果为：
str1保存了对象引用，并不会回收。
软引用-内存不足即回收
-
软引用是用来描述一些还有用，但非必需的对象。
-
只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。
-
软引用通常用来实现内存敏感的缓存。比如:高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存。
-
垃圾回收器在某个时刻决定回收软可达的对象的时候，会清理软引用，并可选地把引用存放到一个引用队列(Reference Queue)
-
类似弱引用，只不过Java虚拟机会尽量让软引用的存活时间长一些，迫不得已才清理。
/**
* -Xms10m -Xmx10m -XX:+PrintGCDetails
* 软引用的测试：内存不足即回收
*
*/
public class SoftReferenceTest {
public static class User {
public User(int id, String name) {
this.id = id;
this.name = name;
}
public int id;
public String name;
@Override
public String toString() {
return "[id=" + id + ", name=" + name + "] ";
}
}
public static void main(String[] args) {
//创建对象，建立软引用
// SoftReference<User> userSoftRef = new SoftReference<User>(new User(1, "songhk"));
//上面的一行代码，等价于如下的三行代码
User u1 = new User(1,"songhk");
SoftReference<User> userSoftRef = new SoftReference<User>(u1);
u1 = null;//取消强引用
//从软引用中重新获得强引用对象
System.out.println(userSoftRef.get());
System.gc();
System.out.println("After GC:");
// //垃圾回收之后获得软引用中的对象
System.out.println(userSoftRef.get());//由于堆空间内存足够，所有不会回收软引用的可达对象。
//
try {
//让系统认为内存资源紧张、不够
byte[] b = new byte[1024 * 1024 * 7];
//计算刚好放下b对象的空间
//byte[] b = new byte[1024 * 7168 - 562 * 1024];
} catch (Throwable e) {
e.printStackTrace();
} finally {
//再次从软引用中获取数据
System.out.println(userSoftRef.get());//在报OOM之前，垃圾回收器会回收软引用的可达对象。
}
}
}
运行参数：-Xms10m -Xmx10m -XX:+PrintGCDetails
内存不足即回收
匿名内部类：
SoftReference<User> userSoftRef = new SoftReference<User>(new User(1, "songhk"));
等价于
User u1 = new User(1,"songhk");
SoftReference<User> userSoftRef = new SoftReference<User>(u1);
u1 = null;//取消强引用
弱引用-发现即回收
-
弱引用也是用来描述那些非必需对象，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。
-
在系统GC时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。
-
由于垃圾回收器的线程通常优先级很低，因此，并不一定能很快地发现持有弱引用的对象。在这种情况下，弱引用对象可以存在较长的时间。
-
弱引用和软引用一样，在构造弱引用时，也可以指定一个引用队列，当弱引用对象被回收时，就会加入指定的引用队列，通过这个队列可以跟踪对象的回收情况。
-
软引用、弱引用都非常适合来保存那些可有可无的缓存数据。 如果这么做，当系统内存不足时，这些缓存数据会被回收，不会导致内存溢出。而当内存资源充足时，这些缓存数据又可以存在相当长的时间，从而起到加速系统的作用。
弱引用对象与软引用对象的最大不同就在于，当GC在进行回收时，需要通过算法检查是否回收软引用对象，而对于弱引用对象，GC总是进行回收。弱引用对象更容易、更快被GC回收。
/**
* 弱引用的测试
*
*/
public class WeakReferenceTest {
public static class User {
public User(int id, String name) {
this.id = id;
this.name = name;
}
public int id;
public String name;
@Override
public String toString() {
return "[id=" + id + ", name=" + name + "] ";
}
}
public static void main(String[] args) {
//构造了弱引用
WeakReference<User> userWeakRef = new WeakReference<User>(new User(1, "songhk"));
//从弱引用中重新获取对象
System.out.println(userWeakRef.get());
System.gc();
// 不管当前内存空间足够与否，都会回收它的内存
System.out.println("After GC:");
//重新尝试从弱引用中获取对象
System.out.println(userWeakRef.get());
}
}
运行结果：
不管当前内存空间足够与否，一旦GC都会回收它的内存
WeakHashMap
WeakHashMap实现了Map接口，基于hash-table实现，在这种Map中，key的类型是WeakReference。如果对应的key被回收，则这个key指向的对象会被从Map容器中移除。
public class WeekHashTest {
public static void main(String[] args) {
String a = new String("a");
String b = new String("b");
Map map = new HashMap();
map.put(a, "aaa");
map.put(b, "bbb");
Map weakmap = new WeakHashMap();
weakmap.put(a, "aaa");
weakmap.put(b, "bbb");
map.remove(a);
//map.remove(b);
a = null;
b = null;
System.gc();
Iterator i = map.entrySet().iterator();
while (i.hasNext()) {
Map.Entry en = (Map.Entry) i.next();
System.out.println("map:" + en.getKey() + ":" + en.getValue());
}
Iterator j = weakmap.entrySet().iterator();
while (j.hasNext()) {
Map.Entry en = (Map.Entry) j.next();
System.out.println("weakmap:" + en.getKey() + ":" + en.getValue());
}
}
}
对于b对象虽然指向了null，但HashMap中还有指向b的指针。
WeakHashMap应用场景
- tomcat两级缓存
package org.apache.tomcat.util.collections;
import java.util.Map;
import java.util.WeakHashMap;
import java.util.concurrent.ConcurrentHashMap;
public final class ConcurrentCache<K,V> {
private final int size;
private final Map<K,V> eden;
private final Map<K,V> longterm;
public ConcurrentCache(int size) {
this.size = size;
this.eden = new ConcurrentHashMap<>(size);
this.longterm = new WeakHashMap<>(size);
}
public V get(K k) {
V v = this.eden.get(k);
if (v == null) {
synchronized (longterm) {
v = this.longterm.get(k);
}
if (v != null) {
this.eden.put(k, v);
}
}
return v;
}
public void put(K k, V v) {
if (this.eden.size() >= size) {
synchronized (longterm) {
this.longterm.putAll(this.eden);
}
this.eden.clear();
}
this.eden.put(k, v);
}
}
-
在put方法里，在插入一个k-v时，先检查eden缓存的容量是不是超了。没有超就直接放入eden缓存，如果超了则锁定longterm将eden中所有的k-v都放入longterm。再将eden清空并插入k-v。
-
在get方法中，也是优先从eden中找对应的v，如果没有则进入longterm缓存中查找，找到后就加入eden缓存并返回。
经过这样的设计，相对常用的对象都能在eden缓存中找到，不常用（有可能被销毁的对象）的则进入longterm缓存。而longterm的key的实际对象没有其他引用指向它时，gc就会自动回收heap中该弱引用指向的实际对象，弱引用进入引用队列。longterm调用expungeStaleEntries()方法，遍历引用队列中的弱引用，并清除对应的Entry，不会造成内存空间的浪费。
- 实现类似本地、堆内缓存的存储机制，缓存的失效依赖于GC收集器的行为
虚引用-对象回收跟踪
-
也称为“幽灵引用”或者“幻影引用”，是所有引用类型中最弱的一个。一个对象是否有虚引用的存在，完全不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。
-
它不能单独使用，也无法通过虚引用来获取被引用的对象。当试图通过虚引用的get()方法取得对象时，总是null。
-
为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收过程。 比如:能在这个对象被收集器回收时收到一个系统通知。
-
虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。
-
由于虚引用可以跟踪对象的回收时间，因此，也可以将一些资源释放操作放置在虚引用中执行和记录。
/**
* 虚引用的测试
*/
public class PhantomReferenceTest {
public static PhantomReferenceTest obj;//当前类对象的声明
static ReferenceQueue<PhantomReferenceTest> phantomQueue = null;//引用队列
public static class CheckRefQueue extends Thread {
@Override
public void run() {
while (true) {
if (phantomQueue != null) {
PhantomReference<PhantomReferenceTest> objt = null;
try {
objt = (PhantomReference<PhantomReferenceTest>) phantomQueue.remove();
} catch (InterruptedException e) {
e.printStackTrace();
}
if (objt != null) {
System.out.println("追踪垃圾回收过程：PhantomReferenceTest实例被GC了");
}
}
}
}
}
@Override
protected void finalize() throws Throwable { //finalize()方法只能被调用一次！
super.finalize();
System.out.println("调用当前类的finalize()方法");
//只能复活对象一次
obj = this;
}
public static void main(String[] args) {
Thread t = new CheckRefQueue();
t.setDaemon(true);//设置为守护线程：当程序中没有非守护线程时，守护线程也就执行结束。
t.start();
phantomQueue = new ReferenceQueue<PhantomReferenceTest>();
obj = new PhantomReferenceTest();
//构造了 PhantomReferenceTest 对象的虚引用，并指定了引用队列
PhantomReference<PhantomReferenceTest> phantomRef = new PhantomReference<PhantomReferenceTest>(obj, phantomQueue);
try {
//不可获取虚引用中的对象
System.out.println(phantomRef.get());
//将强引用去除
obj = null;
//第一次进行GC,由于对象可复活，GC无法回收该对象
System.gc();
Thread.sleep(1000);
if (obj == null) {
System.out.println("obj 是 null");
} else {
System.out.println("obj 可用");
}
System.out.println("第 2 次 gc");
obj = null;
System.gc(); //一旦将obj对象回收，就会将此虚引用存放到引用队列中。
Thread.sleep(1000);
if (obj == null) {
System.out.println("obj 是 null");
} else {
System.out.println("obj 可用");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
运行结果：
注意：finalize()方法在对象GC时，只能执行一次， 里面的obj = this;所以只能复活对象一次。第二次GC已经不执行finalize()方法了。
终结器引用
-
终结器引用(Final reference)它用以实现对象的finalize()方法，也可以称为终结器引用。无需手动编码，其内部配合引用队列使用。
-
在GC时，终结器引用入队。由Finalizer线程通过终结器引用找到被引用对象并调用它的finalize()方法
-
构造函数为私有，无法自己构建这类对象
-
第二次GC时才能回收被引用对象。因为只有在FinalizerThread执行完了对象的finalize方法的情况下才有可能被下次gc回收，而有可能期间已经经历过多次gc了，但是一直还没执行f对象的finalize方法
深入理解JVM系列
- 1.深入理解JVM（一）一一 简介和体系结构
- 2.深入理解JVM（二）一一 类加载器子系统
- 3.深入理解JVM（三）一一 运行时数据区（虚拟机栈）
- 4.深入理解JVM（四）一一 运行时数据区（程序计数器+本地方法栈）
- 5.深入理解JVM（五）一一 运行时数据区（堆）
- 6.深入理解JVM（六）一一 运行时数据区（方法区）
- 7.深入理解JVM（七）一一 执行引擎（解释器和JIT编译器）
- 8.深入理解JVM（八）一一 字符串常量池
- 9.深入理解JVM（九）一一 对象实例化和内存布局
- 10.深入理解JVM（十）一一 字节码层面剖析程序执行过程
- 11.深入理解JVM（十一）一一 垃圾回收相关概念
- 12.深入理解JVM（十二）一一 垃圾回收相关算法
- 13.深入理解JVM（十三）一一 详解垃圾回收器
- 14.深入理解JVM（十四）一一 对象分布图
- 15.深入理解JVM（十五）一一 class文件结构
- 16.深入理解JVM（十六）一一 字节码指令集
- 17.深入理解JVM（十七）一一 类的生命周期详解
- 18.深入理解JVM（十八）一一 再谈类的加载器
- 19.深入理解JVM（十九）一一 JVM监控及诊断工具(命令行）
- 20.深入理解JVM（二十）一一 JVM监控及诊断工具(GUI)
- 21.深入理解JVM（二十一）一一 JVM运行时参数(收藏篇)
- 22.深入理解JVM（二十二）一一 分析GC日志
- 23.深入理解JVM（二十三）一一 OOM场景及解决方案
