线上运行出现请求不了，查看机器cpu不高，第一次出现，以为出现慢sql了，查看jstack没有异常，怀疑是前端slb没有转发。

重启应用后修复，过了15天，再次出现接口不通，发现应用内存占用很高。

第一次尝试修复

使用jdump，查看实例数

/usr/jdk1.8.0_211/bin/jmap -histo:live [pid]

发现有一个tomcat的wsSession有10000个实例，占用了较高内存。

这个10000的数字很特殊，重点关注此业务，websocket使用的springboot的websocket封装。

怀疑是网络异常没有关闭，找到类似问题

https://bz.apache.org/bugzilla/show_bug.cgi?id=64848

怀疑是tomcat版本问题，springboot使用的默认版本是8.5.31，修改pom.xml指定tomcat的version最新的8.5.70版本。

顺带一提，8.5.51版本修复了高危漏洞，官方建议升级。

第二次尝试修复

上线后观察wsSession实例数，仍然是增高趋势，看来甩锅框架是不行了。看看自己的业务代码吧。

学习了jdump的命令

/usr/jdk1.8.0_211/bin/jmap -dump:live,format=b,file=jdump.hprof [pid]

拿到详细内存情况，学习使用jdk自带的jvis工具分析，学习使用MAT分析。

使用放google搜索，找到一个说法，需要在websocketHandler的handleTransportError方法和afterConnectionClosed再用webSocketSession.close()关闭一次。

部署上线后仍旧没有变化。

第三次尝试修复

根据close一次的思路，应该是链接状态不正常，没有关闭。

进行系统网络信息分析，使用 lsof -a 查看应用的链接信息，发现和wsSession实例数一样的tcp链接，状态为ESTABLISHED。这个状态是链接中状态。

确定为此问题，解释了为啥10000个实例，因为系统默认最高句柄是10000个，也解释了为啥应用问题是无法访问了，是无法创建新的链接通道了。

另外，吸取经验，若是无法访问，需要lsof -l看一下是否文件句柄满了。

查看自己的websocket应用超时设置。

没有异常情况呢，但是发现少设置了一个值，默认是-1表示永不超时。加上container.setAsyncSendTimeout(60*1000L);吧，也许就可以了呢？

@Bean
public ServletServerContainerFactoryBean createWebSocketContainer() {
ServletServerContainerFactoryBean container = new ServletServerContainerFactoryBean();
container.setMaxTextMessageBufferSize(8192);
container.setMaxBinaryMessageBufferSize(8192);
container.setMaxSessionIdleTimeout(3*60*1000L);

container.setAsyncSendTimeout(60*1000L);
return container;
}

第四次尝试修复

没错，没有用，啥都没变，而且我还发现ESTABLISHED的链接堆积加快了。。

抓紧学习tcp的知识，问题已经变成了ESTABLISHED链接堆积的问题，这个资料很多，但是没有websocket的。

这个情况有可能是客户端没有close，要么是close了但是网络问题，没来的及发送fin导致服务端还在等待。

但是如此频繁的情况，仍旧怀疑是客户端没有调用close方法，但是联系客户端的同事。他说"就算是我的问题，难道你服务端不能将链接关闭掉？"

说的有点道理啊，好吧我们看看，tcp状态保持在了连接中，一般是系统keeplive检测倒计时关闭的。

查看系统配置vi /etc/sysctl.conf，没有设置net.ipv4.tcp_fin_timeout默认是7200，2个小时好像有点长，我改成1800，/sbin/sysctl -p生效。观察情况。

第五次尝试修复

观察结果就是没有用。查看了资料websocket好像没有用keeplive啊，ping/pong的样子。链接信息中也没有timer倒计时。

问题似乎没得玩了，难道只能定时重启应用解决了么。。

既然是websocket处理，那就还是看源码吧，配合着源码分析的文章，一知半解。

重看jdump的信息，MAT分析每一个留存很久的wsSession的状态都是output_close。而且自动分析内存泄漏的情况是

websocket 657 instances of “org.apache.coyote.http11.upgrade.UpgradeProcessorInternal”, loaded by “org.springframework.boot.loader.LaunchedURLClassLoader“

感觉是更底层的事情了？我们使用spring的框架，实际操作的是spring的webSocketSession。

发现当调用spring的webSocketSession.close() 会先调用内部包装的getNativeSession就是实际的tomcat的wssession的close。

继续查看，这里调用的doClose的方法，第三个参数是false。

这个boolean影响的就是 是否调用wsRemoteEndpoint.close()方法。

感觉有点那个味道了，试一下关闭这个试试吧。

spring的websocketSession可以拿到内部包装的tomcat的session，找到一个onclose方法，可以跳过这个判断直接关闭。

加了就是上面第二个try，nativeSession直接调用onClose方法。

打完收工

没错，这个代码上线后，不再有问题链接堆积了。

这期间还学习了ss -aoen 命令，看到ESTAB的链接会转TIME_WAIT状态，然后会等待2ML时间据说就是1min后链接就释放了。

实际观察和应用内的链接数一致。

总结一下

遇到问题，总是会先排除自己代码问题，是不是框架问题？是不是客户端问题？

这样最终还是没有结果的，能改变的还是只有自己。

研究问题的过程中，学习了好多知识，好多工具，收获也很大。

加油！

第6次尝试

如此修改后，会出现更快的sockt连接占用问题，原因不明，现象就是阿里云虚拟机中的连接数正常，但是阿里云的物理机监控连接数会到10k，最后仍旧连接数占满然后请求无法到达tomcat。

根据tcpdump抓包查看，已经ESTAB的tcp连接其实没有消息进出，但是不知道为何系统没有回收。

最后的处理方法是，中间加一层nginx代理，在代理中增加 proxy_readtimeou 300; 用nginx来断超时的连接，这样tomcat可以识别到连接的释放。根据观察连接数可以保持在正常的水平了。

附上nginx代理配置

server{
    listen 8070;
    server_name _;
    location / {
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:8071;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}