Docker中JVM CPU占100%但4核各仅25%利用率问题咨询

你的推测完全准确，这个现象是JDK 7无容器感知能力+早期Docker cgroup隔离机制对旧版本程序不兼容共同导致的，具体逻辑如下：

• JDK 7发布时间远早于容器技术大规模落地，完全没有做cgroup资源适配，它的CPU核心数探测逻辑不会读取Docker通过cgroup配置的CPU配额/核心绑定信息，在Docker 17.05的默认cgroup v1环境下，Runtime.getRuntime().availableProcessors()方法会错误返回1。
• JVM内部所有依赖CPU核心数自动配置的参数，都会按照1个核心来初始化：包括并行GC线程数、JIT编译线程数、java.util.concurrent包下ForkJoinPool通用池的默认并行度，很多业务代码里自定义线程池也会取核心数作为参数，最终整个JVM实际只会用到1个核的算力。
• 宿主机看到4个核心各占25%左右，是Linux内核CFS调度器的正常行为：调度器会把总负载为1核的进程时间片均匀分散到所有物理核心上执行，避免单核长期高负载过热，4个核各25%加总刚好就是1核的总算力，和你看到的容器内Java进程100%CPU占用完全对应。

JDK 7永远不会获得容器cgroup感知能力（该特性是在JDK 8u191、JDK 11及之后版本才正式加入的），所以不要指望仅升级Docker就能让JDK自动识别正确核心数，可落地的方案按优先级排序如下：

• 最直接、无兼容问题的方案：启动Spring Boot应用时手动显式指定JVM的并行参数，绕开JDK的自动核心数探测逻辑。如果你给容器分配4核资源，在java启动命令中添加以下参数即可：

  # 强制指定JVM识别到的CPU核心数（JDK7u40及以上版本支持）
  -XX:ActiveProcessorCount=4
  # 手动指定并行GC线程数
  -XX:ParallelGCThreads=4
  # 手动指定CMS/G1并发标记阶段的线程数（如果使用对应GC）
  -XX:ConcGCThreads=2
  # 手动指定ForkJoinPool通用池并行度，覆盖默认配置
  -Djava.util.concurrent.ForkJoinPool.common.parallelism=4
  

  如果你使用的JDK 7小版本过低不支持ActiveProcessorCount参数，额外检查业务代码中自定义线程池的核心数配置，不要直接取availableProcessors()返回值，手动按实际分配的核心数设置即可。
• 升级Docker版本到19.03及以上稳定版后，启动容器时显式添加--cpuset-cpus参数绑定物理核心，例如分配4核时指定--cpuset-cpus=0-3，强制容器进程只能运行在0到3号物理核心上，该场景下JDK 7读取CPU信息时可以正确识别到4个可用核心，不需要额外改太多JVM参数。注意不要只配--cpus=4，该参数是配置CPU配额，JDK 7无法识别该配置，依然会返回1个核心。
• 升级Docker后不要开启cgroup v2，JDK 7完全不兼容cgroup v2的目录结构，会出现更多资源识别异常，保持使用cgroup v1即可。

排查提示：配置完成后可以在应用内加个简单的健康检查接口，返回Runtime.getRuntime().availableProcessors()的值，确认返回值和你分配的核心数一致后，再做后续的性能优化，此时如果再出现CPU瓶颈，再考虑对高耗时逻辑做并行改造。

内容的提问来源于stack exchange，提问作者PabPabPab