容器启动失败：JRE内存不足无法创建GC线程问题排查

以下是常规内存扩容、JVM参数调整之外的高概率根因排查点，按优先级从高到低排序：

1. 优先排查cgroup/容器层面的资源配额限制 #

你当前通过free看到的是宿主机全局可用内存，但容器启动时的资源申请受cgroup配额约束，宿主机内存再充足，配额不足一样会触发创建GC线程失败的报错：

• 检查故障容器的内存配额：执行cat /sys/fs/cgroup/memory/docker/<替换为故障容器ID>/memory.limit_in_bytes，确认配额值大于JVM堆+元空间+线程栈+本地内存的总预留值
• 检查容器PID/线程数配额：执行cat /sys/fs/cgroup/pids/docker/<替换为故障容器ID>/pids.max，创建GC线程失败本质是native线程创建失败，PID配额打满时的报错和内存不足完全一致，属于最高发漏查项
• 检查Docker daemon全局默认限制：执行docker info | grep -iE "pids|memory|limit"，确认默认PID限制、默认内存限制没有被配置为过小的值
• 检查systemd对Docker服务的资源约束：执行systemctl show docker --property=TasksMax,MemoryLimit,LimitNPROC，如果TasksMax配置过低，Docker服务总线程数触顶后，哪怕单个容器没配限制也无法创建新线程

2. 排查旧版Java 8的容器资源感知Bug #

Java 8 191之前的版本默认没有开启cgroup资源感知能力，JVM启动时会直接读取宿主机的硬件配置计算GC线程数、内存预留值，不会感知容器的配额限制：

• 先在容器内执行java -version确认JDK小版本，如果版本低于8u191，会默认按宿主机CPU核数计算ParallelGCThreads数量——如果你的故障机是16核，JVM默认会开十余个GC线程，每个线程默认占1M栈空间，叠加cgroup内存限制很容易直接触发资源不足
• 临时修复可以在JVM启动参数中添加如下配置，强制JVM感知容器资源、手动控制GC线程数：

-XX:+UseCGroupMemoryLimitForHeap
-XX:MaxRAMFraction=2
-XX:ParallelGCThreads=2
-XX:ConcGCThreads=1

如果是8u131之前的版本，根本没有cgroup感知相关参数，直接升级JDK基础镜像到8u191以上版本即可

3. 排查宿主机内核参数限制 #

内存剩余充足但无法创建线程/申请内存时，内核参数配置错误是常见诱因：

• 执行如下命令核对关键内核参数：

sysctl vm.max_map_count
sysctl kernel.threads-max
sysctl kernel.pid_max
ulimit -u

• 重点关注vm.max_map_count值：默认值65530仅能满足轻量应用运行，跑Java应用建议调整到262144以上，该值过低时JVM内存映射失败会直接抛出内存不足报错
• 确认kernel.threads-max、kernel.pid_max没有被安全加固脚本改小，避免宿主机全局线程/进程数触顶

4. 排查安全模块拦截 #

两台服务器配置一致但单台出问题，大概率是上次流水线更新时故障机自动打了安全补丁，更新了AppArmor/SELinux规则，拦截了容器内进程的线程创建、内存锁定操作：

• 临时执行setenforce 0将SELinux切换为宽容模式，重启容器验证是否恢复，如果恢复则排查SELinux规则中对Docker进程的权限限制
• 执行aa-status确认AppArmor运行状态，在/var/log/audit/audit.log或/var/log/auth.log中搜索denied关键字，确认是否存在针对catalina进程的权限拦截记录

5. 排查镜像与存储驱动异常 #

• 流水线构建后故障机拉取镜像时可能出现镜像层损坏，虽然容器可以执行启动命令，但JVM加载核心类库或本地依赖时失败，会误报内存不足。可以删除故障机本地的问题镜像，重新从仓库拉取最新镜像验证
• 对比两台服务器docker info输出中的Storage Driver配置，确认故障机没有使用devicemapper等过时存储驱动，同时检查存储池剩余空间，避免存储层写入失败触发资源不足报错

内容的提问来源于stack exchange，提问作者Master.Aurora