有些报错你第一眼看到时完全摸不着头脑docker ps -a里那一行exited(137)就属于这一类。我第一次遇到时第一反应是跑docker logs看容器日志结果干干净净什么都没有。后来才明白137 这个数字根本不是业务日志能解释的它来自 Linux 内核的进程管理机制。这篇文章我就围绕 Docker 的exited(137)展开从退出码的含义、内核层面的触发机制到具体案例的排查流程和处理方案一次性讲透。内容会覆盖宿主机内存不足、容器内存限制、JVM 堆内存设置、docker stop 超时强杀这几个最常见的场景也适合刚接触 Docker 不久、看到exited(137)不知道从哪下手的同学。看完这篇文章你至少能自己定位 80% 的 137 问题并且能给出合理的解决方案。1. 先把137掰开揉碎1289意味着什么1.1 退出码的计算规则为什么是137而不是别的数Linux 下进程退出码有一个约定程序正常退出时返回 0异常退出时返回非 0。如果进程是被信号杀死的Shell 和 Docker 会把它换算成128 信号编号。比如SIGTERM 的编号是 15128 15 143SIGKILL 的编号是 9128 9 137所以退出码 137 在语义上等价于这个进程被 SIGKILL 信号终结了。SIGKILL 是 Linux 里最粗暴的终止方式它不可被捕获、不可被阻塞、也不可被忽略。你可以用kill -l查看系统所有信号编号确认这个对应关系。这个换算规则是理解 137 的第一把钥匙。很多人一看到 137 就去翻应用日志找异常堆栈这是方向性错误。137 不是应用自己抛出的错误码而是内核或外部进程给它下达的死刑判决书。应用本身没有机会写日志、也没有机会做清理操作直接被清走了。1.2 被SIGKILL杀死的容器为什么日志一片空白SIGKILL 的粗暴性决定了被杀的进程没有任何善后机会。正常情况下一个 Java 进程收到 SIGTERM 后可以执行 ShutdownHook把未完成的请求处理完再关掉线程池和连接池然后从容退出。但收到 SIGKILL 时内核直接释放进程占用的资源应用代码连一行日志都来不及写。所以当你看docker logs发现日志停留在某个时间点后面突然什么都没有了就要意识到这可能不是应用崩溃而是进程被外力杀死。这时候去应用日志里找原因基本是白费功夫应该去系统层面找证据。反过来如果日志里留下了 OutOfMemoryError、Segmentation fault 之类的信息那都不属于 137 的排查范畴那是应用自身的问题。1.3 谁能发出SIGKILL四种常见的凶手我实际工作中总结下来137 的凶手基本就这四类凶手触发场景特征内核 OOM Killer宿主机内存耗尽或容器超过 memory limit最常见dmesg 里能看到记录docker stop 超时强杀容器不响应 SIGTERM等待 10 秒后被强制结束CI/CD 里最常见外部 kill -9有人手动 kill 进程或面板/脚本调用查操作记录能发现Docker 引擎重启守护进程重启时部分容器被清理看 Docker 事件能溯源这四类里第一类和第二类占了 95% 以上。下面我会重点展开这两种情况的完整排查链路因为在处理方式上它们是完全不同的方向如果搞混了可能改了很多配置问题依旧。2. 排查链路的第一步第一案发现场在dmesg2.1 OOM Killer是什么挨打的条件是什么OOM Killer 是 Linux 内核的内存保护机制。当系统物理内存和 swap 都用尽时内核无法再满足任何一个进程的内存申请这时候必须杀一个保平安挑选一个进程下手释放它的内存让系统继续运行。内核为每个进程维护一个oom_score分数分数越高被杀的概率越大。正常情况下占用内存越大的进程oom_score越高所以被淘汰的往往是内存大户。在 Docker 场景下一个容器内所有进程共享一个 cgroup如果容器整体内存用量超过了 cgroup 的限制memory.limit_in_bytes内核直接把该 cgroup 标记为 OOM然后杀掉容器里得分最高的进程。这里有个大多数人容易忽略的点OOM Killer 开枪时打中的不一定是内存占用最大的那个进程而是在申请内存那一刻分数最高的进程。所以有时候你发现 MySQL 容器退出 137 了但真正把内存吃满的可能是隔壁 Redis只是 MySQL 恰好在那时又去申请了一块新内存内核就顺手把它给收拾了。2.2 用 dmesg 找证据别靠猜遇到 137我的第一反应永远是执行下面这条命令dmesg | grep -i -E killed process|out of memory|oom-killer | tail -20dmesg 是内核环形缓冲区日志OOM Killer 动手的时候一定会在这里留下记录。输出大概是这样的Out of memory: Killed process 12345 (java) total-vm:4194304kB, anon-rss:1024kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:4096kB oom_score_adj:0如果你用的是 systemd 的系统也可以这样查journalctl -k --since 2025-01-01 00:00:00 | grep -i -E oom|killed process注意dmesg需要 root 权限普通用户执行会报权限错误。还有一点如果容器已经被自动重启了dmesg 里的日志不会消失它依然在那所以这条命令永远是最先执行的。如果 dmesg 里什么都没有那基本可以确定不是 OOM直接看下面的docker inspect。2.3 docker inspect 还原案发时间线不是所有 137 都是 OOM所以在 dmesg 没有发现的情况下我要用docker inspect确认容器的状态字段docker inspect 容器名 --format {{.State.OOMKilled}}这个字段返回true或false它是 Docker 自己记录的 OOM 标记。OOMKilleddmesg 记录结论true有 Killed process 记录确实是内存触发的 OOMfalse无记录大概率是 docker stop 超时或其他外部 kill再结合下面这条查看容器的启动和结束时间docker inspect 容器名 --format {{.State.StartedAt}} - {{.State.FinishedAt}}然后回到宿主机上查看同一时间段的内存变化free -h或者查系统日志cat /var/log/messages | grep -i oom cat /var/log/syslog | grep -i oom把容器被杀的精确时间、宿主机当时的空闲内存、以及有没有 OOM 记录这三条信息拼在一起案发时间线就出来了。这一步做完你基本就能确定到底是被人杀的还是被系统杀的了。3. 我见过的几种137原因各不相同3.1 宿主机内存被写满最常见的死法先讲一个最常见的案例。我之前在一台 2G 内存的小主机上同时运行 MySQL 8.0、Redis 和一个 Spring Boot 应用结果 MySQL 容器每隔一阵就exited(137)但其他容器好好的。当时我第一直觉是 MySQL 配置问题检查了innodb_buffer_pool_size、max_connections全部调低了问题依旧。后来执行dmesg才发现内存紧张的根源根本不是 MySQL而是同一台机器上的 Redis。Redis 默认没有任何内存上限当时有个定时任务往里写了一批大数据把宿主机剩余内存直接吃光。内核 OOM Killer 开枪时恰好 MySQL 正在申请新内存分配于是中弹倒地。这个案例提醒我排查 137 时视角不能只局限在报错容器本身一定要看整个宿主机的内存布局。有时候出问题的容器只是替死鬼真正把内存吃满的是隔壁邻居。排查手段很简单装个htop或者直接看free -h top -o %MEM重点看两点宿主机还剩多少内存是否有某个进程的内存占比异常高3.2 容器自身的memory limit被击穿这种场景比宿主机内存耗尽更隐蔽也更冤。很多人在部署时习惯带上-m参数docker run -m 512m --memory-swap 512m myapp这个命令的意思是容器最多只能用 512M 内存而且禁用了 swap 兜底。超过 512M内核直接杀容器进程不管宿主机内存有多充裕。这类问题的典型特征是宿主机内存明明还有一大半空闲但容器就是反复 137。看docker stats能发现规律——容器的内存使用率逼近 100% 的瞬间容器就退出了。如果你用 docker compose对应配置是这样的services: app: image: myapp mem_limit: 512m memswap_limit: 512m这个memswap_limit的值容易搞混我单独解释一下--memory 512m --memory-swap 512m容器最多 512M且禁用 swap--memory 512m --memory-swap 1g容器最多可用 512M 物理内存 512M swap只设--memory 512m不设 swap容器默认可以无上限使用宿主机的 swap取决于宿主机vm.swappiness这其实很危险后面第 4.4 节会详细说如果你只是感觉容器内存不够但不知道具体峰值是多少可以在容器运行期间跑docker stats观察曲线不要拍脑袋决定 limit 数值。3.3 Java应用与JVM堆的无底洞Java 应用是容器化进程中 137 的高发区而且问题往往出在 JVM 和容器的内存认知不一致。默认情况下JVM 会按照宿主机物理内存的 1/4 来设置堆最大值。如果你在一台 32G 的机器上跑容器给容器设置了-m 1g但 JVM 启动参数里没有显式指定-Xmx那 JVM 会认为可用的堆有 8G32G 的 1/4。当容器内应用实际使用超过 1G 时容器被杀但 JVM 自己还懵然不知。针对这个问题的标准解法是让 JVM 感知容器配额Java 10 及以上默认开启容器感知-XX:UseContainerSupport用-XX:MaxRAMPercentage75.0指定堆占容器内存的百分比Java 8u191需要显式加-XX:UseContainerSupport或者用老参数-XX:UseCGroupMemoryLimitForHeapJava 8 早期版本老老实实写-Xmx512m没有别的捷径我推荐的启动参数组合java -XX:UseContainerSupport -XX:MaxRAMPercentage75.0 -XshowSettings:vm -jar app.jar这里用 75% 而不是 100%是因为 JVM 不只吃堆内存还有 metaspace、线程栈、DirectByteBuffer 这些堆外内存。如果你把堆直接拉满到容器上限堆外内存一旦增长照样会被 OOM。保留 25% 是给堆外内存和系统缓存留的缓冲。3.4 docker stop超时后的kill最容易忽略的假137这个场景我要单独提因为很多人没意识到Docker 部署流程里的 137 可能根本不是内存问题而是docker stop的强杀机制。Docker 执行docker stop时会先向容器内 PID 1 进程发送 SIGTERM然后等待容器优雅退出。默认等待时间是 10 秒也就是 docker CLI 里的-t参数compose 里是stop_grace_period。如果 10 秒内容器没有退出Docker 会发送 SIGKILL强制执行。很多 Java 应用如果没有配置优雅停机或者进程里有长时间运行的任务无法被打断就很容易触发这个超时强杀。此时容器退出码同样是 137但State.OOMKilled是falsedmesg 里也没有任何记录。真实场景在我这边发生过CI 流水线每次构建完执行docker compose down时某个服务总是返回 137每次都要等 10 秒才退出。排查后发现是这个应用在收到 SIGTERM 后没有立即结束Docker 等满 10 秒后只能强杀。解决的思路有两个一是给应用配置优雅停机。Spring Boot 可以开启 graceful shutdownspring: lifecycle: timeout-per-shutdown-phase: 20s server: shutdown: graceful二是在编排层面留足时间services: app: stop_grace_period: 30s两者配合使用CI 流程里的 137 很快就消失了。这个案例说明一个问题遇到 137 先别急着加内存先看OOMKilled字段这个字段能帮你少走很多弯路。3.5 低配置设备上的常驻任务青龙这类脚本容器的典型处境青龙面板在低配设备上跑挂机任务变成 137 的情况也很典型。这类设备内存通常只有 512M 到 2G同时跑着下载工具、监控脚本、Web 服务等一堆容器。青龙每次执行依赖管理和脚本任务时内存峰值会瞬间冲高设备内核直接开枪。这类 137 的教训是小内存设备上跑 Docker首先要降低单容器内存尖峰。青龙这类容器可以在 compose 里限制日志大小避免日志文件占满磁盘分区同时把容器的ulimits内存限制写好services: qinglong: image: whyour/qinglong:latest mem_limit: 512m memswap_limit: 512m logging: driver: json-file options: max-size: 10m max-file: 3同一台设备上如果跑着多个容器建议把所有容器的内存上限加起来低于设备总内存的 80%留出系统本身的开销。小内存设备上不要用硬件的 swap 来救场那只会让 OOM 变成更隐蔽的性能问题后面会单独讲。4. 对症下药从容器参数到应用配置的调整清单4.1 先给容器加显式内存上限limit是底线也是保护排查完根因处理第一步永远是给容器一个明确的内存上限。这一步的意义不只是防止单容器内存失控更重要的是让 OOM Killer 的判决范围可控。为什么这么说如果容器没有 limit它和宿主机其它进程共享整个内存空间。一旦某个进程发生内存泄漏可能连累其它无关容器被杀。而有了 limit内核会在容器内部优先处决最活跃的内存进程不会波及外部。我建议的上限设置原则是单进程实际峰值 30% 余量。比如你观察到应用内存峰值稳定在 400M那么 limit 给 512M 是底线给 1G 更稳妥。给太紧会让系统频繁杀进程给太松又起不到限制作用。以 docker run 为例docker run -d --name myapp -m 1g --memory-swap 1g myapp:latest如果使用 composeservices: myapp: image: myapp:latest mem_limit: 1g memswap_limit: 1g注意memswap_limit和mem_limit相等表示关闭 swap 兜底让容器内存用量严格可控。这是生产环境的标准做法。4.2 Java让JVM感知容器配额Java 应用在容器里的内存参数是我每次部署都要重点检查的部分。经验不丰富的人往往只关心应用代码忽略了 JVM 本身的资源认知这导致很多 Java 容器在 K8s 或 Docker 里无缘无故被杀。第一步确认 Java 版本。Java 8u191 和 Java 10 支持容器感知Java 8 早期版本不支持需要使用-Xmx硬编码。第二步配置合理的堆内存。我推荐用比例而不是固定值这样当容器 limit 调整时不用同步改代码和 Dockerfilejava -XX:UseContainerSupport -XX:MaxRAMPercentage75.0 -Xss512k -jar app.jar这里-Xss512k是把每个线程的栈空间限制在 512K可以避免在创建大量线程时堆外内存过度膨胀。如果你用的是 Java 8 老版本需要这样java -XX:UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction1 -jar app.jar但MaxRAMFraction1意味着用满整个容器内存堆外内存可能没空间所以我更建议老版本直接写成-Xmx600m这种固定值。另外如果你的应用是 Spring Boot可以在application.yml里设置 JVM 参数spring: application: admin: jmx-enabled: true不过这只是辅助最主要的还是启动命令行里的 JVM 参数。4.3 MySQL/Redis调参不是调内存大小是调上限和淘汰策略数据库类容器遇到 137核心原因往往是它们默认值太贪心。MySQL 8.0 安装完默认配置不调在繁忙场景下非常容易吃满内存。这里的重点不是简单地调小内存而是理解每个参数对应的内存池在哪。MySQL 方面我给出的建议[mysqld] innodb_buffer_pool_size 256M max_connections 100 performance_schema OFF max_heap_table_size 64M tmp_table_size 64Minnodb_buffer_pool_size是 MySQL 最大的内存池建议设置为容器 limit 的 50%~60%。max_connections越大内存消耗越线性增长因为每个连接都要分配线程栈和缓冲区。performance_schema在 MySQL 8.0 默认开启它本身就要占用不少内存不是必须时可关闭。Redis 方面重点不是maxmemory设置多大而是设置之后要有淘汰策略maxmemory 256mb maxmemory-policy allkeys-lru如果不设置maxmemory-policy即使触达maxmemoryRedis 只是拒绝写入请求不会淘汰旧数据。但如果你连maxmemory都没设置Redis 就会无限吃内存直到被 OOM Killer 打中。日志、消息队列容器同理建议大家根据实际应用场景把所有常驻容器的内存占用上限都梳理一遍。4.4 swap与overcommit是救场还是帮倒忙swap 在 Docker 场景里是一个需要谨慎使用的选项。很多人以为给系统加 swap 就能避免 137但实际情况比这复杂。Linux 内核默认的vm.swappiness是 60表示内核会积极地把不常用的内存页换到 swap。在容器场景下如果把整个宿主机内存和 swap 都用满OOM Killer 依然会开枪。而且 swap 的存在可能导致系统看起来很卡才被杀排查问题时更难判断。Docker 容器的 swap 策略通过--memory-swap控制。如果你想让容器可以借用宿主机 swap可以这样设置docker run -m 512m --memory-swap 1g myapp这个配置给了容器 512M 物理内存 512M swap 额度。对于内存峰值偶发性的任务型容器这个配置能明显降低被杀概率对于数据库这种对延迟敏感的服务我不建议用 swap因为 swap 的读写延迟会导致查询速度骤降最终引发超时比 137 更难受。如果宿主机内存本身紧张我建议先压容器而不是盲目加 swap。vm.swappiness可以临时调低sysctl vm.swappiness10不过重启会失效想要持久化需要写/etc/sysctl.conf这个操作影响宿主机全局要谨慎。4.5 重启策略能不能兜底很多人遇到容器反复被 137想到的第一招就是加restart: always或restart: unless-stopped让容器被杀后自动拉起。我的看法是这可以作为应急处理但绝不能当作根治手段。restart: unless-stopped的逻辑是容器无论怎么退出只要不是手动 stopDocker 都会自动重启它。对于 OOM 的情况容器被拉起后很可能再次 OOM形成被杀—重启—再被杀的循环不仅服务不可用还在反复消耗系统资源。我见过最极端的例子有个容器一小时重启了 40 多次日志上千条最后连 Docker 守护进程都开始不稳定。所以重启策略的正确使用方式是配合健康检查让容器在内存吞掉后能自动恢复同时在监控层面设置告警及时介入。如果你的服务对可用性要求高推荐用restart: unless-stopped加健康检查比如 compose 里这样services: app: image: myapp mem_limit: 512m restart: unless-stopped healthcheck: test: [CMD, curl, -f, http://localhost:8080/health] interval: 30s timeout: 3s retries: 3但别忘了根本问题还是内存管理重启策略只是止血带。5. 防患于未然让137不再回来的运维习惯5.1 按需监控不用上重武器但要看得见趋势137 发生的瞬间再优秀的排查手段也是事后补救。真正省心的方式是让内存问题的伏笔在爆发前就被看到。如果只是自己的一台或几台服务器没必要上完整的 Prometheus Grafana 全家桶但至少应该把docker stats的数据采集下来。一个非常轻量的做法是写个简单的脚本每分钟把容器内存使用写入日志while true; do echo $(date %Y-%m-%d %H:%M:%S) /var/log/docker-mem.log docker stats --no-stream --format table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}} /var/log/docker-mem.log sleep 60 done这比什么都不做要强太多。当你遇到某个容器半夜被 137醒来才发现的情况时这份日志能帮你精确地还原当时每个容器的内存使用率。如果机器数量多、容器规模大再考虑 cAdvisor Prometheus 这条路。cAdvisor 本身也是个容器它会暴露容器级监控指标配上告警规则可以在容器 OOM 之前提前预警。5.2 评估内存时要看宿主总内存-其他容器占用这一层之前讲过137 的根源经常不在报错容器身上而在邻居容器。为了避免这种冤案我建议每台机器维护一份内存地图每个容器的 limit 是多少、实际峰值是多少、整台宿主机的总内存是多少、系统保留内存预留多少。我习惯在部署新容器前先用公式估算一遍可用内存 宿主机物理内存 - swap - 系统预留(约10%) - 现有所有容器的limit之和如果这个可用内存是负数说明这台机器已经不能再加容器了。这个简单的判断能避免大量部署上的踩坑。5.3 优雅停机这一点比大多数人想的更重要最后聊一个被很多人忽略的问题应用的优雅停机能力。前面讲 docker stop 超时强杀会引发 137它背后真正的问题其实是应用没有处理 SIGTERM 信号。一个健壮的容器应用收到 SIGTERM 后应该做这几件事停止接收新请求处理完正在进行的请求或有限度地等待刷新缓存、关闭连接池、释放资源正常退出让退出码为 0 或 143对于 Spring Boot开启 graceful shutdown 后应用会在收到 SIGTERM 时自动执行上述逻辑server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 30s对于 Node.js 应用可以自己监听信号process.on(SIGTERM, () { server.close(() { process.exit(0); }); });这样处理之后docker stop基本不会触发 SIGKILL退出码会变成 0 或 143不会再有莫名其妙的 137。我现在遇到 137排查顺序已经固定了先看dmesg确认是不是 OOM再看docker inspect的OOMKilled字段然后结合宿主机的内存占用来判断是自身超限还是被邻居连累。这个流程基本不会跑偏。最后想提醒一句如果某个容器反复 137别硬扛先在 compose 里把内存限制和优雅停机写好再考虑是不是要加机器。容器退出可以靠自动重启恢复但被 SIGKILL 打断的数据写操作损失是无法通过重启挽回的。