在一次服务更新后发现每天凌晨0点3秒服务准时挂，开始的时候认为是maven依赖中存在system.exit(3)类似这样的代码，但是我想了下这个代码很多客户都有用到但是只有这一个客户出现了问题，而且另外一个服务没有更新在此前几个月都是没问题的 这几天也是一样无故挂了。

windows服务器

1、初步怀疑是内存泄漏问题，在启动脚本中加入 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:\heapdump.log，第二天起来一看还是挂了没有出现dump日志说明不是内存泄漏 2、白天几千几万的请求量都没有挂，凌晨时候星星两两的请求量甚至没有请求却挂了 3、服务准时0点3秒挂，后续我写了个脚本加入执行计划每日凌晨1点检查服务并启动，发现有写脚本的服务还是0点3秒挂而另外一个服务变成1点10几分左右挂了 4、有怀疑可能是logback的问题，日志生成规则是按日期备份的，可是每个客户都是这样的配置就这个客户有问题所以暂时排除这个可能了

1、暂时给几个服务的启动脚本加入到执行计划中每日凌晨检查并启动，没有找到好的解决方案也不知道是什么问题，希望知道的大佬告知一下感激不尽。

附上执行计划检查脚本 @echo off echo 正在检测启动服务…请不要关闭该窗口 D: cd “D:\写上服务的目录” :ks set num=0 for /f %%i in (‘netstat -ano^| find “:服务的端口”’) do set /a num=%num%+1 echo %num% if %num% == 0 ( echo “开始启动服务” call D:\aaa.bat ) else ( echo “无需启动服务” )

其中D:\aaa.bat 是服务的启动脚本 这里也可以直接写上java -jar springboot服务.jar类似这样的代码

经昨晚12点时候录屏服务器后看后终于找到了问题所在，控制台没有丝毫的报错信息直接程序崩溃，这就是windows服务器的不足之处，如果此时服务器是Linux的话 会在项目目录底下记录崩溃的Jvm日志。思考之后发现果真竟然是logback的锅，找到原因： 1、因为logback配置中没有加入maxFileSize的配置，导致日志文件大小有几个G 2、服务器本身性能配置一般 3、logback采用的是zip压缩按日备份的 4、压缩文件是很耗CPU的，文件越大CPU占用越多，如果文件很大就会导致压缩到一半程序崩溃，这里就是出现了这种情况导致压缩到一半没成功，tmp临时文件也没有被删除 5、没有出现该问题的几个客户是因为日志文件都没有达到这种级别的量，其次其他几个客户的服务器性能都是很OK的

解决方法就是在加入maxFileSize配置 建议值是128M。值越大对服务器的性能要求就越高，我这边因为服务器性能一般保险起见设置128M