知识2025-10-04 00:56:271739

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

来源：阿里技术

这是次由2024年的第12篇文章

（本文阅读时间：15分钟）

前言文章开头，先分享一张大部分Java开发同学都记在心里的于股一张图。

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

第一次报错系统监控现象

关键时间节点：14:16 机器发布新代码15:35 机器开始出现fullGC15:50 机器fullGC耗时上升17:48 对JVM进行dump操作，然后进行机器置换由图可知，泄漏在14:16发布完成后，次由系统正常运行了一段时间，于股期间内存、文引线程等均未出现异常，内存不过当系统运行了一段时间后，泄漏通过监控可以明显发现内存使用量和线程数都在持续上升，那这样问题就很明确了：1.有大量阻塞线程2.存在内存泄露问题2.1 排查过程分析线程Dump文件

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

2.2 分析原因

根据线程堆栈信息，查到了线程是阻塞在下面这段代码：@Componentpublic class OssClient implements BeanPostProcessor { private OSS ossClient = null;/** * 初始化OSS客户端 **/@Overridepublic 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通，验证了我的猜测。

2.3 第一次问题解决

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

第二次报错系统监控现象

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

关键时间节点：19:48 机器发布新代码22:30 机器开始出现fullGC23:30 机器fullGC耗时上升00:30 对JVM进行dump操作，然后进行机器置换然而，在发布后3个小时以后，系统又开始报错，同样是fullGC，只不过这次fullGC耗时没有之前那么长了。

3.1 排查过程

分析线程Dump文件因为有了前车之鉴，所以第一步想到的就是上一步的问题没有解决，线程仍然阻塞在刚才的高防服务器代码处。

不过，这次并没有查询到阻塞线程。这至少证明：1.阻塞线程确实是由于OSS跨单元拒绝访问导致的2.还有其他问题导致了内存泄漏分析GC Dump文件首先，通过集团Grace工具，发现有严重的内存泄漏问题。

这里显示有11万个org.apache.http.impl.conn.PoolingHttpClientConnectionManager实例，占用了80.42%的堆内存，但是这个类并不是我直接引入的，那么一定是有间接依赖，生成了大量该类对象。另外，通过类名，能判断这个对象是和网络请求有关系，而我这个应用上需要网络请求的地方有几处：1.访问DB2.访问Redis3.访问OSS4.进行HSF调用继续通过对对象依赖进行分析，发现了一个重要信息：

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

3.2 分析原因

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

@Componentpublic class OssClient implements BeanPostProcessor { private OSS ossClient = null;/** * 初始化OSS客户端 **/@Overridepublic 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初始化的代码会被多次执行？回到文章标题和开头，为什么这篇文章标题叫“一次由于八股文引起的内存泄漏”，以及为什么文章开头会引入下面这张图？

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

3.3 最终问题解决

改变一下实现接口，使代码逻辑符合我预期效果即可，当然这个解决方式有多种多样，下面只是我的一种解决方案。@Componentpublic 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开发岗位面试中的常规知识题目持有轻蔑态度。然而，这些被称作“八股文”的知识，实际上是每位开发工程师技术根基的核心。坚实的基础才能确保构建在其之上的高楼大厦能够屹立不倒，历经岁月的洗礼。

相关文章