JVM系列(三) JVM垃圾判断及强引用关系

最新推荐文章于 2024-08-25 22:19:38 发布

jzjie

最新推荐文章于 2024-08-25 22:19:38 发布

阅读量470

点赞数

分类专栏： JVM-Java调优文章标签： jvm java 算法 JVM调优 JVM对象引用关系

本文链接：https://blog.csdn.net/u010134642/article/details/129717082

版权

JVM-Java调优专栏收录该内容

6 篇文章 1 订阅

订阅专栏

文章介绍了如何判断Java中的对象是否可被回收，主要讨论了引用计数法和可达性分析法两种方法，以及这两种方法的优缺点。接着，详细阐述了JVM的强引用特性，并通过示例展示了强引用导致的对象无法回收及可能引发的内存溢出问题。此外，还提到了JVM的内存配置和垃圾回收器的类型。

摘要由CSDN通过智能技术生成

1.判断垃圾对象

如何判断该对象是垃圾，或者该对象要被回收？

引用计数法
- 在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就 +1
- 当引用失效时，计数器值就-1 ；任何时刻计数器为 0 的对象就是没人用的，那么就要被回收
- 优点是原理简单，效率高
- 问题是无法解决循环引用的问题A->B,B->A, 对于A,B两个对象，计数器全都是1，其实两个对象再无其他引用了，是要被回收的，但是计数器法就无法解决
可达性分析法
- 以GC Roots的根对象作为起始节点集
- 从根节点开始，根据引用关系向下搜索，搜索所走过的路径称为
- 如果GC Roots 和某个对象没有任何引用链，也就是该对象不可达，该对象就是没人用的，就要被回收

2.JVM的引用关系

设置JVM参数

设置最大内存 30M
默认 young:old 是 1:2
所以年轻到 10M, 老年代 20M
年轻代默认 eden/from/to 8:1:1
年轻代可用的应该在 8+1=9M左右
老年代应该在 20M左右

-verbose:gc -Xmx30M  -XX:+PrintGC -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

配置JVM参数

3 强引用

平时大多的新建的对象都是强引用，程序代码之中普遍存在的引用赋值，无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象

如果所有的GC ROOTS对象都没有与某个对象有强引用路径，那么这个对象就可以被垃圾回收的

Object obj=new Object()

3.1 强引用测试

我们来测试一下强引用

public class JvmTest {
    
    static class MyBigObj {
        // 创建5M大小的字节数组
        private byte[] bytes = new byte[1024*1024*5];
    }

    public static void main(String[] args) throws Exception {

        //测试强连接
        strongTest();

    }


    public  static void strongTest() throws Exception{
        //每次都创建 不同的对象, 强连接, 即使执行gc 也不会被回收, 再次创建OOM

        for (int i = 0; i < 6; i++) {
            MyBigObj big = new MyBigObj();
            System.out.println("========="+i);
        }
    }

}

3.2 启动程序

查看自己JVM使用的是哪种垃圾回收方式

java -XX:+PrintCommandLineFlags -version

查看结果

-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)

-XX:+UseParallelGC 使用并行收集器
并行收集器就是新生代（Parallel Scavenge），老年代（Ps MarkSweep）组合
打印的新生代 PSYoungGen
打印的老年代 ParOldGen

运行方法, 我们看下打印日志, 是不是使用的 UseParallelGC并行收集器

=========0
=========1
=========2
[GC (Allocation Failure) [PSYoungGen: 7062K->1008K(9216K)] 22422K->16916K(29696K), 0.0022281 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
=========3
[GC (Allocation Failure) [PSYoungGen: 6291K->1008K(9216K)] 22200K->16972K(29696K), 0.0018994 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
=========4
[GC (Allocation Failure) [PSYoungGen: 6290K->1008K(9216K)] 22254K->16988K(29696K), 0.0016448 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
=========5
Heap
 PSYoungGen      total 9216K, used 6453K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
  eden space 8192K, 66% used [0x00000007bf600000,0x00000007bfb51528,0x00000007bfe00000)
  from space 1024K, 98% used [0x00000007bfe00000,0x00000007bfefc198,0x00000007bff00000)
  to   space 1024K, 0% used [0x00000007bff00000,0x00000007bff00000,0x00000007c0000000)
 ParOldGen       total 20480K, used 15980K [0x00000007be200000, 0x00000007bf600000, 0x00000007bf600000)
  object space 20480K, 78% used [0x00000007be200000,0x00000007bf19b198,0x00000007bf600000)
 Metaspace       used 4698K, capacity 5068K, committed 5248K, reserved 1056768K
  class space    used 522K, capacity 564K, committed 640K, reserved 1048576K

3.3 gc日志分析

下面我们分析下日志

PSYoungGen total 9216K 年轻代的确是 9M, 可用的占年轻代 90%
eden space 8192K eden区是 8M 满足 8:1:1 eden/from/to
from space 1024K from区 1M
to space 1024K to区 1M
ParOldGen total 20480K 老年代的确是 20M, 与年轻代比例是 1:2 young:old
Metaspace used 4728K, capacity 5068K 元空间可用 5M 用了4M

然后分析下YoungGC和FullGC

第一次 5M的obj 被成功放到9M的 young区, 剩余
第二次 5M的obj 被成功放到9M的 eden区没问题
第三次 5M的obj 再被放入 eden区时候,不够了, 使用了 7092, 发生YoungGC, gc后剩余 1008k
第四次可以继续放, 一次类推, 放一次,YoungGC后清理出来部分空间
继续放,继续清理直至结束

3.4 强引用存在回收不了OOM

把逻辑如下修改, 用list来存储big对象, 这样就不会被回收掉

public  static void strongTest() throws Exception{
    //每次都创建 不同的对象, 强连接, 即使执行gc 也不会被回收, 再次创建OOM
    List<MyBigObj> list = new ArrayList<>();
    for (int i = 0; i < 6; i++) {
        MyBigObj big = new MyBigObj();
        list.add(big);
        System.out.println("========="+i);
    }
}

多次执行后看下结果

Full GC [PSYoungGen: 6292K->6053K(9216K)] eden区无法回收
Full GC [ParOldGen: 15945K->15625K(20480K)] 22238K->21679K(29696K) 老年代也无法回收
导致 java.lang.OutOfMemoryError: Java heap space 内存溢出

=========0
=========1
=========2
[GC (Allocation Failure) [PSYoungGen: 7062K->1008K(9216K)] 22422K->16922K(29696K), 0.0023415 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
=========3
[GC (Allocation Failure) --[PSYoungGen: 6292K->6292K(9216K)] 22206K->22238K(29696K), 0.0021786 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 6292K->6053K(9216K)] [ParOldGen: 15945K->15625K(20480K)] 22238K->21679K(29696K), [Metaspace: 4692K->4692K(1056768K)], 0.0060295 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) --[PSYoungGen: 6053K->6053K(9216K)] 21679K->21703K(29696K), 0.0019607 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
[Full GC (Allocation Failure) [PSYoungGen: 6053K->5966K(9216K)] [ParOldGen: 15649K->15638K(20480K)] 21703K->21604K(29696K), [Metaspace: 4692K->4692K(1056768K)], 0.0058404 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 
java.lang.OutOfMemoryError: Java heap space

这就是强引用, 如果内存一直存在无法回收, 就会出现OOM