在系统部署生产环境后， 在十天左右就会出现系统反应慢， 堆爆了，cpu占用百分百的情况。 在重启tomcat后情况就恢复了。
在经过详细的 跟踪， 线程dump, 堆dump 下来分析后， 线程没有问题， 发现有两个原因：
1： 通过memory analyzer 分析 堆dump文件后， 有一个缓存对象无限增长，并保持活动， 导致回收不了， 堆爆掉。
2：由于后台 频繁gc, 导致系统响应慢，导致 liunx服务器的 time_wait 连接数量飙升， 参数没有设置： 将超时等待的连接用于新的连接。 导致前台请求不够。
解决方案：
1: 缓存对象 无限增长 回收不了的问题 解决方案为： 本来使用过后不用的对象应该移除的， 没有移除成功， 将此bug修复， 保持增长和移除相对稳定。
2： 超时等待的原因解决： 文章地址： https://www.aliyun.com/jiaocheng/810456.html
这个命令是查询连接数：
netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"/t",state[key]}'
TIME_WAIT 250263
TIME_WAIT 250263
CLOSE_WAIT 57
FIN_WAIT2 3
ESTABLISHED 2463
SYN_RECV 8
time_wait 数量过多：
可以修改系统的/etc/sysctl.conf配置来减少TIME_WAIT的tcp连接:
vi /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1(某些情况下该参数已启用)
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行/sbin/sysctl -p让参数生效。再用命令查看TIME_WAIT连接数 netstat -ae | grep “TIME_WAIT” |wc -l 发现大量的TIME_WAIT 已不存在。
这个图片为：出现卡顿时的 jvisualvm 的监控， cpu使用百分比， 频繁gc, 堆使用百分百。
以下图片为 memory Analyzer 工具分析 堆dump文件的图像
以下图片为老区中 无限增长的对象的类名， 对象及大小。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
