解决服务器卡死和内存泄漏问题的经历

自己的个人兴趣爱好是处理数据，因此在线上有一个阿里云服务器用于频繁IO和数据分析。然而，服务器经常会出现卡死的情况，每隔大约两个月就需要重启才能正常运行。起初并未太在意，直到这个问题开始影响到我的收入，我才开始重视起来。服务器的启动脚本如下：

nohup java  -Xms512m  -Xmx1024m  -jar xxx.jar  &

显然，这个脚本存在很多问题。由于这是我自己的服务器，我追求的只是简单和粗暴，所以并没有太多顾虑。然而，我埋下的坑终究是要填上的。

有一天，我登录服务器时发现无法成功登录，类似xshell的提示。虽然看起来是连接上了，但无法进入服务器，这种情况通常是由于网络问题或服务器卡死引起的。通过阿里云控制台也无法进入，一般这种情况需要等一段时间，待消耗内存的应用被杀掉后，才能重新登录。然而，我这种性急的人当然选择了直接在阿里云后台强制重启服务器。

尽管服务器能够重新登录，但却没有任何日志可供查询，没有堆栈信息。查看日志也未发现OOM（内存溢出）错误的记录，这让我感到非常惊讶。因此，我修改了启动脚本，以便在下一次出现类似情况时能够留下一些痕迹：

nohup java  -Xms512m  -Xmx1024m  -Xlog:gc*:file=gc.log:time,uptime,level,tags -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps -jar  xx.jar &

由于出现了OOM错误，我开始关注内存情况。通常情况下，我们需要关注垃圾回收器的行为以及堆内存的使用情况。因此，我添加了参数-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath，以便在发生堆内存溢出时导出内存文件进行后续分析。终于，在两个月后的某一天，我发现了OOM错误：

这一情况非常离奇。上一次服务器卡死时我直接强制重启了，但在nohup.out文件中并没有发现OOM错误的日志。然而，这一次却出现了OOM错误日志。这个问题至今我仍未搞清楚。服务器有2GB内存，启动脚本堆内存最大为1GB，理论上完全足够使用，不应该耗尽服务器内存。难道代码中还存在IO等内存泄漏问题？先不管了，先解决眼前的问题。既然是OOM错误，自然需要查看哪个实例占用了内存，使用MAT进行分析。

可以看到有一个大对象占用了692.4MB的内存，这基本可以确定问题出现在这个对象上。然后我发现其中有一个属性是一个静态成员变量map，其中包含了6291456个key。结合代码来看，该变量会根据具体情况被业务数据填充，但并没有释放的地方。因此，这就是问题所在。

我采取了简单粗暴的定时内存清理方法：

由于OOM错误出现的时间间隔较长，这段代码能够使用，但并不是一种优雅的解决方法。然而，由于自己的项目代码混乱不堪，难以修改，因此只能将就着用。毕竟有一句话说得好：“如果你的代码以某种莫名其妙的方式运行，就不要再去碰它了”。否则将会面对残酷的结果：

文章中提到设置了-Xmx1024m，但实际导致了服务器2GB内存卡死的问题，可能存在内存泄漏。因此，我在启动脚本中加上了参数-XX:MaxDirectMemorySize=256M，以控制本地内存。如果再次出现OOM错误，我将继续进行调整：

nohup java  -Xms512m  -Xmx1024m  -Xlog:gc*:file=gc.log:time,uptime,level,tags -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps -XX:MaxDirectMemorySize=256M -jar  xx.jar &

希望大家在编写代码时不要偷懒，最好将gc日志参数和堆内存导出等设置好。