由一个Bug来看Java内存模型和垃圾回收

背景

前两天,项目中发现一个Bug。我们使用的RocketMQ,在服务启动后会创建MQ的消费者实例。测试过程中,发现服务启动一段时间后,与RocketMQ的连接就会断掉,从而找不到订阅关系,监听不到数据。

一、Bug的产生

经过回溯代码,发现订阅的逻辑是这样的。将ConsumerStarter类注册到Spring,并通过PostConstruct注解触发初始化方法,完成MQ消费者的创建和订阅。

ConsumerStarter

上面代码中的Subscriber类是同事写的一个工具类,封装了一些连接RocketMQ的配置信息,使用的时候都调用这里。这里面也不复杂,就是连接RocketMQ,完成创建和订阅。

Subscriber

1、finalize

上面的代码看起来平平无奇,但实际上他重写了finalize方法。并且在里面执行了consumer.shutdown(),将RocketMQ断开了,这里是诱因。

finalizeObject中的方法。在GC(垃圾回收器)决定回收一个不被其他对象引用的对象时调用。子类覆写 finalize 方法来处置系统资源或是负责清除操作。

回到项目中,他这样的写法就是在Subscriber类被回收的时候,断开RokcketMQ的连接,因而产生了Bug。最简单的方式就是把shutdown这句代码删掉,但这似乎不是好的解决方案。

2、为何被回收?

在Java的内存模型中,有一个虚拟机栈,它是线程私有的。

虚拟机栈是线程私有的,每创建一个线程,虚拟机就会为这个线程创建一个虚拟机栈,虚拟机栈表示Java方法执行的内存模型,每调用一个方法就会为每个方法生成一个栈帧(Stack Frame),用来存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法被调用和完成的过程,都对应一个栈帧从虚拟机栈上入栈和出栈的过程。虚拟机栈的生命周期和线程是相同的

在上面的ConsumerStarter.init()方法中,Subscriber subscriber = new Subscriber()被定义成了局部变量,在方法执行完毕后,subscriber变量就没有了引用,然后GC掉。

很快,我就有了新的想法,将Subscriber定义成ConsumerStarter类中的成员变量也是可以的,因为ConsumerStarter是注册到了Spring中。在Bean的生命周期内,不会被回收。

如上代码,把subscriber变量作用域提到类级别,事实证明这样也是没问题的。

还有个更优的方案是,将Subscriber类直接注册到Spring中,由PostConstruct注解触发初始化完成对MQ的创建和订阅;由PreDestroy注解完成资源的释放。这样,资源的创建和销毁跟Bean的生命周期绑定,也是没问题的。

到目前为止,这个Bug的原因和解决方案都有了。但还有个问题,笔者当时也没想明白。

二、线程与垃圾回收

为了确定哪些对象是垃圾,在Java中使用了可达性分析的方法。

它通过通过一系列的GC roots对象作为起点搜索。从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的。

在上面的例子中,虽然Subscriber类已经不被引用,要被回收,但是它里面还有RocketMQConsumer实例还在以线程的方式运行,这种情况下,Subscriber类也会被回收掉吗?

那么,就变成了这样一个问题: 如果一个对象A已不被引用,符合GC条件;但是它里面还有一个线程对象a1在活跃,那么此时这个对象A还会被回收吗?

为了验证这个问题,笔者做了一个测试。

1、测试一

在这里,还是以Subscriber类为例,给它启动一个线程,看是否还会被GC。简化代码如下:

测试流程是:启动服务 > Subscriber类被创建 > 线程执行10次循环 > 手动调用GC

得出结果如下:

15:01:07.110  [main]  INFO  - Subscriber已启动...
15:01:07.112  [Thread-9]  INFO  - 执行线程次数:0
15:01:07.357  [main]  INFO  - Initializing ExecutorService 'applicationTaskExecutor'
15:01:07.568  [main]  INFO  - Starting ProtocolHandler ["http-nio-8081"]
15:01:07.609  [main]  INFO  - Tomcat started on port(s): 8081 (http) with context path ''
15:01:07.614  [main]  INFO  - Started BootMybatisApplication in 3.654 seconds
15:01:08.114  [Thread-9]  INFO  - 执行线程次数:1
15:01:09.114  [Thread-9]  INFO  - 执行线程次数:2
15:01:09.302  [http-nio-8081-exec-2]  INFO  - 调用GC。。。
15:01:10.122  [Thread-9]  INFO  - 执行线程次数:3
15:01:11.123  [Thread-9]  INFO  - 执行线程次数:4
15:01:12.123  [Thread-9]  INFO  - 执行线程次数:5
15:01:12.319  [http-nio-8081-exec-3]  INFO  - 调用GC。。。
15:01:13.123  [Thread-9]  INFO  - 执行线程次数:6
15:01:14.124  [Thread-9]  INFO  - 执行线程次数:7
15:01:15.125  [Thread-9]  INFO  - 执行线程次数:8
15:01:15.319  [http-nio-8081-exec-5]  INFO  - 调用GC。。。
15:01:16.125  [Thread-9]  INFO  - 执行线程次数:9
15:01:17.775  [http-nio-8081-exec-7]  INFO  - 调用GC。。。
15:01:17.847  [Finalizer]  INFO  - finalize-------------Subscriber对象被销毁
复制代码

