部署于Azure App Service的Spring Boot应用持续重启问题排查及启动时长延长方法咨询
我之前碰到过好几个类似的Spring Boot部署Azure App Service频繁重启的案例，结合经验给你梳理下排查方向和临时解决办法：
首先，既然嵌入式Tomcat和Spring的日志没发现异常，那得把目光转向Azure平台层面和系统级的日志，还有一些容易忽略的启动细节：
Azure平台日志与诊断工具
- 先看Web Server Logs：如果是IIS托管，打开Kudu控制台（
https://<your-app-name>.scm.azurewebsites.net），进入Log Files->W3SVCxxxx目录查看IIS请求日志，同时检查HttpErr日志，看看有没有端口占用、请求超时导致的进程终止记录。另外，Kudu的Deployment页面能看到部署过程中有没有脚本执行失败、文件复制异常，这些都可能触发重启。 - 用App Service Diagnostics：在Azure门户的App Service页面，左侧菜单的“诊断并解决问题”里，“可用性和性能”分类下的指标能帮你看到重启前CPU、内存、磁盘IO的波动——比如内存突然占满被系统OOM杀死，或者CPU持续100%导致进程被强制重启。
- 检查Kudu的Process Explorer：在Kudu的
Processes页面，能看到进程的启动时间、PID变化，还能查看每个进程的终止原因，有没有Windows系统发出的TerminateProcess指令触发的重启。
- 先看Web Server Logs：如果是IIS托管，打开Kudu控制台（
Windows系统级日志
通过Kudu的Tools->Event Viewer，查看Application和System日志：比如有没有Application Error事件（ID 1000），记录了Java进程意外终止的具体原因；或者Service Control Manager的事件，有没有服务被强制停止的记录。这些都是应用日志里看不到的系统层面触发的重启信号。Spring Boot启动细节追踪
虽然你说Spring日志没异常，但可以加更细粒度的日志定位瓶颈：- 开启
logging.level.org.springframework.boot.autoconfigure=DEBUG，记录自动配置的每一步，看有没有某个配置项反复重试（比如数据库连接失败重试，导致启动超时）。 - 给自定义的初始化Bean、监听器加日志，记录每个步骤的开始和结束时间，比如在
ApplicationListener<ApplicationReadyEvent>里加耗时统计，排查哪一步卡住了。 - 启用Spring Boot Actuator的
/startup端点（需要依赖spring-boot-starter-actuator并暴露端点），能看到启动阶段每个Bean的加载耗时，精准找到瓶颈环节。
- 开启
启动脚本与配置
检查你的Startup Command或者自定义启动脚本：如果用了startup.cmd之类的脚本，有没有循环逻辑、错误判断缺失，导致脚本反复重启应用？比如脚本里检测到某个服务没起来就重启，形成死循环。
在不清楚重启原因的情况下，先试试这些方法来给启动“争取时间”：
调整启动超时时间
在Azure门户的App Service -> Configuration -> General settings里，找到“Startup timeout”选项，默认是230秒，你可以改成最大的1800秒（30分钟）。这样单次启动有足够时间完成，不会因为Azure认为启动超时而杀死进程，减少不必要的重启次数。升级App Service Plan层级
如果你的应用用的是Free/Basic层，资源有限（比如CPU、内存不足），启动时容易因为资源瓶颈触发重启。升级到Standard或Premium层，获得更多的计算资源，能显著减少启动时的资源竞争问题。拆分非核心启动任务
把一些不影响应用核心功能的初始化工作（比如数据预热、缓存加载）放到异步线程里执行：用@Async注解标记这些方法，或者实现ApplicationListener<ApplicationStartedEvent>，在应用启动完成后再后台执行。这样能缩短启动阶段的耗时，避免触发超时重启。使用部署槽预热
创建一个Staging部署槽，先在槽里部署应用，等它完全启动并预热完成后，再切换到生产槽。这样生产槽的启动是基于已经预热好的实例，不会有长时间的启动等待，也避免了生产环境的频繁重启。启用Always On
在App Service的Configuration -> General settings里开启“Always On”，虽然它主要是防止应用空闲超时，但也能让Azure更积极地维持应用进程，减少因为长时间无响应被系统回收的概率。
内容的提问来源于stack exchange，提问作者Ant
