JAVA POI 频繁GC 解决问题 java gc allocation failure

文章目录

• GC垃圾回收

• 以下内容参考至 [Android工程师进阶](https://kaiwu.lagou.com/course/courseInfo.htm?courseId=67#/detail/pc?id=1856)
• 什么是垃圾
• 什么时候触发垃圾回收
• 哪些对象是垃圾？

• 1. 引用计数算法
• 2.可达性分析算法

• 验证GC Root

• 1. 验证栈帧中的局部变量表中引用的对象可以作为GC Root
• 2. 验证方法区中的静态变量引用的对象可以作为GC Root
• 3. 验证活跃线程作为GC Root
• 4. 验证成员变量是否可以作为 GCRoot

• 总结

• 2.回收算法

• 1.标记-清理算法
• 2.复制算法
• 3. 标记整理算法
• 4. 分代收集算法

• 对象分代

• 1.对象优先在Eden分配
• 2.大对象直接进入老年代
• 3. 长期存活的对象将进入老年代
• 4.动态对象年龄判定

GC垃圾回收

以下内容参考至 Android工程师进阶

什么是垃圾

所谓的垃圾就是一些在内存中没有引用的对象。

什么时候触发垃圾回收

1. Allocation Failure: 在堆内存中为新对象分配内存时，如果此时剩余内存空间不足，导致为对象分配内存失败，此时系统会触发一次GC; Low Memory Killer
2. System.gc : 系统提供的Api，在应用层，程序员可以通过调用Api，主动触发GC。
3. 自动回收 不同的虚拟机有不同的实现。

哪些对象是垃圾？

主要的算法有两种：

1. 引用计数算法

给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1，当引用失效时，计数器值就减1，任何时刻计数器为0的对象就是不可用的。

• 优点：该算法实现简单，判定效率也很高
• 缺点：假如有两个对象都无用，但是互相之间持有对方的引用，导致它们的计数器的值都不为0，然后引用计数算法就无法通知GC收集器去回收它们。

// 使用引用计数方式，obj1与obj2不能被Gc回收，导致了内存泄露
 public class GcDemo {
 
    public static void main(String[] args) {
        //分为6个步骤
        GcObject obj1 = new GcObject(); //Step 1 obj1的引用计数为1
        GcObject obj2 = new GcObject(); //Step 2 obj2的引用计数为1
 
        obj1.instance = obj2; //Step 3 obj2的引用计数为2
        obj2.instance = obj1; //Step 4 obj1的引用计数为2
 
        obj1 = null; //Step 5 obj1的引用计数减1，当前为1
        obj2 = null; //Step 6 obj2的引用计数减1，当前为1
    }
}
 
class GcObject{
    public Object instance = null;
}

2.可达性分析算法

通过一些列的称为GCRoots的对象作为起始点，从这些节点开始向下搜索，搜索所走的路径称为引用链，当一个对象到GCRoots根节点没有任何引用链相连时，就证明对象是不可用的。可以作为GCRoots的对象有四种

• 1.虚拟机栈(栈帧中的局部变量表)中引用的对象。
• 2.方法区中类静态属性引用的对象。
• 3.方法区中常量引用的对象
• 4.本地方法栈中JNI引用的对象。

验证GC Root

在验证之前，我们先看一个执行Java命令时的参数

-Xms 初始分配JVM运行时内存大小，如果不指定默认是物理内存的1/64

1. 验证栈帧中的局部变量表中引用的对象可以作为GC Root

import org.omg.SendingContext.RunTime;

/**
 * 验证虚拟机栈中的引用变量可以作为GC Root根节点
 */
class GCRootLocalVariable{

    private int _10MB = 10 * 1024 * 1024;
    private byte[] memory = new byte[8 *_10MB];

    public static void main(String[] args) {
        System.out.println("start");
        printMemory();
        method();
        System.gc();
        System.out.println("second GC finish");
        printMemory();
    }

    public static void method() {
        GCRootLocalVariable gv = new GCRootLocalVariable();
        System.gc();
        System.out.println("first GC finish");
        printMemory();
    }

    private static void printMemory() {
        System.out.println(String.format("free memory is %d M", Runtime.getRuntime().freeMemory() / 1024 / 1024));
        System.out.println(String.format("totle memory is %d M", Runtime.getRuntime().totalMemory() / 1024 / 1024));
    }

}

打印结果如下：

start
free memory is 242 M
totle memory is 245 M
first GC finish
free memory is 163 M
totle memory is 245 M
second GC finish
free memory is 243 M
totle memory is 245 M

分析：

1. 当 method 方法入栈，gv 作为局部变量，引用了 new 出来的对象(80M), 并且它作为 GC Root, 在第一次GC 后并不会被回收，因为 method 方法还没有出栈
2. 当 method 方法出栈，gv 也会随着方法消失，不再引用 new 出来的对象(80M), 在第二次GC后会被回收。

2. 验证方法区中的静态变量引用的对象可以作为GC Root

class GCRootStaticVariable{

    private static int _10M = 10 * 1024 * 1024;
    private byte[] memory;
    private static GCRootStaticVariable staticVariable;

    public GCRootStaticVariable(int memorySize) {
        memory = new byte[memorySize];
    }

    public static void main(String[] args) {
        System.out.println("start");
        printMemory();
        GCRootStaticVariable gsv = new GCRootStaticVariable(4 * _10M);
        gsv.staticVariable = new GCRootStaticVariable(8 * _10M);
        System.out.println("using -----------");
        printMemory();
        gsv = null;
        System.gc();
        System.out.println("gc finish");
        printMemory();
    }

    private static void printMemory() {
        System.out.println(String.format("free memory is %d M", Runtime.getRuntime().freeMemory() / 1024 / 1024));
        System.out.println(String.format("totle memory is %d M", Runtime.getRuntime().totalMemory() / 1024 / 1024));
    }
}

打印结果如下：

start
free memory is 244 M
totle memory is 245 M
using -----------
free memory is 122 M
totle memory is 245 M
gc finish
free memory is 163 M
totle memory is 245 M

分析：

1. gc 之前，我们创建了 40M 的 gsv 对象，并初始化了 80M 的gsv 中静态变量 staticVariable，此时我们一共使用了 120M 的内存空间
2. 接着我们将 40M 的gsv对象置为 null，执行 gc 时，只有 40M 的 gsv 对象所占的内存被回收了，而 gsv 的静态变量作为GC Root 却没有被回收掉。

3. 验证活跃线程作为GC Root

class GCRootThread {

    private int _10MB = 10 * 1024 * 1024;
    private byte[] memory = new byte[8 * _10MB];

    public static void main(String[] args) {
        System.out.println("start-----");
        printMemory();
        AsyncTask task = new AsyncTask(new GCRootThread());
        Thread t1 = new Thread(task, "t1");
        t1.start();
        System.gc();
        System.out.println("main method finished, finish GC");
        printMemory();
        try {
            t1.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } // wait t1 finish
        task = null;
        System.gc();
        System.out.println("t1 finished, finish GC");
        printMemory();
    }

    private static void printMemory() {
        System.out.println(String.format("free memory is %d M", Runtime.getRuntime().freeMemory() / 1024 / 1024));
        System.out.println(String.format("totle memory is %d M", Runtime.getRuntime().totalMemory() / 1024 / 1024));
    }

    private static class AsyncTask implements Runnable{
        private GCRootThread root;

        public AsyncTask(GCRootThread root) {
            this.root = root;
        }

        @Override
        public void run() {
            try {
                Thread.sleep(500);
            } catch (Exception e) {
            }
        }
    }
}

打印结果如下：

start-----
free memory is 244 M
totle memory is 245 M
main method finished, finish GC
free memory is 163 M
totle memory is 245 M
t1 finished, finish GC
free memory is 243 M
totle memory is 245 M

分析：

1. main 方法入栈，创建一个引用 80M 内存的 task(内部休息了 500ms), 将该任务交由线程 t1 执行。执行 gc 后，我们发现， 有80M的内存没有被回收，说明 task 作为 GC Root，它所占的 80M 内存没有被回收。
2. 当线程 t1 完成任务结束时，我们将 task = null，再次执行 gc ，发现 task 引用的 80M 内存已经被回收。

4. 验证成员变量是否可以作为 GCRoot

其实这一点可以根据生命周期就可以确定：成员变量的生命周期与所在类对象生命周期一致，所以只要对象可以被回收，那么成员变量一定可以被回收，所以 成员变量不可以作为 GCRoot

class GCRootClassVariable {
    private static int _10M = 10 * 1024 * 1024;
    private byte[] memory;
    private GCRootClassVariable mVariable;

    public GCRootClassVariable(int memorySize) {
        memory = new byte[memorySize];
    }
    public static void main(String[] args) {
        System.out.println("start------");
        printMemory();
        GCRootClassVariable gcv = new GCRootClassVariable(4 *_10M);
        gcv.mVariable = new GCRootClassVariable(8 * _10M);
        System.out.println("using------");
        printMemory();
        gcv = null;
        System.gc();
        System.out.println("finished gc------");
        printMemory();
    }
    
    private static void printMemory() {
        System.out.println(String.format("free memory is %d M", Runtime.getRuntime().freeMemory() / 1024 / 1024));
        System.out.println(String.format("totle memory is %d M", Runtime.getRuntime().totalMemory() / 1024 / 1024));
    }
}

打印结果如下：

start------
free memory is 244 M
totle memory is 245 M
using------
free memory is 122 M
totle memory is 245 M
finished gc------
free memory is 243 M
totle memory is 245M

总结

在虚拟机栈帧的局部变量中引用的对象，只要该GCRoot对象没有逃逸出栈的范围，它占用的内存会随着方法的执行结束而自动被GC回收。

即使在可达性分析算法中不可达的对象，也并非是真正的非死不可的，它是处于一个缓刑阶段，要真正判断一个对象死亡，至少要经历两次标记的过程，如果对象在进行可达性分析后没有发现与GCRoots相连接的引用链，那么它将会被第一次标记并且进行一次筛选，筛选的条件是此对象有没有必要执行finalize方法，当对象没有覆盖finalize方法或者finalize方法以及被虚拟机调用过，就认为没有必要执行。如果对象没有必要执行finalize方法，那这个对象就会被放置在F-Queue的队列中，并且稍后由一个虚拟机自动建立，低优先级的Finalizer线程去执行。finalize方法是对象逃脱死亡的最后一次机会，稍后GC会对F-Queue中的对象进行二次小规模的标记，只要对象在finalize中重新与引用链上的任何对象建立连接就行，在第二次标记的时候就会被移除队列，如果对象还没有逃脱那么就会真的被回收了。

2.回收算法

1.标记-清理算法

标记清除算法分为标记 MARK和清理 SWEEP两个阶段。首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它主要有两个缺点

• 效率问题，标记和清除两个过程的效率都不高, 由于 STOP THRE WORLD, 即 会中断进程内其他组件的执行。
• 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到连续内存而不得不提前触发另一次GC。

2.复制算法

为了解决效率问题，我们引入了一种复制算法，它将可用内存按照容量划分为大小相等的两块，每次只使用其中的一块，当这一块的内存用完了就将还存活的对象复制到另一块中，然后再把已经使用过的内存一次清理掉。这样使得每次只对整个半区内存回收，也就不用考虑标记清理带来的碎片问题。它的优点是实现简单，运行高效。但是缺点也很明显

• 内存代价太高，每次要花费一般的内存空间，当收集存活率比较高的对象时，就要进行较多次的复制，效率就会变得低下。

3. 标记整理算法

先根据GCRoot可达性分析将对象进行标记，然后将所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

优点：该方法即避免了内存碎片化，也不用减少可用内存，性价比较高

缺点：在整理的过程中，涉及到对象引用的移动，效率上还是有所欠缺的。

4. 分代收集算法

分代收集算法就是根据各个年代的特点采用最适当的算法来收集，在新生代中，每次回收都有大量的对象死去，只有少量的对象存活，所以选择用复制算法，只需要付出少量存活对象的空间就可以完成收集；如果新生代中的一些对象经过几次(由不同的虚拟机决定，一般是15次)GC后依然存活，则将这些对象跃迁到老年代中，在老年代中对象的存活率非常的高，没有额外空间对它进行分配，所以使用标记清理或者标记整理算法来完成回收。

对象分代

JVM 根据对象存活的周期不同，将堆内存分为： 新生代，老年代。注意 HotSpot 中分为 新生代，老年代，永久代。

新生代又划分了三个区：Eden, Survivor0(s0), Survivor1(s1), 这三部分按照 8 ：1 ：1 的分配策略划分新生代。

新创建对象主要分配在新生代的Eden区和其中一个Survivor区上，如果启动了本地线程分配缓冲将按线程优先在tlab上分配，少数情况下也有可能直接分配在老年代中，分配的规则并不是百分百固定。

1.对象优先在Eden分配

大多数情况下对象在新生代Eden中分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次GC。

2.大对象直接进入老年代

所谓大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组，让大对象直接在老年代分配，这样的目的是避免Eden和两个Survivor区之间发生大量的内存复制。

3. 长期存活的对象将进入老年代

虚拟机给每一个对象定义了一个年龄计数器，如果对象在Eden出生并经过了第一次GC仍然存活，就被Survivor容纳。进入Survivor空间中，并且对象年龄设为1，对象在Survivor中熬过一次GC年龄就增加为1岁，当它的年龄增加到一定程度时（默认为15岁）就会晋级为老年代，

4.动态对象年龄判定

虚拟机并不是永远要求对象的年龄必须达到那个标志才晋级老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到默认的年龄15再进入。