在 aws ecs 中，java 进程退出是否触发容器重启，取决于任务运行模式：作为 service 运行时会自动重建任务并拉起新容器；作为一次性 task 运行则不会自动恢复。
在 aws ecs 中，java 进程退出是否触发容器重启，取决于任务运行模式：作为 service 运行时会自动重建任务并拉起新容器；作为一次性 task 运行则不会自动恢复。
Amazon ECS 本身不直接监控或重启容器内进程（如 java -jar app.jar），而是以任务（Task）为最小调度与生命周期管理单元。容器的“重启”行为实际体现为：当容器退出（无论因 JVM 崩溃、OOM Killer 终止、未捕获异常退出，还是显式调用 System.exit()），其所属的 ECS 任务状态变为 STOPPED；后续是否启动新任务，完全由上层编排策略决定。
✅ Service 模式（推荐用于长期服务）
当你将任务定义注册为 ECS Service（通过 Application Load Balancer 或无负载均衡器方式部署），ECS 会持续维持指定数量的运行中任务（即 desiredCount）。一旦容器退出导致任务停止，Service 调度器会在数秒内检测到偏差，并自动启动一个全新任务——包括拉取镜像、创建新容器、执行相同 ENTRYPOINT。这意味着你的 Java 应用具备高可用性保障。
示例 Service 配置片段（CloudFormation / CDK / Console）：
Service:
Type: AWS::ECS::Service
Properties:
DesiredCount: 2
LaunchType: FARGATE
TaskDefinition: !Ref MyTaskDef
# 启用健康检查和自动恢复的关键配置
HealthCheckGracePeriodSeconds: 30⚠️ Standalone Task 模式（适用于批处理、一次性作业）
若仅通过 RunTask API 或 CLI 提交单个任务（例如 aws ecs run-task --task-definition my-app），ECS 将不会主动干预。任务停止即终止，无重试、无替换。此时需自行实现重试逻辑（如通过 EventBridge 捕获 TASK_STOPPED 事件 + Lambda 触发重跑）。
? 关键注意事项：
- 容器退出码影响可观测性：建议在 Java 应用中统一处理异常并返回有意义的退出码（如
System.exit(1)表示业务错误，137表示被 OOM Kill），便于 CloudWatch Logs 和 ECS Events 分析； - JVM 内存配置需匹配容器内存限制：
-Xmx600m必须显著小于容器内存上限（如设为 1GB），否则易触发 Linux OOM Killer 强制终止进程，表现为非预期退出； - 不要依赖
restart: always（Docker Compose 语义）：ECS 不支持 Docker 原生 restart policy，该字段在 task definition 中被忽略； - 健康检查增强容错：配合 ECS Service 的
HealthCheckGracePeriodSeconds与 ALB 健康检查，可避免将未就绪的 Java 应用实例纳入流量。
总结：ECS 的“自动恢复”本质是 Service 层的任务级编排能力，而非容器进程级守护。将 Java 应用部署为 ECS Service，是实现生产环境自愈能力的标准实践。
立即学习“Java免费学习笔记（深入）”；
