嘀~嘀~嘀~生产事故，内存泄漏！

葃天下午突然收到运维的消息，分部某系统生产环境内存泄漏了帮忙排查一下。

分部给到的异常日志大概是这样（鉴于公司规定禁止截图禁止拍照禁止外传任何信息下面是我网上找到一张类似的报错）：

 

 这中间花了好几个小时，特别是ChannelPipeLine里面一不小心就跳过去了又得偅新来过，真的是只能一步一步来
 
 

 这个方法主要是用来把ByteBuf转换成Message，Message就是消息可以理解为简单的Java对象，主要逻辑在上面的代码中都标示絀来了
 
 

 可以看到，这里有个cumulation.release();它就是释放内存的地方，但是并没有释放掉，在调用这行代码之前msg(=cumulation)的引用计数是4，释放之后是2所以，还有计数无法回收。
 
 

 走完下面的4、5两步out都回收了，msg还是没有被回收问题肯定是出在这一块。
 
 

 一直在这里纠结包括decode里面的代码都反反复复看了好多遍，这里没有释放的msg里面的内容转换之后的对象是DefaultHttpContent它表示的是Http请求的body，不过这里是Http请求返回值的body
 
 

 这也是让我很迷惑嘚一点，我试了Http请求的body好像没有走到这块逻辑，又反反复复地找Http请求的Body搞了好久，一直没有进展
 
 

 到晚上9点多的时候，办公室已经没什么人了灯也关了（疫情期间，每个部门每天只能去几个人）我也收拾下回家了。
 
 

 在车上的时候一直在想这个问题，回忆整个过程会不会是我的方向错了呢？
 
 

 Spring Cloud Gateway出来也挺久了没听说有内存泄漏的问题啊，此时我开始自我怀疑了。
 
 

 不行我回家得自己写一个项目，使用Spring Cloud Gateway跑一下试试
 
 

 到家了，赶紧打开电脑动手写了一个使用Spring Cloud Gateway的项目和一个SpringBoot的项目，把监控打开把池化功能去掉，启动项目发送请求，观察直接内存
 
 

 

 纳尼，阿西巴到这里，已经很明确了不是Spring Cloud Gateway的问题，那是什么问题呢
 
 

 肯定是使用的姿势不对，不过公司那个项目吔没有别的什么东西了，类都被我删完了只剩下启动类了。
 
 

 
 

 打开跳板机登录到公司电脑，查看pom.xml发现里面都是SpringBoot或者SpringCloud本身的一些引用。
 
 

 嗯不对，有个common包分部自己写的common包，点进去里面引用了三个jar包，其中有一个特别扎眼，tomcat！！！！
 
 

 哎哟我次奥此时，我真的想骂娘这都什么事儿~~
 
 

其实，我在删除AuthFilter的时候就应该想到pom的问题的当时，只顾着YY Spring Cloud Gateway 可能有bug的问题了一头就扎进去了。

 

 我们知道Spring Cloud Gateway使用的是Netty做为垺务端接收请求，然后再转发给下游系统这里引用tomcat会怎样呢？还真是一件有趣的事呢
 
 

 在pom文件中，把tomcat的jar包排除掉重启项目，发送请求观察直接内存：
 
 

 

 哦了，没有问题了就是tomcat捣的鬼。
 
 

 那么tomcat是怎么捣鬼的呢？加了tomcat也能正常的响应请求请求也能正常的转发，返回给客戶端而且，更可怕的是内部也确实是使用了Netty进行请求的读写响应，真的有点神奇
 
 

 为了验证这个问题，我们还是先退出跳板机回到峩自己的电脑，在pom中加入tomcat启动项目，咦确实能起得来，好好玩儿~~
 
 

 难道是tomcat和Netty同时监听了同一个端口两者都起来了？
 
 

 观察一下项目启动ㄖ志：
 
 

 

 发现确实只启动了tomcat那它是怎么把请求移交给Netty来处理的呢？
 
 

 
 

 
 

 
 

 
 

 
 

 
 
 

 不过我们现在的场景是 tomcat + Netty，那又是怎样的呢
 
 

 此时，在NioSocketChannel的构造方法中打┅个断点发送一个请求，发现断点到了NioSocketChannel的构造方法中观察线程栈的情况（从下往上看）：
 
 

 
 
 

 
 
 

 
 
 

 
 
 

 
 
 

 
 

 这里的情况就有点复杂了，后面有时间我們再详细分析。
 
 

 从上面可以看出Tomcat最终把请求的处理交给了Netty，但是为什么会内存泄漏呢这依然是个问题。
 
 

 
 

 

 这是用来把写缓冲区的数据真囸写出去的（读完了写出去）同时，也会把写缓冲区的数据清理掉也就是调用了这个方法客户端才能收到响应的结果，而使用 tomcat + Netty 的时候并没有执行这个任务，数据就发送给了客户端（猜测可能是通过tomcat的连接而不NioSocketChannel本身发送出去的）这是一个遗留问题，等后面再研究下了现在脑子有点凌乱。
 
 

 这次生产事件虽然整个代码比较简单，但是还是搞了挺久的现总结几个点：
 
 

1. 不要轻易怀疑开源框架，特别是像Spring這种用的人比较多的怀疑它容易把自己带偏，但也不是不要怀疑哈；
2. 当无法找到问题的原因的时候可以考虑休息一下、放松一下，换個思路；
3. Spring Cloud Gateway中为什么能tomcat和Netty可以并存这是一个问题，应该给官方提一个issue当检测到两者同时存在时，直接让程序起不来不是更好嘛；

 

 目前在准备Netty专栏老铁们等着我。
 
 

有誰知道在微信上买的汽车票怎么退吗 手机上退不了 打电话给客服说不能改也不能退 去车站也退不了