从结果上看,如果Subscriber类如果有活跃的线程在运行,它是不会被回收的;等线程运行完之后,再次调用GC,才会被回收掉。不过,先不要急着下结论,我们再测试一下别的情况。

2、测试二

这次,我们先创建一个线程类Thread1

它的run方法,我们跟上面保持一致。然后在Subscriber对象中通过线程调用它。

流程和测试1一样,这次的结果输出如下:

14:59:20.193  [main]  INFO  - Subscriber已启动...
14:59:20.194  [Thread-9]  INFO  - 执行次数:0
14:59:20.359  [Finalizer]  INFO  - finalize-------------Subscriber对象被销毁
14:59:20.444  [main]  INFO  - Initializing ExecutorService 'applicationTaskExecutor'
14:59:20.699  [main]  INFO  - Starting ProtocolHandler ["http-nio-8081"]
14:59:20.745  [main]  INFO  - Tomcat started on port(s): 8081 (http) with context path ''
14:59:20.751  [main]  INFO  - Started BootMybatisApplication in 3.453 seconds
14:59:21.197  [Thread-9]  INFO  - 执行次数:1
14:59:22.198  [Thread-9]  INFO  - 执行次数:2
14:59:23.198  [Thread-9]  INFO  - 执行次数:3
14:59:24.198  [Thread-9]  INFO  - 执行次数:4
14:59:25.198  [Thread-9]  INFO  - 执行次数:5
14:59:26.198  [Thread-9]  INFO  - 执行次数:6
14:59:27.198  [Thread-9]  INFO  - 执行次数:7
14:59:28.199  [Thread-9]  INFO  - 执行次数:8
14:59:29.199  [Thread-9]  INFO  - 执行次数:9
复制代码

从结果上看,Subscriber创建之后就因为ConsumerStarter.init()方法执行完毕,而被销毁了,丝毫没有受线程的影响。

咦,这就有意思了。从逻辑上看,两个测试都是通过new Thread()开启了新的线程,为啥结果却不一样呢?

当即就在微信联系了芋道源码大神,大神果然老道,他一眼指出:你这个应该是内部类的问题。

3、匿名内部类

我们把目光回到测试1的代码中。

如果在方法中,这样创建一个线程,实际上创建了一个匿名内部类。但是,它有什么特殊之处吗?竟然会阻止对象会正常回收。

我们知道在内部类编译成功后,它会产生一个class文件,该class文件与外部类并不是同一class文件。在上面的代码中,编译后就产生一个class文件叫做:Subscriber$1.class

通过反编译软件,我们可以得到这个class文件的内容如下:

看到这里,就已经很明确了。这个内部类虽然与外部类不是同一个class文件,但是它保留了对外部类的引用,就是这个Subscriber this$0

只要内部类的方法执行不完,就会还保留外部类的引用实例,所以外部类就不会被GC回收。

所以,再回到一开始的问题:

如果一个对象A已不被引用,符合GC条件;但是它里面还有一个线程对象a1在活跃,那么此时这个对象A还会被回收吗?

答案也是肯定的,除非线程对象a1还在引用A对象。

三、匿名内部类与垃圾回收

第二部分中,我们看的是匿名内部类中开启线程和垃圾回收的关系,我们再看看与线程无关的情况。

在意识到是因为匿名内部类导致垃圾回收的问题时,在网上找到一篇文章。说的也是匿名内部类垃圾回收的问题,原文链接: 匿名内部类相关的gc

里面的代码笔者也测试过了,确实也如原文作者所说:

从结果推测,匿名内部类会关联对象,内部类对象不回收,导致主对象无法回收;

但实际上,这并不是匿名内部类的问题,或者说不完全是它的问题,而是static修饰符的问题。

1、测试一

使用匿名内部类我们必须要继承一个父类或者实现一个接口,所以我们随便创建一个接口。

public interface TestInterface {
    void out();
}
复制代码

然后在Subscriber外部类中使用它。

然后启动服务,输出结果如下:

