Spring Boot部署AWS Elastic Beanstalk时长任务无异常中断未完成问题

问题根因排查方向 #

一、AWS Elastic Beanstalk平台侧可能原因 #

• 自动扩缩容/实例替换触发：Elastic Beanstalk的自动扩缩容策略如果配置了基于CPU、内存、请求数的阈值，当长任务运行占用过高资源时，会触发不健康实例判定被回收，或者缩容时直接终止运行中的实例，进程被强制杀死自然不会抛出应用层异常。另外EB的健康检查如果是HTTP类型，长任务占满线程池导致健康接口超时，也会被判定为不健康实例被替换。
• 部署触发实例替换：如果开启了自动部署，新代码发布时旧实例会被终止，刚好运行到长任务的实例就会被强制关闭。
• 虚拟机资源耗尽：EC2实例内存不足触发OOM Killer直接杀掉Java进程，或者CPU被占满导致进程被操作系统挂起后长时间无响应被EB回收。

二、应用代码侧隐藏问题 #

从你提供的代码来看，存在几个容易被忽略的坑，也可能导致你观察到的无异常中断现象：

• doUploadOneOfMultipleImages方法内部捕获了所有Exception后仅返回0，没有打印任何异常日志：如果S3上传、图片处理过程中抛出异常，上层for循环根本感知不到异常发生，也不会触发catch分支的日志打印，仅会统计为上传失败，看起来就像循环提前终止无报错。
• S3客户端未配置超时规则：如果使用默认的S3客户端配置，没有设置socket超时、请求超时，遇到网络波动时putObject请求会无限阻塞，看起来就像循环停在某一步，既不抛出异常也不往下执行。
• 长任务绑定HTTP请求线程：如果当前长任务是同步绑定在HTTP请求线程上运行的，Elastic Beanstalk的负载均衡、反向代理都有默认的请求超时阈值（通常为60s/300s），超时后连接被断开、请求线程被销毁，任务自然中断，也不会生成异常日志。
• 图片处理异常被静默丢弃：ImageIO.read如果读取到非合法格式的图片文件会返回null，后续ImageIO.write操作会抛出IllegalArgumentException，但这个异常会被doUploadOneOfMultipleImages的catch分支直接吃掉，没有日志输出你也无法感知到这一步的异常。

排查验证方案 #

• 优先查看Elastic Beanstalk事件日志和EC2实例生命周期事件，确认任务中断的时间点是否存在实例终止、扩缩容、健康检查失败、新代码部署的记录，可直接定位是否为平台侧操作导致的问题。
• 查看EC2实例的系统日志和CloudWatch指标，核对中断时间点的CPU、内存、磁盘IO使用率，检查是否存在OOM相关的日志记录，即可确认是否是虚拟机资源不足导致的进程终止。
• 补全代码日志：在doUploadOneOfMultipleImages的catch分支添加异常堆栈打印，同时在for循环每次迭代结束后打印当前上传进度，确认循环是直接终止还是阻塞在某一步操作上。
• 给S3客户端添加显式超时配置：初始化S3Client时配置overrideConfiguration，设置apiCallTimeout、apiCallAttemptTimeout，避免请求无限阻塞。

优化修复建议 #

• 长任务异步解耦：不要将长任务绑定在HTTP请求线程上，使用Spring Task或者专业的任务调度框架，也可以将任务提交到SQS队列由单独的Worker进程处理，避免请求超时导致任务中断。
• 配置EB实例保护：对于运行长任务的实例，可以开启缩容保护，避免自动扩缩容过程中被意外终止。
• 增加任务断点续跑能力：将任务执行进度持久化到数据库/Redis中，任务中断后重启可从上次执行的位置继续运行，无需从头执行。

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