java VM(2）之对象已死？？？

最新推荐文章于 2022-07-15 00:25:23 发布

bubbleTg

最新推荐文章于 2022-07-15 00:25:23 发布

阅读量173

点赞数

分类专栏： java VM

本文链接：https://blog.csdn.net/qq_36570464/article/details/89068979

版权

java VM 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

从标题可以看见，此片文章讲的是对象是否已经死了？？主要用到以下算法：

引用计数算法

简单的讲:就是给对象添加一个计数器，当有一个地方引用它时，计数器值加一，引用失效时，计数器减一，当计数器为零时则表示对象不能再被使用。

但是在主流的Java虚拟机中没有选用计数算法来管理内存，主要的原因是它很难解决对象之间相互引用的问题。

如:

public class ReferenceCountingGC {
	
	public Object instance = null;
	private static final int _1MB = 1024 * 1024;
	private byte[] bigSize = new byte[2* _1MB];
	
	public static void testGC() {
		ReferenceCountingGC objA = new ReferenceCountingGC();
		ReferenceCountingGC objB = new ReferenceCountingGC();
		
		objA.instance = objB;
		objB.instance = objA;
		
		objA = null;
		objB = null;
		
		System.gc();
		
	}

}

因为两个对象相互引用着对方，导致计数都不为0，于是无法通知GC收集回收它们。

可达性分析算法

通过一系列的称为“GC Roots” 的对象作为起始点，从这些字节点向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots 没有任何引用链相连接时，则证明此对象是不可用的。
在这里插入图片描述
在Java语言中，可作为GC Roots 的对象包括下面几种：

虚拟机栈（栈帧中的本地变量表）中引用的对象。
方法区中类静态属性引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI（Native方法）应用的对象。

引用

无论是通过计数算法判断对象引用数量，还是通过可达性分析算法判断对象的引用链是否可达，判断对象是否存活都与引用有关。

在jDK 1.2 以前，对于引用的定义是很传统：如果Reference 类型的数据中存储的数值代表的是另外一块内存的起始地址，就称为这块内存代表这一个引用。

显然这种定义过于狭隘，很纯粹，一个对象在这种定义下只有两种状态，引用或没有引用。对于描述一些“食之无味，弃之可惜”对象就显得无能为力。

在jdk1.2 后，Java对引用进行了扩充，将引用分为：强引用，软引用，弱引用，虚引用。这4中引用强度依次逐渐减弱。

强引用就是指在程序代码之中普遍存在的，类似 “Object obj = new Object()” 这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
软引用是用来描述一些还有用但非必须的对象。对于软引用关联的对象，在系统将要发生内存溢出异常之间，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在jDk 1.2 之后，提供了SoftReference类来实现软引用。
弱引用也是用来买哦书非必需对象的。但它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在jDk 1.2 之后，提供了WeakReference类来实现弱引用。
虚引用，也称为幽灵引用，或者幻影引用，他是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获取得到一个对象实例。作为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在jDk 1.2 之后，提供了PhantomReference类来实现虚引用。

生存还是死亡

在可达性分析算法中的对象，并非是“非死不可”的。有时候它们暂时处于缓刑阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

当对象在进行可行性分析没有与GC Roots 相连接的引用链，它将会被第一次标记并且进行一次筛选，筛选条件是此对对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况视为“没有必要执行”。
如果对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立的，低优先级的Finalizer线程去执行它，因为如果一个对象在finalize()方法中执行缓慢，或者发生了死循环，将有可能导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。
fainalice()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果要在finalize()中成功拯救自己，只要从新与引用链上任何一个对象建立关系即可。譬如把自己(this)赋值给某个类变量或者对象的成员变量，那在第二次标记是它将被移除出“即将回收”的集合。

public class FinalizeEscapeGC {

	public static FinalizeEscapeGC SAVE_HOOK = null;

	public void isAlive() {
		System.out.println("yes, i am stall alive:)");
	}

	@Override
	protected void finalize() throws Throwable {
		super.finalize();

		System.out.println("finalize mehtod eecuted!");
		FinalizeEscapeGC.SAVE_HOOK = this;
	}

	public static void main(String[] args) throws InterruptedException {
		SAVE_HOOK = new FinalizeEscapeGC();

		// 对象第一次成功拯救自己
		SAVE_HOOK = null;
		System.gc();

		// 因为finzalize 方法优先级低，暂停0.5秒等待它
		Thread.sleep(500);

		if (SAVE_HOOK != null) {
			SAVE_HOOK.isAlive();
		} else {
			System.out.println("no,id am dead:( ");
		}

		//与上面相同，但是这次自救却失败了
		SAVE_HOOK = null;
		System.gc();

		// 因为finzalize 方法优先级低，暂停0.5秒等待它
		Thread.sleep(500);

		if (SAVE_HOOK != null) {
			SAVE_HOOK.isAlive();
		} else {
			System.out.println("no,id am dead:( ");
		}

	}

}

运行结果:
在这里插入图片描述
可以发现执行第一次结果却是一次逃脱成功，一次失败，因为任何一个对象的finalize()方法都会只被系统自动调用一次，如果队形面临下一次回收，它的finalize()方法不会再次执行，因此第二段代码自救行动失败了。