1. 问题描述：Java 应用在 Docker 中遭遇内存不足错误
当在 docker 容器中运行 java 应用程序时，例如在 eclipse-temurin:17-jdk 镜像内执行 maven 构建（./mvnw clean package），可能会遇到以下错误信息，导致 java 进程无法启动或正常运行：
[0.002s][warning][os,thread] Failed to start thread "GC Thread#0" - pthread_create failed (EPERM) for attributes: stacksize: 1024k, guardsize: 4k, detached. # # There is insufficient memory for the Java Runtime Environment to continue. # Cannot create worker GC thread. Out of system resources. # An error report file with more information is saved as: # /home/myuser/hs_err_pid8.log
伴随此错误，系统会生成一个 hs_err_pidX.log 文件，其中包含更详细的信息，进一步强调了“内存不足”和“无法创建工作 GC 线程”：
# There is insufficient memory for the Java Runtime Environment to continue. # Cannot create worker GC thread. Out of system resources. # Possible reasons: # The system is out of physical RAM or swap space # The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap # ... (其他可能的解决方案，如减少 Java 堆大小、线程数等)
尽管错误信息明确指出“内存不足”，但实际情况可能是容器或宿主机拥有足够的物理内存和交换空间，并且 Java 堆配置也合理。这表明问题可能并非简单的内存耗尽。
2. 根本原因分析：seccomp 安全限制
在许多情况下，上述“内存不足”错误并非真正的物理内存不足，而是 Docker 容器的默认 seccomp（Secure Computing Mode）安全配置文件限制了 Java 虚拟机（JVM）所需的某些系统调用。
seccomp 是 Linux 内核的一项安全特性，允许进程限制自身可以执行的系统调用。Docker 默认会为容器应用一个 seccomp 配置文件，该文件旨在提高容器的安全性，通过阻止容器执行潜在危险的系统调用。然而，某些情况下，这个默认配置文件可能会过于严格，以至于阻止了 JVM 在内部创建线程（如 GC 线程）所需的 pthread_create 等系统调用。当 JVM 尝试执行这些被禁止的系统调用时，操作系统会返回 EPERM（Operation not permitted）错误，而 JVM 内部将其解释为“资源不足”或“内存不足”，因为它无法完成线程创建操作。
立即学习“Java免费学习笔记（深入）”；
3. 解决方案：调整 Docker seccomp 安全配置
解决此问题的最直接方法是在运行 Docker 容器时，通过 --security-opt seccomp=unconfined 参数来禁用或放宽默认的 seccomp 限制。unconfined 选项意味着容器将以与宿主机相同的系统调用权限运行，不再受 seccomp 配置文件的限制。
示例代码：
将以下参数添加到您的 docker run 命令中：
docker run --security-opt seccomp=unconfined -it eclipse-temurin:17-jdk bash -c "./mvnw clean package"
或者，如果您是交互式进入容器：
docker run --security-opt seccomp=unconfined -it eclipse-temurin:17-jdk bash # 然后在容器内部执行： # ./mvnw clean package
解决方案解释：
通过添加 --security-opt seccomp=unconfined，您实际上是在告诉 Docker 运行时，不要对该容器应用默认的 seccomp 配置文件。这使得 JVM 能够执行其内部线程创建所需的 pthread_create 等系统调用，从而避免了 EPERM 错误，并允许 GC 线程正常启动，进而解决了“内存不足”的问题。
4. 注意事项与安全考量
- 安全风险： 使用 --security-opt seccomp=unconfined 会放宽容器的安全限制，使得容器可以执行更多的系统调用，从而增加了潜在的安全风险。在生产环境中，应谨慎使用此选项。理想情况下，应该创建一个自定义的 seccomp 配置文件，只允许 JVM 正常运行所需的最小系统调用集，而不是完全禁用 seccomp。
- 验证实际内存： 在应用 seccomp 解决方案之前，务必确认容器或宿主机确实有足够的内存资源。您可以通过 docker stats 命令监控容器的内存使用情况，或检查宿主机的内存和交换空间状态。如果实际内存确实不足，那么即使放宽 seccomp 限制也无济于事，您需要增加容器的内存限制（例如使用 -m 参数）或宿主机的物理内存。
- JVM 内存参数： 错误日志中提到的 JVM 内存参数（如 -Xmx、-Xms、-Xss）仍然是优化 Java 应用内存使用的重要手段。如果 seccomp 并非根本原因，或者在解决 seccomp 问题后仍遇到内存问题，则应考虑调整这些 JVM 参数。
- Java 版本： 不同的 Java 版本对系统调用的需求可能略有差异。本教程基于 eclipse-temurin:17-jdk 镜像，但原理适用于其他 OpenJDK 版本。
5. 总结
当在 Docker 容器中运行 Java 应用程序时，遇到“GC 线程创建失败”导致的“内存不足”错误，尽管错误信息指向内存，但一个常见的隐性原因可能是 Docker 默认的 seccomp 安全配置文件过于严格，阻止了 JVM 必要的系统调用。通过在 docker run 命令中添加 --security-opt seccomp=unconfined 参数，可以有效解决此问题。然而，出于安全考虑，在生产环境中使用此选项时应格外谨慎，并优先考虑创建更精细的自定义 seccomp 配置文件。同时，也应排除真正的内存资源不足或 JVM 内存配置不当的可能性。
