退出码139表示进程因SIGSEGV（段错误）被强制终止，本质是程序访问非法内存地址，如空指针解引用、越界读写、栈溢出或系统库不兼容，需通过日志、core dump和分层排查定位并修复。
退出码 139 表示容器内主进程因 sigsegv（段错误） 被操作系统强制终止，本质是程序试图访问它无权访问的内存地址——比如解引用空指针、使用已释放的堆内存、数组越界读写、栈溢出，或调用不兼容的系统库函数。这不是配置问题，而是运行时内存安全逻辑被破坏的明确信号。
定位真实崩溃点：别只看容器状态
仅凭 docker ps -a 看到 Exited(139) 远不够。必须拿到第一手崩溃现场：
- 立即执行
docker logs，重点找含Segmentation fault、abort、libc.so.6、core dumped的行； - 若日志为空或只有启动信息，说明崩溃发生在进程初始化极早期（如 JVM 加载、glibc 符号解析阶段），此时要怀疑基础环境兼容性；
- 对支持 core dump 的镜像，可挂载
/proc/sys/kernel/core_pattern并配置保存路径，用gdb /path/to/binary /path/to/core回溯调用栈。
排查三类高频诱因：从环境到代码
段错误常不是孤立 bug，而是多个层叠因素共同触发：
-
系统库与运行时不兼容：老旧 JDK（如 OpenJDK 7/8）搭配新版 glibc（≥2.34）易在
malloc或线程初始化时崩溃；同理，用 Debian 8 镜像跑在较新内核上也可能触发 ABI 不匹配； -
内存资源硬约束引发间接越界：容器设置
mem_limit: 512m但 JVM 启动参数未同步限制堆大小（如未设-Xmx384m），导致 JVM 在尝试分配时触发底层 malloc 失败并 abort； - C/C++ 扩展或 JNI 调用缺陷：Python 的 C 扩展、Node.js 的 native addon、Java 的 JNI 库若存在指针误用或未检查返回值，会在宿主进程上下文中直接引发 SIGSEGV，且错误堆栈常不显示应用层代码。
修复策略需分层落地
不能只改一行代码，要切断从环境到逻辑的错误传导链：
- 升级基础镜像：改用
eclipse-jdk17:jre或tomcat:10-jre17替代tomcat:8-jre8，规避已知 libc/glibc 兼容问题； - 显式约束运行时内存：在启动命令中加入
-Xms256m -Xmx384m -XX:+UseContainerSupport（JVM），或为 Python 设置ulimit -v 4194304（限制虚拟内存 4GB）； - 启用内存安全检测：编译 C/C++ 组件时加
-fsanitize=address,undefined，运行时加ASAN_OPTIONS=detect_leaks=0；对 Go 程序确保使用CGO_ENABLED=1且链接静态 libc； - 验证挂载行为：若容器内应用动态加载 so 文件，检查宿主机挂载的目录权限是否允许
mmap(PROT_EXEC)，必要时加security_opt: ["seccomp=unconfined"]临时排除 seccomp 策略拦截（仅调试用）。
验证是否真正修复
改完不能只看容器“跑起来”，要确认段错误逻辑已被阻断：
- 连续压测 30 分钟以上，观察
docker stats中内存波动是否平滑，无突增后骤降； - 在容器内执行
cat /proc/<pid>/maps | grep '\[heap\]\|rwxp'</pid>，确认堆和可执行内存页权限合理； - 若原崩溃由特定请求触发，构造相同 payload 重放，确认返回 HTTP 200 或预期错误码，而非直接退出。
