阿里妹导读
本文记录两次报错系统监控现象以及作者针对性的排查过程和分析，最终解决了问题的全过程。
文章开头，先分享一张大部分Java开发同学都记在心里的一张图。
没错，就是Spring Bean生命周期图。就因为这张图不熟悉，导致线上环境出现内存泄漏问题，系统频繁FullGC，服务无法响应。
一、第一次报错系统监控现象
关键时间节点：
14:16 机器发布新代码
15:35 机器开始出现fullGC
15:50 机器fullGC耗时上升
17:48 对JVM进行dump操作，然后进行机器置换
由图可知，在14:16发布完成后，系统正常运行了一段时间，期间内存、线程等均未出现异常，不过当系统运行了一段时间后，通过监控可以明显发现内存使用量和线程数都在持续上升，那这样问题就很明确了：
1.有大量阻塞线程
2.存在内存泄露问题
1.1 排查过程

分析线程Dump文件

Dump文件记录
通过截图中Dump文件内容可知，HSFBizProcessor-DEFAULT-9-thread-792 这个线程已经阻塞了116s，并且的阻塞线程共有682个。
1.2 分析原因
根据线程堆栈信息，查到了线程是阻塞在下面这段代码：
@Componentpublicclass OssClient implements BeanPostProcessor {private OSS ossClient = null;/** * 初始化OSS客户端 **/@OverridepublicObject 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通，验证了我的猜测。
1.3 第一次问题解决
Get到了报错原因，就方便解决了；通过修改配置，将OSS机房配置正确后，重启机器即可。
二、第二次报错系统监控现象
本来以为万事大吉，在观察了30分钟，确认系统无BLOCKED线程后，就认为该问题已经解决。
关键时间节点：
19:48 机器发布新代码
22:30 机器开始出现fullGC
23:30 机器fullGC耗时上升
00:30 对JVM进行dump操作，然后进行机器置换
然而，在发布后3个小时以后，系统又开始报错，同样是fullGC，只不过这次fullGC耗时没有之前那么长了。
2.1 排查过程

分析线程Dump文件

因为有了前车之鉴，所以第一步想到的就是上一步的问题没有解决，线程仍然阻塞在刚才的代码处。
不过，这次并没有查询到阻塞线程。这至少证明：
1.阻塞线程确实是由于OSS跨单元拒绝访问导致的
2.还有其他问题导致了内存泄漏

分析GC Dump文件

首先，通过集团Grace工具，发现有严重的内存泄漏问题。
这里显示有11万个org.apache.http.impl.conn.PoolingHttpClientConnectionManager实例，占用了80.42%的堆内存，但是这个类并不是我直接引入的，那么一定是有间接依赖，生成了大量该类对象。
另外，通过类名，能判断这个对象是和网络请求有关系，而我这个应用上需要网络请求的地方有几处：
1.访问DB
2.访问Redis
3.访问OSS
4.进行HSF调用
继续通过对对象依赖进行分析，发现了一个重要信息：
org.apache.http.impl.conn.PoolingHttpClientConnectionManager这个类由OSS间接依赖进来的，确定了引起内存泄漏的罪魁祸首。
2.2 分析原因
虽然定位到了是由于OSS建议依赖进来，但是看代码仍然不能解释为什么会产生内存泄漏。
@Componentpublicclass OssClient implements BeanPostProcessor {private OSS ossClient = null;/** * 初始化OSS客户端 **/@OverridepublicObject 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。
2.3 最终问题解决
改变一下实现接口，使代码逻辑符合我预期效果即可，当然这个解决方式有多种多样，下面只是我的一种解决方案。
@ComponentpublicclassOssClientimplementsInitializingBean{private OSS ossClient = null;/** * 初始化OSS客户端 **/@OverridepublicvoidafterPropertiesSet()throws Exception {// 省略代码……// 以下是阻塞代码行 ossClient = new OSSClientBuilder().build(ossProperty.getString("endpoint"), ossProperty.getString("accessKeyId"), ossProperty.getString("accessKeySecret"), configuration);// 省略代码…… }}
总结
圈内常有声音抱怨，“面试好比是造火箭，而工作不过是拧螺丝”，尤其对于Java开发岗位面试中的常规知识题目持有轻蔑态度。然而，这些被称作“八股文”的知识，实际上是每位开发工程师技术根基的核心。坚实的基础才能确保构建在其之上的高楼大厦能够屹立不倒，历经岁月的洗礼。
继续阅读
阅读原文
关键词
代码
问题
内存泄漏
线程
篇文章