垃圾收集器和内存分配策略之对象存活检测《深入理解Java虚拟机：JVM高级特性与最佳实践》笔记四

最新推荐文章于 2024-01-19 17:59:43 发布

转载最新推荐文章于 2024-01-19 17:59:43 发布 · 574 阅读

Java 专栏收录该内容

107 篇文章

订阅专栏

本文深入探讨Java垃圾回收机制，包括应用计数、可达性分析算法等对象存活检测方法，以及强引用、软引用、弱引用和虚引用的概念与应用场景。详细解析垃圾回收器如何决定对象的生存还是死亡，以及方法区的回收策略。

参考资料：

《深入理解Java虚拟机：JVM高级特性与最佳实践》第三章
https://blog.youkuaiyun.com/xyh269/article/details/53106790
https://www.jianshu.com/p/147793693edc
https://blog.youkuaiyun.com/u013256816/article/details/50907595

垃圾收集器和内存分配策略

对象存活检测

根据java内存模型，在内存中程序计数器、虚拟机栈、本地方法栈跟线程的生命周期相同，这几个区域内存分配和回收具有确定性，所以不需要过多考虑回收的问题。但是java堆和方法栈对应的内存分配和回收都是动态的，垃圾回收器所关注的就是这部分内存。

对象存活检测

应用计数

算法思想：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值加1，当引用失效时，计数器值减1，任何时刻计数器为0的对象就是不可能再被使用的。
优点：实现简单，判断效率也很高
缺点：很难解决对象之间相互循环引用的问题

可达性分析算法

算法思想：通过一系列的“GC Roots”对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。
可作为 GC Roots 的对象
1.虚拟机栈中引用的对象
2.方法区中类静态属性引用的对象
3.方法区中常量引用的对象
4.本地方法栈中 JNI 引用的对象

再谈引用

序号	引用类型	取得目标对象方式	垃圾回收条件	是否可能内存泄漏
1	强引用	直接调用	不回收	可能
2	软引用	通过 get()方法	视内存情况回收	不可能
3	弱引用	通过 get()方法	永远回收	不可能
4	虚引用	无法取得	不回收	可能

几种引用级别由高到低分别为：强引用、软引用、弱引用和虚引用

强引用：

如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
示例：

Object object=new Object()；
String[] arr = new String[]{"a", "b", "c"};

软引用：

如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。
软引用主要应用于内存敏感的高速缓存，在android系统中经常使用到。一般情况下，Android应用会用到大量的默认图片，这些图片很多地方会用到。如果每次都去读取图片，由于读取文件需要硬件操作，速度较慢，会导致性能较低。所以我们考虑将图片缓存起来，需要的时候直接从内存中读取。但是，由于图片占用内存空间比较大，缓存很多图片需要很多的内存，就可能比较容易发生OutOfMemory异常。这时，我们可以考虑使用软引用技术来避免这个问题发生。SoftReference可以解决oom的问题，每一个对象通过软引用进行实例化，这个对象就以cache的形式保存起来，当再次调用这个对象时，那么直接通过软引用中的get（）方法，就可以得到对象中中的资源数据，这样就没必要再次进行读取了，直接从cache中就可以读取得到，当内存将要发生OOM的时候，GC会迅速把所有的软引用清除，防止oom发生。

// 示例1
SoftReference<String[]> softBean = new SoftReference<String[]>(new String[]{"a", "b", "c"});

// 示例2
ReferenceQueue<String[]> referenceQueue = new ReferenceQueue<String[]>();
SoftReference<String[]> softBean = new SoftReference<String[]>(new String[]{"a", "b", "c"}, referenceQueue);

// 示例3
public class BitMapManager {
    private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();

    //保存Bitmap的软引用到HashMap
    public void saveBitmapToCache(String path) {
        // 强引用的Bitmap对象
        Bitmap bitmap = BitmapFactory.decodeFile(path);
        // 软引用的Bitmap对象
        SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
        // 添加该对象到Map中使其缓存
        imageCache.put(path, softBitmap);
        // 使用完后手动将位图对象置null
        bitmap = null;
    }

    public Bitmap getBitmapByPath(String path) {

        // 从缓存中取软引用的Bitmap对象
        SoftReference<Bitmap> softBitmap = imageCache.get(path);
        // 判断是否存在软引用
        if (softBitmap == null) {
            return null;
        }
        // 取出Bitmap对象，如果由于内存不足Bitmap被回收，将取得空
        Bitmap bitmap = softBitmap.get();
        return bitmap;
    }
}

弱引用

用来描述非必须的对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发送之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。一旦一个弱引用对象被垃圾回收器回收，便会加入到一个注册引用队列中。
示例：

//示例1
WeakReference<String[]> weakBean = new WeakReference<String[]>(new String[]{"a", "b", "c"});
//示例2
ReferenceQueue<String[]> referenceQueue = new ReferenceQueue<String[]>();
WeakReference<String[]> softBean = new WeakReference<String[]>(new String[]{"a", "b", "c"}, referenceQueue);

虚引用（Phantom Reference)

虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个持有虚引用的对象，和没有引用几乎是一样的，随时都有可能被垃圾回收器回收。当试图通过虚引用的get()方法取得强引用时，总是会失败。
并且，虚引用必须和引用队列一起使用，虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。
示例：

ReferenceQueue<String[]> referenceQueue = new ReferenceQueue<String[]>();
PhantomReference<String[]> referent = new PhantomReference<String>(new String[]{"a", "b", "c"}, referenceQueue);

生存还是死亡

即使在可达性分析算法中不可达的对象，也不是“非死不可”的。

对象在被标记为不可达之后，如果对象覆盖了finalize()方法并且该对象还没有调用过finalize()，那么这个对象会被放入F-Queue队列中，并在稍后一个由虚拟机建立的、低优先级的Finalize线程中去执行对象的finalize()方法。稍后GC会对F-Queue的对象进行再一次的标记，如果对象的finalize方法中，将对象重新和GC Roots建立了关联，那么在第二次标记中就会被移除出“即将回收”的集合。

但是，finalize线程的优先级很低，GC并不保证会等待对象执行完finalize方法之后再去回收，因而想通过finalize方法区拯救对象的做法，并不靠谱。鉴于finalize()方法这种执行的不确定性，大家其实可以忘记finalize方法在Java中的存在了，无论什么时候，都不要使用finalize方法。

回收方法区

很多人认为方法区（或者HotSpot虚拟机中的永久代）是没有垃圾收集的，Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集，而且在方法区进行垃圾收集的“性价比”一般比较低：在堆中，尤其是在新生代中，常规应用进行一次垃圾收集一般可以回收70%~95%的空间，而永久代的垃圾收集效率远低于此。

永久代的垃圾收集主要回收两部分内容：废弃常量 和 无用的类。

废弃常量
回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说，就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常置池中的其他类（接口）、方法、字段的符号引用也与
无用的类
类需要同时满足下面3个条件才能算是“无用的类”：
1.该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
2.加载该类的ClassLoader已经被回收。
3.该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。