class DemoApplicationTests {
Object instance = null;
private static final int _1MB = 1024 * 1024;
/**
* 这个成员属性的唯一意义就是占点内存,以便能在GC日志中看清楚是否被回收过
*/
private byte[] bigSize = new byte[2 * _1MB];
@Test
void test() {
ReferenceCountingGCTests objA = new ReferenceCountingGCTests();
ReferenceCountingGCTests objB = new ReferenceCountingGCTests();
objA.instance = objB;
objB.instance = objA;
objA = null;
objB = null;
//假设在这行发生GC,那么objA和objB是否能被回收?
System.gc();
}
}
[GC (System.gc()) [PSYoungGen: 21058K->1445K(134144K)] 29477K->9864K(184320K), 0.0016862 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System.gc()) [PSYoungGen: 1445K->0K(134144K)] [ParOldGen: 8418K->8479K(50176K)] 9864K->8479K(184320K), [Metaspace: 20833K->20833K(1069056K)], 0.0285684 secs] [Times: user=0.08 sys=0.00, real=0.03 secs]
Heap
PSYoungGen total 134144K, used 5372K [0x00000000d5b00000, 0x00000000ded80000, 0x0000000100000000)
eden space 127488K, 4% used [0x00000000d5b00000,0x00000000d603f128,0x00000000dd780000)
from space 6656K, 0% used [0x00000000de700000,0x00000000de700000,0x00000000ded80000)
to space 11264K, 0% used [0x00000000dd780000,0x00000000dd780000,0x00000000de280000)
ParOldGen total 50176K, used 8479K [0x0000000081000000, 0x0000000084100000, 0x00000000d5b00000)
object space 50176K, 16% used [0x0000000081000000,0x0000000081847f88,0x0000000084100000)
Metaspace used 21019K, capacity 22682K, committed 22784K, reserved 1069056K
class space used 2926K, capacity 3249K, committed 3328K, reserved 1048576K
从运行结果可以清楚的看出GC日志中包含“29477K->9864K”,意味着虚拟机没有因为这两个对象互相引用就不回收它们,这也说明虚拟机不是通过引用计数算法来判断对象是否存活的。
在执行上一段代码时,需要设置一下打印GC日志详情。我是使用的idea,如图配置即可。
再说下打印的GC日志说明如下:
CPU时间与墙钟时间:墙钟时间包括各种非运算符的等待耗时,例如等待磁盘I/O、等待线程阻塞,而CPU时间不包括这些耗时,但当系统有多个CPU或者多核的话,多线程操作会叠加这些CPU时间,所以看到sys时间超过real时间是完全正常的。
JVM的GC日志的主要参数包括如下几个:
根搜索算法(GC Roots Tracing)
Java是使用根搜索算法来判断对象是否存活的,基本思路是:通过一系列的名为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连(就是从GC Roots到这个对象不可达)时,则证明此对象是不可用的。如图:
对象object5、object6、object7虽然互有关联,但是他们到GC Roots是不可达的,so它们将会被判定为是可回收对象。在Java语言中,可作为GC Roots的对象包括下面几种:
1、虚拟机栈(栈帧中的本地变量表)中的引用对象。
2、方法区中的类静态属性引用对象。
3、方法区中的常量引用的对象。
4、本地方法栈中的JNI(即一般说的Native方法)的引用的对象。
引用
在JDK1.2之后,Java对引用的概念进行了扩充,将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)四种,这四种引用强度依次逐渐减弱。
强引用:指在程序代码中普遍存在,类似“Object obj = new Object()”这类引用,只要强引用还存在,垃圾收集器永远不会回收掉引用的对象。
软引用:用来描述一些还有用,但并非必须的对象。对于弱引用关联的对象,在系统将要发生内存溢出异常之前,将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存,才会抛出内存溢出异常,提供SoftReference类来实现引用类型。
弱引用:也是用来描述非必需对象的,但是它的强度比软引用更弱一些,被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时,无论当前内存是否足够,被弱引用关联的对象都会被回收掉。提供WeekReference类来实现引用类型。
虚引用:也称幽灵引用或者幻影引用,它是最弱的一种引用关系。一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例。唯一目的是希望这个对象被收集器回收时收到一个系统通知。提供PhantomReference类来实现引用类型。
回收方法区
方法区(HotSpot虚拟机中的永久代)进行垃圾回收,性价比会比较低,在堆中,尤其是在新生代中,常规应用进行一次垃圾回收一般可回收70%-95%的空间,而永久代的垃圾收集效率远低于此。
永久代垃圾收集主要两个部分:废弃常量和无用的类。
回收废弃常量:回收废弃常量和回收堆中的对象相似。以常量池中字面量的回收为例,假如一个字符串“abc”已经进入了常量池中,但是当前系统没有任何一个String对象是叫做“abc”的,换句话说是没有任何String对象引用常量池中的“abc”常量,没有其他地方引用了这个字面量,如果这时候发生内存回收,而且必要的话,这个“abc”常量就会被系统“请”出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
无用的类:判断是否无用的类,需满足三个条件:
1、该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例。
2、加载该类的ClassLoader已经被回收。
3、该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。
垃圾收集算法
下面介绍几种算法的思想及其发展过程。
标记 - 清除算法(Mark-Sweep)
最基础的算法是“标记 - 清除”算法,分为“标记”和“清除”两个阶段:先标记出所有需要回收的对象,然后在标记完成后统一回收掉所有被标记的对象。
不过有两缺点:
1、效率问题,标记和清除过程的效率都不高;
2、空间问题,标记清除之后会产生大量的不连续的内存碎片,空间碎片太多可能会导致,当程序在以后过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
标记 - 清除算法的执行过程如下:
复制算法(Copying)文章转载自:https://blog.csdn.net/m0_37827190/article/details/105904649
欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/) | 黑马程序员IT技术论坛 X3.2 |