表述

在一次服務更新后發現每天凌晨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 offecho 正在檢測啟動服務…請不要關閉該窗口D:cd “D:寫上服務的目錄”:ksset num=0for /f %%i in (‘netstat -ano^| find “:服務的端口”’) do set /a num=%num%+1echo %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

補充知識：Springboot啟動即掛掉問題

提示說明端口8080被占用

將端口改為其他端口號即可

以上這篇記一次springboot服務凌晨無故宕機問題的解決就是小編分享給大家的全部內容了，希望能給大家一個參考，也希望大家多多支持好吧啦網。