16:37:53.626  [main]  INFO  - Root WebApplicationContext: initialization completed in 1867 ms
16:37:53.710  [main]  INFO  - Subscriber已启动...
16:37:53.711  [main]  INFO  - 匿名内部类测试...
16:37:53.866  [Finalizer]  INFO  - finalize-------------Subscriber对象被销毁
16:37:53.950  [main]  INFO  - Initializing ExecutorService 'applicationTaskExecutor'
16:37:54.180  [main]  INFO  - Starting ProtocolHandler ["http-nio-8081"]
16:37:54.224  [main]  INFO  - Tomcat started on port(s): 8081 (http) with context path ''
复制代码

从结果来看,Subscriber对象被创建,使用完之后,不需要手动调用GC,就被销毁了。

如果将interface1变量定义成静态的呢?static TestInterface interface1;

输出结果如下:

16:43:20.331  [main]  INFO  - Root WebApplicationContext: initialization completed in 1826 ms
16:43:20.404  [main]  INFO  - Subscriber已启动...
16:43:20.405  [main]  INFO  - 匿名内部类测试...
16:43:20.673  [main]  INFO  - Initializing ExecutorService 'applicationTaskExecutor'
16:43:20.955  [main]  INFO  - Starting ProtocolHandler ["http-nio-8081"]
16:43:21.002  [main]  INFO  - Tomcat started on port(s): 8081 (http) with context path ''
16:43:21.007  [main]  INFO  - Started BootMybatisApplication in 3.327 seconds
16:43:33.095  [http-nio-8081-exec-1]  INFO  - Initializing Servlet 'dispatcherServlet'
16:43:33.102  [http-nio-8081-exec-1]  INFO  - Completed initialization in 7 ms
16:43:33.140  [http-nio-8081-exec-1]  INFO  - 调用GC。。。
16:43:35.763  [http-nio-8081-exec-2]  INFO  - 调用GC。。。
复制代码

如果把interface1定义成静态的,再怎么调用GCSubscriber都不会被回收掉。

怎么办呢?可以在interface1使用完之后,把它重新赋值成空。interface1=null;,这时候,Subscriber类又会像测试1里面那样,被正常回收掉。

不过,这又是为什么呢?Java的垃圾回收是依靠GC Roots开始向下搜索的,当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的;那么反之,就是可用的,不可回收的。

GC Roots包含以下对象:

  • 虚拟机栈中引用的对象
  • 方法区中类静态属性引用的对象
  • 方法区中常量引用的对象
  • 本地方法栈中JNI[即一般说的Native]引用的对象

也就是说,如果我们把匿名内部类interface1定义成静态的对象,它就会当作GC Root对象存在,此时,这个内部类里面又保持着外部类Subscriber的引用,所以迟迟不能被回收。

2、测试二

为什么说,这并不是匿名内部类的问题,或者说不完全是它的问题,而是static修饰符的问题,我们可以再做一个测试。

关于匿名内部类,我们先不管它是如何产生的,也不理会又是怎么用的,我们只记住它的特性之一:

它会保持外部类的引用。

所以,我们先摒弃什么劳什子内部类,就创建一个普通的类,让它保持调用类的引用。

然后在外部类Subscriber中,创建它的实例,并调用:

最后启动服务,输出结果如下:

17:30:02.331  [main]  INFO  - Root WebApplicationContext: initialization completed in 1726 ms
17:30:02.443  [main]  INFO  - Subscriber已启动...
[email protected]
17:30:02.447  [main]  INFO  - User对象输出信息....
[email protected]
17:30:02.605  [Finalizer]  INFO  - finalize-------------Subscriber对象被销毁
17:30:02.606  [Finalizer]  INFO  - finalize-------------User对象被销毁
17:30:02.676  [main]  INFO  - Initializing ExecutorService 'applicationTaskExecutor'
17:30:02.880  [main]  INFO  - Starting ProtocolHandler ["http-nio-8081"]
复制代码

这种情况下,都是会正常被回收的。

但如果这时候再把user对象定义成静态属性,不管怎么GC,还是不能回收。

由此看来,可以得出这样一个结论:

  • 匿名内部类并不会妨碍外部类的正常GC,而是不能将它定义成静态属性引用。
  • 静态匿名内部类,导致外部类不能正常回收的原因就是:它作为GC Root对象却保持着外部类的引用。

四、总结

本文通过一个小Bug,引发了内存模型和垃圾回收的问题。因为基础理论知识还不过硬,只能通过不同的测试,来解释整个事件的原因。

另外,虽然Java帮我们自动回收垃圾,但大家写代码的时候注意不要引发内存泄露哦。

猜你喜欢

转载自juejin.im/post/5ce78cb2518825332b59f6ee