Introduction to the four reference states of jvm
- 零下一度Original
- 2017-06-28 10:00:051443browse
The four reference states of the JVM
In the article Java Virtual Machine 5: Detailed Explanation of Java Garbage Collection (GC) Mechanism, the JVM is briefly mentioned At that time, I was just learning briefly about the four citation states. I knew that there was such a concept, but I didn’t have a deep understanding of the four citation states. When I re-read the virtual machine part in the past two days, I wrote many examples to study several JVM references in detail. My understanding of JVM references has deepened a lot, so I wrote an article to summarize and share it.
First of all, let’s start with the four reference states of the JVM. This part is excerpted from the book "In-depth Understanding of the Java Virtual Machine: JVM Advanced Features and Best Practices" by Mr. Zhou Zhiming.
Before JDK1.2, the definition of reference in Java was very traditional: If the value stored in the reference type data represents the starting address of another piece of memory, it is called this A block of memory represents a reference . This definition is very pure, but too narrow. An object can only be referenced or not referenced in this way. It is powerless to describe some objects that are "tasteless to eat and a pity to throw away". We hope to describe such a type of object: When the memory space is still enough, it can be retained in the memory; if the memory space is still very tight after garbage collection, these objects can be discarded (Pay attention to the comparison with the blue words in the previous paragraph). The caching functions of many systems conform to this reference scenario.
After JDK1.2, Java has expanded the concept of references and divided references into strong references (Strong Reference), soft references (Soft Reference), weak references (Weak Reference), and phantom references (Phantom). Reference) 4 types, the reference strength of these 4 weakens at once.
#Strong references refer to references that are common in program code, such as "Object obj = new Object()", as long as the strong reference still exists, the garbage collector will never reclaim the referenced object
Soft reference is used to describe some useful but not necessary Objects, for objects associated with soft references,Before a memory overflow exception occurs in the system, these objects will be included in the recycling scope for the second recycling. If there is not enough memory for this recycling, a memory overflow exception will be thrown. After JDK1.2, the SoftReference class is provided to implement soft references
Weak references are also used to describe non-essential objects, but their strength is stronger than soft references Weaker , objects associated with weak references can only survive until the next garbage collection occurs. When the garbage collector works, objects associated with only weak references will be recycled regardless of whether the current memory is sufficient. After JDK1.2, the WeakReference class is provided to implement weak references
Virtual references also become ghost references or phantom references, which are the weakest reference relationships. Whether an object has a virtual reference has no impact on its lifetime, and it is impossible to obtain an object instance through a virtual reference. The only purpose of setting a virtual reference association for an object is to receive a system notification when the object is recycled by the collector. After JDK1.2, the PhantomReference class is provided to implement virtual references
Written before the code starts
Before studying several reference states through code, first define some parameters. These parameters are used in all subsequent code examples.
The first is the JVM parameters, here I use:
-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseParNewGC -verbose:gc -XX:+PrintGCDetails
这意味着：
堆大小固定为20M
新生代大小为10M，SurvivorRatio设置为8，则Eden区大小=8M，每个Survivor区大小=1M，每次有9M的新生代内存空间可用来new对象
新生代使用使用ParNew收集器，Server模式下默认是Parallel收集器，不过这个收集器的GC日志我看着没有ParNew收集器的GC日志舒服，因此就改成ParNew收集器了
当发生GC的时候打印GC的简单信息，当程序运行结束打印GC详情
其次，再定义一个常量类"_1MB"：
_1MB = 1024 * 1024
代码示例使用byte数组，每个byte为1个字节，因此定义一个"_1MB"的常量就可以方便得到1M、2M、3M...的内存空间了。
强引用的研究
关于强引用的研究，研究的重点在于验证"当一个对象到GC Roots没有任何引用链相连，则证明此对象是不可用的（要被回收）"这句话的正确性。虚拟机参数上面列了，首先写一个空方法：
1 /** 2 * @author 五月的仓颉 3 */ 4 @Test 5 public void testStrongReference0() { 6 7 }程序运行结果为：
1 Heap 2 par new generation total 9216K, used 3699K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000) 3 eden space 8192K, 45% used [0x00000000f9a00000, 0x00000000f9d9cdc0, 0x00000000fa200000) 4 from space 1024K, 0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000) 5 to space 1024K, 0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000) 6 tenured generation total 10240K, used 0K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000) 7 the space 10240K, 0% used [0x00000000fa400000, 0x00000000fa400000, 0x00000000fa400200, 0x00000000fae00000) 8 compacting perm gen total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000) 9 the space 21248K, 20% used [0x00000000fae00000, 0x00000000fb243d88, 0x00000000fb243e00, 0x00000000fc2c0000)10 No shared spaces configured.
这意味着新生代中本身就有3699K的内存空间。很好理解，因为虚拟机启动的时候就会加载一部分数据到内存中，这部分数据的大小为3699K。
下一步我们放一个4M的byte数组进去（4M是因为找一个相对大点的数字，结果会比较明显），4M=4096K，加上原来的3966K等于8062K。对这8062K内存空间触发一次GC：
1 /** 2 * @author 五月的仓颉 3 */ 4 @Test 5 public void testStrongReference0() { 6 System.out.println("**********强引用测试（放一个4M的数组，触发GC）**********"); 7 8 byte[] bytes = new byte[4 * _1MB]; 9 10 // 手动触发GC11 System.gc();12 }运行结果为：
1 **********强引用测试（放一个4M的数组，触发GC）********** 2 [Full GC[Tenured: 0K->5161K(10240K), 0.0085630 secs] 7958K->5161K(19456K), [Perm : 4354K->4354K(21248K)], 0.0086002 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 3 Heap 4 par new generation total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000) 5 eden space 8192K, 3% used [0x00000000f9a00000, 0x00000000f9a47300, 0x00000000fa200000) 6 from space 1024K, 0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000) 7 to space 1024K, 0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000) 8 tenured generation total 10240K, used 5161K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000) 9 the space 10240K, 50% used [0x00000000fa400000, 0x00000000fa90a548, 0x00000000fa90a600, 0x00000000fae00000)10 compacting perm gen total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)11 the space 21248K, 20% used [0x00000000fae00000, 0x00000000fb243dc0, 0x00000000fb243e00, 0x00000000fc2c0000)12 No shared spaces configured.
总结一下这次GC的结果（由于这篇不是研究内存分配的文章，因此我们只关注结果，至于过程到底为什么就不细究了）：
新生代中只留下了284K大小的对象
7958K大小的对象被移到了老年代中
7958K大小的对象被进行了一次回收，剩余5161K大小的对象
总结起来就是4M的byte数组并没有被回收（因为总共有5161K的对象，虚拟机启动的时候也才加载了3699K不到5161K，那4M的byte数组肯定是在的），原因是有bytes引用指向4M的byte数组。既然如此，我们把bytes置空看看结果如何：
1 /** 2 * @author 五月的仓颉 3 */ 4 @Test 5 public void testStrongReference0() { 6 System.out.println("**********强引用测试（放一个4M的数组，bytes置空，触发GC）**********"); 7 8 byte[] bytes = new byte[4 * _1MB]; 9 10 bytes = null;11 12 // 手动触发GC13 System.gc();14 }运行结果为：
1 **********强引用测试（放一个4M的数组，bytes置空，触发GC）********** 2 [Full GC[Tenured: 0K->1064K(10240K), 0.0096213 secs] 7958K->1064K(19456K), [Perm : 4354K->4354K(21248K)], 0.0096644 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 3 Heap 4 par new generation total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000) 5 eden space 8192K, 3% used [0x00000000f9a00000, 0x00000000f9a47300, 0x00000000fa200000) 6 from space 1024K, 0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000) 7 to space 1024K, 0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000) 8 tenured generation total 10240K, used 1064K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000) 9 the space 10240K, 10% used [0x00000000fa400000, 0x00000000fa50a368, 0x00000000fa50a400, 0x00000000fae00000)10 compacting perm gen total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)11 the space 21248K, 20% used [0x00000000fae00000, 0x00000000fb243dc0, 0x00000000fb243e00, 0x00000000fc2c0000)12 No shared spaces configured.
从GC详情我们可以看到：
老年代只使用了1064K大小的内存
新生代只使用了284K大小的内存
很显然4M的byte数组被回收。
由这个例子我们回顾可以作为GC Roots的对象：
虚拟机栈（栈帧中的本地变量表）中引用的对象，比如在方法中定义"Object obj = new Object();"
方法区中类静态属性引用的对象，比如在类中定义"private static Object lock = new Object();"，将Object对象作为一个锁，所有类共享
方法区中常量引用的对象，比如在接口中定义"public static final char c = 'a';"，字符'a'是一个常量
本地方法栈中JNI（即一般说的Native方法）引用的对象，这个不好找例子
这次的回收正是因为第一条。本身有bytes（在虚拟机栈中）指向4M的byte数组，由于将bytes置空。因此4M的byte数组此时没有任何一个可以作为GC Roots对象的引用指向它，即4M的byte数组被虚拟机标记为可回收的垃圾，在GC时被回收。
稍微扩展一下，这里上面代码的做法是手动将bytes置空，其实方法调用结束也是一样的，栈帧消失，栈帧消失意味着bytes消失，那么4M的byte数组同样没有任何一个可以作为GC Roots对象的引用指向它，因此方法调用结束之后，4M的byte数组同样会被虚拟机标记为可回收的垃圾，在GC时被回收。
软引用的研究
软引用之前说过了，JDK提供了SoftReference类共开发者使用，那我们就利用SoftReference研究一下软引用，测试代码为：
1 /** 2 * @author 五月的仓颉 3 */ 4 @Test 5 public void testSoftReference0() { 6 System.out.println("**********软引用测试**********"); 7 8 byte[] bytes = new byte[4 * _1MB]; 9 SoftReference<byte[]> sr = new SoftReference<byte[]>(bytes);10 System.out.println("GC前：" + sr.get());11 12 bytes = null;13 14 System.gc();15 System.out.println("GC后：" + sr.get());16 }同样的new一个4M的byte数组，通过SoftReference构造方法放到SoftReference中。
这段代码最值得注意的是第9行"bytes=null"这一句，如果不将bytes置空，那么4M的byte数组还与强引用关联着，内存不够虚拟机将抛出异常而不会尝试回收它；将bytes置空则不一样，4M的byte数组失去了强引用，但是它又在SoftReference中，这意味着这个4M的byte数组目前仅仅与软引用关联。
运行一下程序，结果为：
1 **********软引用测试********** 2 GC前：[B@76404629 3 [Full GC[Tenured: 0K->5161K(10240K), 0.0094088 secs] 7953K->5161K(19456K), [Perm : 4354K->4354K(21248K)], 0.0094428 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 4 GC后：[B@76404629 5 Heap 6 par new generation total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000) 7 eden space 8192K, 3% used [0x00000000f9a00000, 0x00000000f9a47330, 0x00000000fa200000) 8 from space 1024K, 0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000) 9 to space 1024K, 0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)10 tenured generation total 10240K, used 5161K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)11 the space 10240K, 50% used [0x00000000fa400000, 0x00000000fa90a778, 0x00000000fa90a800, 0x00000000fae00000)12 compacting perm gen total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)13 the space 21248K, 20% used [0x00000000fae00000, 0x00000000fb243f10, 0x00000000fb244000, 0x00000000fc2c0000)14 No shared spaces configured.
看到GC前后，bytes都是"[B@76404629"，很显然4M的byte数组并没有被回收。从内存空间来看，老年代中使用了5161K，和之前强引用测试是一样的，证明了这一点。
那我们怎么能看到弱引用的回收呢？既然弱引用是发生在内存不够之前，那只需要不断实例化byte数组，然后将之与软引用关联即可，代码为：
1 /** 2 * @author 五月的仓颉 3 */ 4 @Test 5 public void testSoftReference1() { 6 System.out.println("**********软引用测试**********"); 7 8 SoftReference<byte[]> sr0 = new SoftReference<byte[]>(new byte[4 * _1MB]); 9 SoftReference<byte[]> sr1 = new SoftReference<byte[]>(new byte[4 * _1MB]);10 SoftReference<byte[]> sr2 = new SoftReference<byte[]>(new byte[4 * _1MB]);11 SoftReference<byte[]> sr3 = new SoftReference<byte[]>(new byte[4 * _1MB]);12 SoftReference<byte[]> sr4 = new SoftReference<byte[]>(new byte[4 * _1MB]);13 SoftReference<byte[]> sr5 = new SoftReference<byte[]>(new byte[4 * _1MB]);14 15 System.out.println(sr0.get());16 System.out.println(sr1.get());17 System.out.println(sr2.get());18 System.out.println(sr3.get());19 System.out.println(sr4.get());20 System.out.println(sr5.get());21 }运行结果为：
1 **********软引用测试********** 2 [GC[ParNew: 7958K->1024K(9216K), 0.0041103 secs] 7958K->5187K(19456K), 0.0041577 secs] [Times: user=0.05 sys=0.00, real=0.00 secs] 3 [GC[ParNew: 5203K->331K(9216K), 0.0036532 secs] 9366K->9481K(19456K), 0.0036694 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 4 [GC[ParNew: 4427K->4427K(9216K), 0.0000249 secs][Tenured: 9149K->9149K(10240K), 0.0054937 secs] 13577K->13246K(19456K), [Perm : 4353K->4353K(21248K)], 0.0055600 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 5 [Full GC[Tenured: 9149K->783K(10240K), 0.0071252 secs] 13246K->783K(19456K), [Perm : 4353K->4352K(21248K)], 0.0071560 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 6 [GC[ParNew: 4096K->41K(9216K), 0.0010362 secs] 4879K->4921K(19456K), 0.0010745 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 7 [GC[ParNew: 4137K->10K(9216K), 0.0009216 secs] 9017K->8986K(19456K), 0.0009366 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 8 null 9 null10 null11 [B@4783165b12 [B@6f30d50a13 [B@6ef2bc8d14 Heap15 par new generation total 9216K, used 4307K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)16 eden space 8192K, 52% used [0x00000000f9a00000, 0x00000000f9e32560, 0x00000000fa200000)17 from space 1024K, 1% used [0x00000000fa200000, 0x00000000fa202978, 0x00000000fa300000)18 to space 1024K, 0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)19 tenured generation total 10240K, used 8975K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)20 the space 10240K, 87% used [0x00000000fa400000, 0x00000000facc3f40, 0x00000000facc4000, 0x00000000fae00000)21 compacting perm gen total 21248K, used 4366K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)22 the space 21248K, 20% used [0x00000000fae00000, 0x00000000fb2439e0, 0x00000000fb243a00, 0x00000000fc2c0000)23 No shared spaces configured.
从第8行~第13行的结果来看，前三个4M的byte数组被回收了，后三个4M的byte数组还在，这就证明了"被软引用关联的对象会在内存不够时被回收"。
这段代码我们可以做一个对比思考：
如果4M的byte数组没有被软引用关联而是被强引用关联，且不释放强引用，那么new到第4个4M的byte数组时就会报错，因为老年代总共只有10M，前两个4M的byte数组可以进入老年代，第3个4M的byte数组new出来的时候放入新生代，但是当第四个4M的byte数组new出来的时候，第3个4M的byte数组却没法进入老年代（因为3个4M=12M，大于老年代的10M），虚拟机抛出OutOfMemoryError
如果4M的byte数组被软引用关联且强引用已经释放，那么可以无限写"SoftReference
所以，很多时候对一些非必需的对象，我们可以将直接将其与软引用关联，这样内存不够时会先回收软引用关联的对象而不会抛出OutOfMemoryError，毕竟抛出OutOfMemoryError意味着整个应用将停止运行。
弱引用的研究
JDK给我们提供的了WeakReference用以将一个对象关联到弱引用，弱引用的测试比较简单，代码为：
1 /** 2 * @author 五月的仓颉 3 */ 4 @Test 5 public void testWeakReference() { 6 System.out.println("**********弱引用测试**********"); 7 8 WeakReference<byte[]> wr = new WeakReference<byte[]>(new byte[4 * _1MB]); 9 System.out.println("GC前：" + wr.get());10 11 System.gc();12 System.out.println("GC后：" + wr.get());13 }我这里不定义一个强引用直接关联4M的byte数组（避免忘了将对象与强引用的关联取消），这也是使用SoftReference、WeakReference时我个人比较推荐的做法。程序运行的结果为：
1 **********弱引用测试********** 2 GC前：[B@21dd63a8 3 [Full GC[Tenured: 0K->1065K(10240K), 0.0080353 secs] 7958K->1065K(19456K), [Perm : 4353K->4353K(21248K)], 0.0080894 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 4 GC后：null 5 Heap 6 par new generation total 9216K, used 284K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000) 7 eden space 8192K, 3% used [0x00000000f9a00000, 0x00000000f9a47318, 0x00000000fa200000) 8 from space 1024K, 0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000) 9 to space 1024K, 0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)10 tenured generation total 10240K, used 1065K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)11 the space 10240K, 10% used [0x00000000fa400000, 0x00000000fa50a6e8, 0x00000000fa50a800, 0x00000000fae00000)12 compacting perm gen total 21248K, used 4367K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)13 the space 21248K, 20% used [0x00000000fae00000, 0x00000000fb243dc8, 0x00000000fb243e00, 0x00000000fc2c0000)14 No shared spaces configured.
看到GC后bytes为null了，且新生代、老年代中也没见到有4M以上的大对象，从两个角度都证明了，GC之后4M的byte数组被回收了。
Reference与ReferenceQueue
前面用代码验证了强引用、软应用、弱引用三种引用状态，虚引用就不演示了，记住虚引用是用于跟踪对象的回收状态就够了。
下面再讲一个知识点ReferenceQueue，ReferenceQueue的作用分点讲解下：
SoftReference、WeakReference、PhantomReference，在构造的时候可以通过构造函数传入一个ReferenceQueue，但是只有PhantomReference，ReferenceQueue是必须的
以SoftReference为例，一个类型为SoftReference的sr关联了一个4M的byte数组，那么当内存不够的时候，回收此4M的byte数组，sr.get()为null，表示sr不再关联此4M的byte数组
当sr对应的4M的byte数组被回收之后，sr本身被加入ReferenceQueue中，表示此软引用关联的对象被回收
ReferenceQueue本身是一个Queue，可通过poll()方法不断拿到队列的头元素，如果是null表示没有被回收的软引用关联的对象，如果不是null表示有软引用关联的对象被回收
SoftReference是这样的，WeakReference与PhantomReference同理
讲完理论，用代码验证一下，还是使用软引用，不过为了显示更清楚把GC显示相关参数（-verbose:gc -XX:+PrintGCDetails）去掉，代码为：
1 /** 2 * @author 五月的仓颉 3 */ 4 @Test 5 public void testReferenceQueue() { 6 System.out.println("**********引用队列测试**********\n"); 7 8 ReferenceQueue<byte[]> referenceQueue = new ReferenceQueue<byte[]>(); 9 10 SoftReference<byte[]> sr0 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);11 SoftReference<byte[]> sr1 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);12 SoftReference<byte[]> sr2 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);13 SoftReference<byte[]> sr3 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);14 SoftReference<byte[]> sr4 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);15 SoftReference<byte[]> sr5 = new SoftReference<byte[]>(new byte[4 * _1MB], referenceQueue);16 17 System.out.println("**********软引用关联的对象展示**********");18 System.out.println(sr0 + "---" + sr0.get());19 System.out.println(sr1 + "---" + sr1.get());20 System.out.println(sr2 + "---" + sr2.get());21 System.out.println(sr3 + "---" + sr3.get());22 System.out.println(sr4 + "---" + sr4.get());23 System.out.println(sr5 + "---" + sr5.get());24 25 System.out.println("**********引用队列中的SoftReference展示**********");26 System.out.println(referenceQueue.poll());27 System.out.println(referenceQueue.poll());28 System.out.println(referenceQueue.poll());29 System.out.println(referenceQueue.poll());30 System.out.println(referenceQueue.poll());31 System.out.println(referenceQueue.poll());32 }运行结果为：
1 **********引用队列测试********** 2 3 **********软引用关联的对象展示********** 4 java.lang.ref.SoftReference@50ed0a5---null 5 java.lang.ref.SoftReference@fa4033b---null 6 java.lang.ref.SoftReference@58d01e82---null 7 java.lang.ref.SoftReference@4783165b---[B@6f30d50a 8 java.lang.ref.SoftReference@6ef2bc8d---[B@23905e3 9 java.lang.ref.SoftReference@6db17b38---[B@1f10d1cb10 **********引用队列中的SoftReference展示**********11 java.lang.ref.SoftReference@50ed0a512 java.lang.ref.SoftReference@fa4033b13 java.lang.ref.SoftReference@58d01e8214 null15 null16 null
Seeing that due to insufficient memory, the first three soft references were recycled, and the memory addresses of the three recycled soft references all match, which proves the above statement.
The above is the detailed content of Introduction to the four reference states of jvm. For more information, please follow other related articles on the PHP Chinese website!