一次由于八股文引起的内存泄漏

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介: 本文记录两次报错系统监控现象以及作者针对性的排查过程和分析,最终解决了问题的全过程。

文章开头,先分享一张大部分Java开发同学都记在心里的一张图。

image.png

没错,就是Spring Bean生命周期图。就因为这张图不熟悉,导致线上环境出现内存泄漏问题,系统频繁FullGC,服务无法响应。

一、第一次报错系统监控现象

image.png

关键时间节点:

14:16 机器发布新代码 15:35 机器开始出现fullGC 15:50 机器fullGC耗时上升 17:48 对JVM进行dump操作,然后进行机器置换

由图可知,在14:16发布完成后,系统正常运行了一段时间,期间内存、线程等均未出现异常,不过当系统运行了一段时间后,通过监控可以明显发现内存使用量和线程数都在持续上升,那这样问题就很明确了:

1.有大量阻塞线程

2.存在内存泄露问题

1.1 排查过程

分析线程Dump文件

image.png

通过截图中Dump文件内容可知,HSFBizProcessor-DEFAULT-9-thread-792 这个线程已经阻塞了116s,并且的阻塞线程共有682个。

1.2 分析原因

根据线程堆栈信息,查到了线程是阻塞在下面这段代码:

@Component
public class OssClient implements BeanPostProcessor {
private OSS ossClient = null;
/** 
     * 初始化OSS客户端
     **/
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
// 省略代码……
// 以下是阻塞代码行
        ossClient = new OSSClientBuilder().build(ossProperty.getString("endpoint"),
                        ossProperty.getString("accessKeyId"),
                        ossProperty.getString("accessKeySecret"),
                        configuration);
// 省略代码……
return bean;
    }
}

这段代码本意是在应用启动时,通过动态配置文件来配置OSS客户端。

但是线程阻塞在了这行,首先我想到可能是由于OSS客户端初始化需要发起网络请求,因为饿了么有张北和南通机房且一般情况下跨机房无法访问,所以第一时间检查了一下配置,果不其然,南通机房配置了张北的OSS。

登录上南通机房的机器,尝试PING张北的OSS域名,发现无法PING通,验证了我的猜测。

image.png

1.3 第一次问题解决

Get到了报错原因,就方便解决了;通过修改配置,将OSS机房配置正确后,重启机器即可。


二、第二次报错系统监控现象

本来以为万事大吉,在观察了30分钟,确认系统无BLOCKED线程后,就认为该问题已经解决。

image.png

关键时间节点:

19:48 机器发布新代码 22:30 机器开始出现fullGC 23:30 机器fullGC耗时上升 00:30 对JVM进行dump操作,然后进行机器置换

然而,在发布后3个小时以后,系统又开始报错,同样是fullGC,只不过这次fullGC耗时没有之前那么长了。

2.1 排查过程

分析线程Dump文件

因为有了前车之鉴,所以第一步想到的就是上一步的问题没有解决,线程仍然阻塞在刚才的代码处。

image.png

不过,这次并没有查询到阻塞线程。这至少证明:

1.阻塞线程确实是由于OSS跨单元拒绝访问导致的

2.还有其他问题导致了内存泄漏

分析GC Dump文件

首先,通过集团Grace工具,发现有严重的内存泄漏问题。

image.png

这里显示有11万个org.apache.http.impl.conn.PoolingHttpClientConnectionManager实例,占用了80.42%的堆内存,但是这个类并不是我直接引入的,那么一定是有间接依赖,生成了大量该类对象。

另外,通过类名,能判断这个对象是和网络请求有关系,而我这个应用上需要网络请求的地方有几处: 1.访问DB 2.访问Redis 3.访问OSS 4.进行HSF调用

继续通过对对象依赖进行分析,发现了一个重要信息:

image.png

org.apache.http.impl.conn.PoolingHttpClientConnectionManager这个类由OSS间接依赖进来的,确定了引起内存泄漏的罪魁祸首。

2.2 分析原因

虽然定位到了是由于OSS建议依赖进来,但是看代码仍然不能解释为什么会产生内存泄漏。

@Component
public class OssClient implements BeanPostProcessor {
private OSS ossClient = null;
/** 
     * 初始化OSS客户端
     **/
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
// 省略代码……
// 一下是阻塞代码行
        ossClient = new OSSClientBuilder().build(ossProperty.getString("endpoint"),
                        ossProperty.getString("accessKeyId"),
                        ossProperty.getString("accessKeySecret"),
                        configuration);
// 省略代码……
return bean;
    }
}

排查原因过程中,有一篇文章给了我答案,下面是这篇文章给的OOM原因的解释:

每次new OSSClient的时候,都会往List中放入HttpClientConnectionManager,但是没有主动调用OSSClient的shutdown的方法,所以List只会增大不会变小。反观我们的代码,每次接口调用都会创建一个OSSClient对象,但却在使用完之后,没有调用OSSClient的shutdown方法,导致未调用IdleConnectionReaper的removeConnectionManager方法,使得IdleConnectionReaper中静态列表存储的PoolingHttpClientConnectionManager实例数据一直会增长,一直都不会被回收,最终带来的结果就是OOM。

