Spring Boot 1.5.9.RELEASE应用随机重启（含Tomcat启动日志）求助

你已经排除了devtools、JMX远程调用、手动触发/refresh这几个常见的重启触发点，还只用了Spring Cloud Config，却依然出现1小时内甚至3分钟内的随机重启，结合你提供的日志，咱们可以从以下几个方向逐一排查：

一、排查Spring Cloud Config的自动刷新逻辑 #

虽然你没手动调用/refresh，但Spring Cloud Config客户端可能存在隐蔽的自动刷新触发机制：

• 检查是否无意间开启了配置自动刷新的触发器：比如Config Server配置了Git仓库的Webhook，当配置仓库有变更时会主动推送刷新信号到客户端，部分场景下可能触发上下文的重建甚至应用重启；可以查看Config Server的日志，确认是否有频繁的配置变更推送记录
• 检查依赖是否引入了消息总线组件：比如spring-cloud-starter-bus-amqp或spring-cloud-starter-bus-kafka，这类组件默认可能会监听配置变更事件，即使没做完整配置，也可能触发异常的刷新行为
• 查看客户端配置：是否设置了spring.cloud.config.refreshable参数，或者自定义了RefreshScope的相关逻辑，导致某些Bean的刷新触发了连锁反应，最终引发应用重启

二、排查JVM或系统层面的进程终止问题 #

应用突然重启，很大概率是JVM进程被终止了，这时候要查系统和JVM的日志：

• 检查服务器的系统日志（比如Linux的/var/log/messages、dmesg），看是否有OOM Killer的记录——当系统内存不足时，Linux会自动杀掉占用内存最高的进程，这是非常常见的应用突然消失的原因
• 查看应用目录下是否生成了hs_err_pidXXX.log文件，这是JVM崩溃时生成的错误日志，里面会记录崩溃的具体原因（比如内存溢出、栈溢出、JNI调用错误等）
• 检查应用的启动参数，是否配置了-XX:OnOutOfMemoryError这类参数，导致JVM在OOM时自动执行重启脚本

三、排查部署环境的自动重启机制 #

如果是容器化部署或者在云平台运行，环境本身的策略可能导致应用重启：

• 检查容器的健康检查配置：比如Docker的HEALTHCHECK或者K8s的存活探针/就绪探针，是否阈值设置过低（比如响应时间超过几秒就判定不健康），导致应用偶尔响应慢就被重启
• 查看资源限制：容器的CPU、内存配额是否被打满，触发了平台的重启机制
• 云平台的自动伸缩或实例替换：部分云平台会定期替换实例，或者在实例出现异常时自动重建，这也会导致应用看起来是随机重启

四、检查应用内部的致命逻辑 #

从你提供的重启前日志来看，有几个线程池的日志输出：

2018-05-28 09:50:43.108 INFO [pool-3-thread-3] myclass1 : myMessage1
2018-05-28 09:50:43.112 INFO [pool-2-thread-2] myclass2 : myMessage2
2018-05-28 09:50:43.118 INFO [pool-1-thread-3] myclass3 : myMessage3

这几个线程处理的任务可能存在问题：

• 检查myclass1、myclass2、myclass3的代码，是否有调用System.exit()或Runtime.getRuntime().exit()的逻辑——这类代码会直接终止JVM进程，导致应用重启
• 排查这些线程的任务是否有未捕获的致命异常，虽然一般未捕获异常只会终止单个线程，但如果线程池的拒绝策略设置不当（比如直接抛出异常导致线程池崩溃），或者异常触发了整个应用的上下文关闭逻辑，也可能引发重启
• 检查是否有第三方库在执行任务时触发了进程退出的操作

五、排查Spring Boot上下文的异常刷新 #

• 检查应用中是否有自定义的ApplicationListener、CommandLineRunner或ApplicationRunner组件，是否存在逻辑错误，比如误调用了ApplicationContext.refresh()方法——这个方法会触发整个Spring上下文的重启，如果被错误触发，就会导致应用重启
• 开启Spring Boot的Debug日志，重点监控org.springframework.context和org.springframework.cloud.config包的日志，查看重启前是否有上下文关闭、刷新的相关日志，这能帮你定位到触发重启的具体触发点

六、检查依赖冲突问题 #

Spring Boot 1.5.9.RELEASE对应的Spring Cloud版本是Edgware.SR3，版本不匹配很容易引发异常：

• 用mvn dependency:tree（Maven）或gradle dependencies（Gradle）生成依赖树，检查是否有不同版本的Spring Boot、Spring Cloud组件共存，或者引入了与1.5.x版本不兼容的第三方库（比如新版本的数据库驱动、缓存框架等）
• 排查是否有依赖重复引入的情况，导致类加载异常，进而触发应用重启

额外的日志排查建议 #

为了更精准定位问题，你可以添加这些日志配置：

• 开启JVM的GC日志：添加启动参数-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log，查看是否有频繁GC或内存不足的情况
• 增加Spring Boot的日志级别：在application.properties中设置logging.level.org.springframework.context=DEBUG和logging.level.org.springframework.cloud.config=DEBUG，记录上下文的刷新和关闭过程
• 用进程监控工具（比如top、htop）实时监控应用的CPU、内存占用，看重启前是否有异常波动

内容的提问来源于stack exchange，提问作者2011