TOMCATwebsocket多连接内存泄漏与jetty对比分析

服务器环境8核 32G内存

问题&＃xff1a;

在5000个连接的时候Tomcat内存基本吃满

Tomcat 压测&＃xff1a;

检查下JVM内存使用情况&＃xff0c;其中老年代被占用了98.4%&＃xff0c;有大量不能释放的对象在heap。

老年代内存大小31.5G&＃xff0c;老年代使用31G

JETTY压测

内存情况老年代被使用了79.4%&＃xff0c;老年代总大小3.5G占用0.5G

通过现象我们可以看到jetty占用内存非常小&＃xff0c;而TOMCAT暂用却非常多&＃xff0c;但是国外论坛有人Tomcat却可以压到4万的连接&＃xff0c;是什么东西占用了这么多heap空间呢?

分析TOMCAT内存占满原因&＃xff1a;

一&＃xff0c;由于测试方便在本地启动程序建立了501个连接&＃xff0c;并且用jmap生成了快照

二&＃xff0c;我们用mat来分析下内存的情况&＃xff08;也可以用jhat&＃xff0c;但是太low了很多还需要人工肉眼看和计算&＃xff09;

我们可以看到WsFrameServer占用了2.9的heap空间对象个数恰好是我们建立的连接数

三&＃xff0c;现在我们来分析WsFrameServer对象&＃xff0c;到底什么东西可以占用这么大

我们可以看到WsFrameServer对象直接引用对象的heap空间HeapCharBuffer和HeapByteBuffer非常大

我们再来看看这个大对象什么引用在引用&＃xff0c;通过分析我们知道了原来是WsFrameServer的messageBufferText成员变量

下面我们来看下源代码

我们在WsFrameServer的父类中发现了这两个大对象的引用

那么问题来了&＃xff0c;是什么原因导致这个对象很大的呢&＃xff1f;我们继续看源代码什么地方用来它&＃xff0c;特别是初始化的时候

我们检查到&＃xff0c;这个地方初始化的&＃xff0c;初始化大小是wsSession.getMaxBinaryMessageBufferSize()

和wsSession.getMaxTextMessageBufferSize()&＃xff0c;那么问题又来了&＃xff0c;这两个值有是从哪里来的呢&＃xff1f;

我们查看源码

有一个默认值是8K&＃xff0c;如果是8K的话内存不至于溢出&＃xff0c;看什么地方做了赋值

原来是这个地方做的赋值&＃xff0c;那么webSocketContainer又是从哪里来的呢&＃xff1f;

我们点进去

这里要么是默认值&＃xff0c;要么是什么地方做了设置我们打断点调试&＃xff0c;而且这个默认值是8K&＃xff0c;肯定是什么地方修改了&＃xff0c;那么我们在set方法打断点

断点来了&＃xff0c;我们通过线程栈来分析下什么地方调到这里来的&＃xff0c;跟着往上点

最后我们发现是这个类ServletServerContainerFactoryBean&＃xff0c;这个类是spring提供的&＃xff0c;我们是在这儿用到了&＃xff0c;原来如此&＃xff0c;内存之所以这么大就是这里的设置导致的&＃xff0c;这个设置的目的是让websocket可以传输更大的消息

其实我们看到的Tomcat的webSocketContainer是实现了javax.websocket.webSocketContainer的&＃xff0c;很明显这个是J2EE的规范我们可以查下这个规范

https://docs.oracle.com/javaee/7/api/javax/websocket/WebSocketContainer.html

其实这个类就是在初始化的时候可以让你设置websocket相关的一些参数

但是它设置了之后对所有session都生效了所以导致我们的连接数上不去&＃xff0c;有什么办法可以解决吗&＃xff0c;我们查到有另外的J2EE规范可以在运行过程中动态的修改而且是针对特定session的

那么问题来了&＃xff0c;为什么jetty没有出现这个问题&＃xff0c;如果是J2EE的规范那么我们设置这个值JETTY也应该出现这个问题&＃xff0c;可是没有&＃xff01;

我们再来对jetty进行调试&＃xff0c;发现这个配置对jetty不起作用

为什么不起作用呢&＃xff1f;这又是另外的问题了~

后来通过源码分析得知JETTY和TOMCAT的实现不一样&＃xff0c;不知道算不算BUG&＃xff0c;个人认为是JETTY的BUG~

什么代码实现导致他们不一样呢&＃xff1f;

Tomcat每次请求过来时在创建session时都会把这个webSocketContainer作为参数传进去所以对所有的session都生效了

我们来看看jetty

启动初始化时jetty把webSocketContainer的参数值设置给了这个过滤器&＃xff0c;我们看看这个过滤器它的dofilter方法

其实在这个过滤器我们没有注册任何的访问URL&＃xff0c;因为我们是通过spring提供的方式实现的websocket&＃xff0c;如果我们在这个过滤器注册了访问URL那么所有过来的请求都会生效~可以继续跟后面的代码&＃xff0c;其实就是调用的其他处理器来处理&＃xff0c;这些处理器是在这里初始化的

每个url都有一个单独的处理器&＃xff0c;这个实现是springboot提供的

spring给每一个websocket URL单独new 了一个处理器&＃xff0c;jetty里面这个类是WebSocketServerFactory

其实jetty的处理方式是事件驱动模式设计&＃xff0c;把所有的请求当做一个事件&＃xff0c;不同的事件有自己对应的eventdriver来处理

重点是jetty在实例化这个对象的时候并没有把webSocketContainer所带的参数设置进去

这就导致了Tomcat生效jetty没有生效&＃xff0c;其实你还会发现虽然jetty的buffer默认大小是64K&＃xff0c;Tomcat是8K&＃xff0c;可是jetty压测的时候CPU和内存都比Tomcat少&＃xff0c;这是为什么呢&＃xff1f;

原因是jetty用了对象池&＃xff0c;不像tomcat来一次请求就new一个buffer&＃xff0c;下面是jetty使用对象池的地方

后面简单做了netty的压测10000个连接消耗内存190M&＃xff0c;吊炸天的存在