其实通过代码能够看出,我的初衷是在OssClient这个Bean初始化的时候执行一下初始化逻辑,在我查到导致内存泄漏的原因后,我仍然对一个问题很是不解:为什么OSS初始化的代码会被多次执行?

回到文章标题和开头,为什么这篇文章标题叫“一次由于八股文引起的内存泄漏”,以及为什么文章开头会引入下面这张图?

image.png

实际上,是由于实现错了接口导致的OSS初始化代码被重复调用,最终导致系统OOM。

2.3 最终问题解决

改变一下实现接口,使代码逻辑符合我预期效果即可,当然这个解决方式有多种多样,下面只是我的一种解决方案。

@Component
public class OssClient implements InitializingBean {

    private OSS ossClient = null;

    /** 
     * 初始化OSS客户端
     **/
    @Override
    public void afterPropertiesSet() throws Exception {
        // 省略代码……
        // 以下是阻塞代码行
        ossClient = new OSSClientBuilder().build(ossProperty.getString("endpoint"),
                        ossProperty.getString("accessKeyId"),
                        ossProperty.getString("accessKeySecret"),
                        configuration);
        // 省略代码……
    }

}


总结

圈内常有声音抱怨,“面试好比是造火箭,而工作不过是拧螺丝”,尤其对于Java开发岗位面试中的常规知识题目持有轻蔑态度。然而,这些被称作“八股文”的知识,实际上是每位开发工程师技术根基的核心。坚实的基础才能确保构建在其之上的高楼大厦能够屹立不倒,历经岁月的洗礼。


作者 |  星驰

来源 | 阿里云开发者公众号

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
相关文章
|
2天前
|
存储 监控 NoSQL
一次由于八股文引起的内存泄漏
本文描述了一次由于对Spring Bean生命周期理解不当导致的Java应用程序内存泄漏问题。开发者在`BeanPostProcessor`接口的实现中错误地在每次Bean初始化时创建了OSS客户端,但没有正确关闭连接管理器,导致连接池不断增长,最终引发内存泄漏。在初次修复跨单元访问问题后,系统仍出现Full GC,通过分析发现OSS客户端的初始化代码因接口实现错误而被多次调用,进一步加剧了内存泄漏。通过改用`InitializingBean`接口并正确实现初始化逻辑,问题得以解决。文章强调了基础知识的重要性,即使是面试中常见的“八股文”知识,也是实际工作中解决问题的关键。
|
11天前
|
缓存 算法 Java
这些年背过的面试题——JVM篇
本文是技术人面试系列JVM篇,面试中关于JVM都需要了解哪些基础?一文带你详细了解,欢迎收藏!
|
11天前
|
架构师 编译器 程序员
内存泄露专题(1)何为内存泄露
内存泄露专题(1)何为内存泄露
22 1
|
10月前
|
算法 Java 程序员
JVM面试专题:面试中JVM常问的问题你都知道吗?
JVM面试专题:面试中JVM常问的问题你都知道吗?
146 1
JVM面试专题:面试中JVM常问的问题你都知道吗?
|
存储 Java Spring
面试官:ThreadLocal 为什么会内存泄漏吗?是怎么产生的?面试必问!
面试官:ThreadLocal 为什么会内存泄漏吗?是怎么产生的?面试必问!
116 0
|
算法 Java 大数据
2020大厂面试之【JVM+GC】必考面试题讲解
2020大厂面试之【JVM+GC】必考面试题讲解
105 0
2020大厂面试之【JVM+GC】必考面试题讲解
|
Java Linux Android开发
这次,我想把内存泄漏讲明白
这次,我想把内存泄漏讲明白
227 0
这次,我想把内存泄漏讲明白
|
存储 Web App开发 监控
一文让你读懂内存泄露
[TOC] ## 0. 背景 [![e62eaf67-820c-49ee-9295-86011d7d596c](https://typro-img-1256878004.cos.ap-nanjing.myqcloud.com/e62eaf67-820c-49ee-9295-86011d7d596c-1607941296624.jpg)](https://typro-img-1256878004.cos.ap-nanjing.myqcloud.com/e62eaf67-820c-49ee-9295-86011d7d596c-1607941296624.jpg) 没想到项目放到线上后
104 0
|
缓存 前端开发 Oracle
面试必问的 JVM 类加载机制,你懂了吗?
本次带来JVM 的另一块重要内容,类加载机制,不废话,直接开怼。
159 0
面试必问的 JVM 类加载机制,你懂了吗?
|
算法 Java
面试官:谈谈你对JVM垃圾收集器的了解
面试官:谈谈你对JVM垃圾收集器的了解
面试官:谈谈你对JVM垃圾收集器的了解