Java程序静态全局变量与内存泄漏的关系与分析＜一＞

1. 所需工具说明

要做这样的测试与分析我们需要以下这些工具：

1. 集成开发工具（我用的是STS）
2. jconsole.exe（用来观察堆内存的变化，路径是JDK安装路径bin下，我的是C:\Program Files\Zulu\zulu-8\bin），用法链接
3. Tomcat（我的是Spring Boot内置有Tomcat），要模拟Tomcat前后端服务

2. 任务

静态全局变量与内存泄漏的关系与分析。
重点考试要考：静态全局变量的生命周期与服务器一致。
按定义格式分两种静态全局变量类型：<1>. private static List<byte[]> byteList = new ArrayList<>();，这是直接声明和new创建；
<2>. private static List<byte[]> byteList;，这是先声明，用的时候再new创建。

3. 测试和分析第一种类型(直接声明和new创建)

1. 代码
   后端服务代码

package oom;

import java.util.ArrayList;
import java.util.List;

public class OutOfMemery {

    private static List<byte[]> byteList = new ArrayList<>();
    
    public static void clear() {
        if (!byteList.isEmpty()) {
            System.out.println("开始清除byteList数据");
            byteList.clear();
        }        
    }
    
    public static String initial() {
                
        int count = 0;
        while (count < 1000) {
            byteList.add(new byte[4096 * 10]);
            count++;
        }
        
        System.out.println("byteList's HashCode=" + byteList.hashCode() + ", size=" + byteList.size());
        
        return "byteList's HashCode=" + byteList.hashCode() + ", size=" + byteList.size();
    }
    
}

    @RequestMapping("/oom")
    public String oom_test() {
        String value = OutOfMemery.initial();
        return value;
    }

2. 分析
   测试的类叫OutOfMemery，有一个静态全局变量byteList，里面装的是byte[]；initial()方法就是往这个byteList添加1000个byte[4096 * 10]，返回的是byteList的hash code和size。controller就是前端发出oom请求就会调用OutOfMemery.initial()。

3. 测试
   Tomcat服务开启，我们先使用Jconsole查看开启的进程GC次数和内存使用量（如何使用请看上面链接），old, eden survivor依次如下图：

我的oom请求url是http://localhost:1010/sprintboot/oom。我们在浏览器输入这个url得到的结果如下图：

再回头看内存使用量，old, eden survivor依次如下图：



明显的看到3个内存都有增加。PS Scavenge（Young GC）次数是2。

执行第二oom请求看看静态全局变量byteList的变化，注意了这里是重点考试要考，前端结果如下图：

可以看到静态全局变量byteList的Hash code和之前不一样了，而且size是2000，即第一次请求时有1000，第二次请求又加了1000得到2000。说明了如果使用静态全局变量像List，Map，这些变量的值会在高并发下累加起来。
我们在连接点击10次看看结果：

size累积到12000。
那么与内存泄漏有什么关系呢？
上面有说到静态全局变量的生命周期与服务器一致，即这个全局变量一直引用List里面的byte[]对象地址，导致所占用的内存在执行GC(包括Full GC)时无法得到回收。那我们来简单验证一下，我们的byteList目前的size是12000，我们在JConsole点击执行GC看看内存是否会回收，点击前后依次如下图：
执行GC前：

执行GC后：

分析：
可以看到执行GC后，首先要看的就是GC次数，PS MarkSweep（Full GC）和PSScavenge（Young GC）都加了1；其次看PS Old Gen的堆内存使用量反而增加了，原因看两张图片右下角的堆3个柱的两，执行GC前后面的两个柱（依次是Eden，Survivor）都是有占用的，执行后这两个柱是没有占用了，那之前的占用当然是到了Old Gen了，所以解释了执行GC后Old Gen的堆内存使用量反而增加了。结论就是执行GC也无法回收全局变量byteList所占用的内存。

既然有这么个问题，那有什么方法避免呢？

1. 不使用静态全局变量；
2. 必定要使用静态全局变量的话，在return结果给前端之前要清除其数据（清除数据即是释放变量里内容byte[]的引用，这样执行GC时就能回收byte[]占用的内存了）。

好，那我们看看清除数据后再return结果给前端会有什么样的变化。
先看代码的变化：clear()方法之前就有只是没有调用，所以变化的在controller：

多了调用OutOfMemery.clear();

    @RequestMapping("/oom")
    public String oom_test() {
        String value = OutOfMemery.initial();
        OutOfMemery.clear();
        return value;
    }

开启Tomcat服务看看，多次请求会有什么不一样。

无论执行多少请求byteList的size都是1000，因为return结果之前就清除了byteList里面的数据。
说明一下其实byteList在return之前就清空了，但是我们的输出是size=1000，因为没有重新获取。
为了避免误会我们可以修改一下代码，如下：
在OutOfMemery类新增getter方法

public static List<byte[]> getByteList() {
        return byteList;
    }

Controller

  @RequestMapping("/oom")
    public String oom_test() {
        String value = OutOfMemery.initial();
        OutOfMemery.clear();
        String valueAfterRemove = "; 清除数据后，byteList's HashCode=" + OutOfMemery.getByteList().hashCode() + ", size=" + OutOfMemery.getByteList().size();
        return value + valueAfterRemove;
    }

无论我们浏览器刷新多少次oom请求，得到的结果如下图：

其实跟上面是一样啦，return结果之前就清除了byteList里面的数据。

好了，我们再用JConsole看看内存的占用：
执行GC前：

可以看到右下角的堆，最左边(Old)几乎是没有占用；中间(Eden)有一点占用；最右边(Survivor)有大量的占用。
执行GC前的次数：PS MarkSweep（Full GC）是1和PSScavenge（Young GC）是8。
我们手动执行GC看看结果：
执行GC后：

执行GC后，看到右下角的堆，最左边(Old)几乎是没有占用；中间(Eden)几乎是没有占用；最右边(Survivor)几乎是没有占用。
执行GC后的次数：PS MarkSweep（Full GC）是2和PSScavenge（Young GC）是9。

分析：
为什么会这样呢？因为我们后端程序在return前端请求结果之前都会清除静态全局变量byteList里面的内容即是释放变量里内容byte[]的引用，这样执行GC时就能回收byte[]占用的内存了。

经过这样的试验我们也可以发现一点：GC什么时候执行是有自己的规则的，但是我们可以手动的去执行GC(代码层面好像是通过System.gc()，我是没试过)。我简单说一下GC自己的执行规则：当执行new对象操作时，发现没有内存可以装下新的对象就会执行GC（什么对象放什么区域可以自行百度）。

4. 测试和分析第二种类型(先声明，用时再new创建)

这个另起一篇文章（Java程序静态全局变量与内存泄漏的关系与分析<二>）说明。