拓冰网站定制 
开发工具可观测性后端【免费下载链接】vjtoolsThe vip.coms java coding standard, libraries and tools项目地址https://gitcode.com/gh_mirrors/vj/vjtools点击查看免费下载容器中的 JVM 默认通过sysconf(_SC_NPROCESSORS_CONF)读取宿主机的 CPU 核数导致 GC 线程数、Netty 线程数等按宿主机规模配置造成线程泛滥与资源争抢。本文以唯品会开源项目 vjtools 中vjstar模块的 docker-cpus 方案 为核心讲解基于 libsysconfcpus 的通用补丁原理、镜像编译步骤与启动脚本改造方法并给出-server模式下的 2 核下限等关键注意事项帮助你在任何 JDK 版本上为容器 JVM 注入真实 CPU 配额。问题背景容器里 JVM 看到的核数为什么是假的Docker 容器通过--cpus或cpuset限制进程可用的 CPU但 JVM 在启动时并不读取容器的 cgroup 配额而是直接调用操作系统接口sysconf(_SC_NPROCESSORS_CONF)获取系统配置的处理器数量。在宿主机上部署多个容器时这个返回值是宿主机的总核数而非容器被分配到的核数。这个误差会沿 JVM 的运行时参数一路放大GC 线程数Parallel GC / CMS 默认按CPU核数 * 5/8计算并行线程数多余线程造成无谓的上下文切换Netty 等框架的默认线程数如 Netty 的 EventLoop 默认按2 * CPU核数创建线程数虚高直接拉高内存占用ForkJoinPool 公共池、定时线程池等均以Runtime.availableProcessors()为基准同样失真。官方修复并不覆盖所有版本。vjstar模块在 vjstar/README.md 中明确指出据说 JDK8 的最新版解决了这个问题但其他版本的 JDK 则建议使用此补丁。 因此唯品会vip.com在生产上采用基于 libsysconfcpus 的方案为各个版本的 JDK 提供一个通用解决方案。补丁原理LD_PRELOAD 截获 sysconf 系统调用libsysconfcpus.so 的原理非常精巧它利用 Linux 动态链接器的LD_PRELOAD机制抢先加载一个同名的sysconf函数实现从而截获 JVM 获取 CPU 核数所用的系统调用sysconf(_SC_NPROCESSORS_CONF)将其返回值改为读取环境变量LIBSYSCONFCPUS。整体调用链如下JVM 启动 └─ Runtime.availableProcessors() └─ sysconf(_SC_NPROCESSORS_CONF) ← 被 LD_PRELOAD 的 libsysconfcpus.so 截获 └─ 返回环境变量 LIBSYSCONFCPUS 的值而非宿主机核数只要在 JVM 进程启动前设置好两个环境变量整个过程对应用代码完全透明LIBSYSCONFCPUS告诉截获层容器实际分到了几个核LD_PRELOAD指向编译好的libsysconfcpus.so且必须放在最前面保证它优先于其他库被加载。第一步编译 libsysconfcpus.so 并放入镜像从 libsysconfcpus 项目获取源码并编译出共享库这一步通常在构建镜像时完成git clone libsysconfcpus 项目地址 cd libsysconfcpus make # 产物为 libsysconfcpus.so将编译产物安装到镜像的标准路径例如/usr/local/lib/libsysconfcpus.so。后续脚本中的LD_PRELOAD路径需与此保持一致。若你的基础镜像缺少编译工具链应尽量在构建阶段编译完成后再将 so 文件单独拷贝进运行镜像避免在运行镜像中保留编译环境。第二步编写启动脚本并注入环境变量vjstar仓库在 vjstar/src/main/script/docker-cpus 目录下给出了可直接套用的启动脚本。脚本完成两件事定义环境变量LD_PRELOAD把libsysconfcpus.so放在最前面达到截获的目的读取容器平台注入的 CPU 核数环境变量转换为 libsysconfcpus 所需的LIBSYSCONFCPUS。脚本原文以仓库为准#!/bin/sh if [ x$CONTAINER_CORE_REQUEST ! x ]; then LIBSYSCONFCPUS$CONTAINER_CORE_REQUEST if [ ${LIBSYSCONFCPUS} -lt 2 ]; then LIBSYSCONFCPUS2 fi export LIBSYSCONFCPUS fi export LD_PRELOAD/usr/local/lib/libsysconfcpus.so:$LD_PRELOAD逐行解读脚本片段作用if [ x$CONTAINER_CORE_REQUEST ! x ]; then判断容器平台是否注入了核数环境变量。x前缀是 POSIX Shell 防止变量为空时产生语法歧义的惯用写法LIBSYSCONFCPUS$CONTAINER_CORE_REQUEST把容器分配的核数转交给 libsysconfcpus 读取的环境变量if [ ${LIBSYSCONFCPUS} -lt 2 ]; then LIBSYSCONFCPUS2; fi强制核数下限为 2规避-server模式启动死锁问题见下文export LD_PRELOAD/usr/local/lib/libsysconfcpus.so:$LD_PRELOAD将 so 文件置于LD_PRELOAD最前面并保留原有项确保截获优先生效关于环境变量命名的两个说明原文档中提到部署容器时会额外传入一个环境变量CONTAINER_CORE_LIMIT代表分配的 CPU 核数而仓库脚本实际读取的是CONTAINER_CORE_REQUEST。两者并不一致使用时需按自己的情况修改如果你的容器平台注入的是CONTAINER_CORE_LIMIT或 Kubernetes 的resources.limits.cpu换算值请把脚本中的变量名替换为对应名称。若容器平台未注入任何核数环境变量LIBSYSCONFCPUS不会被设置此时 libsysconfcpus 将退化为透传真实的sysconf返回值不会破坏原有行为。关键警告-server模式至少需要 2 核原文档特别强调当 JVM 以-server启动时至少需要 2 核否则在启动时会被死锁。这正是脚本中LIBSYSCONFCPUS2下限存在的原因——即使容器只分配了 1 核也要向 JVM 报告 2 核避免服务器模式下线程与优化逻辑不足导致启动卡死。这个下限建议在生产环境保持默认不要随意下调。第三步与 JVM 启动参数脚本集成vjstar模块同时提供了完整的 JVM 启动参数推荐脚本。集成时将上述 docker-cpus 脚本与 jvm-options.sh 一起引入应用启动流程# 1. 先执行 docker-cpus 脚本完成 LD_PRELOAD 与 LIBSYSCONFCPUS 注入 source ./docker-cpus.sh # 2. 再加载 JVM 参数推荐脚本内部会按 JDK 版本自动适配 source ./jvm-options.sh # 3. 使用输出的 JAVA_OPTS 启动应用 java $JAVA_OPTS -jar your-app.jar值得留意的是jvm-options.sh 中有一条与容器 CPU 感知直接相关的注释如果 JVM 并不独占机器机器上有其他较繁忙的进程在运行将 GC 线程数设置得比默认值CPU核数5/8更低以减少竞争反而会大大加快 YGC 速度。在容器场景下这恰好印证了 CPU 核数失真会传导到 GC 线程数的论断——补丁修正核数后GC 线程数才会按容器配额计算而多容器共享宿主机时仍可按需进一步手工压低-XX:ParallelGCThreads与-XX:ConcGCThreads。验证补丁是否生效补丁注入后可通过以下方式验证1. 检查进程环境变量# 查看 JVM 进程的 LD_PRELOAD 与 LIBSYSCONFCPUS cat /proc/pid/environ | tr \0 \n | grep -E LD_PRELOAD|LIBSYSCONFCPUS2. 观察 JVM 实际感知的核数jinfo -flag PrintFlagsFinal pid 2/dev/null | grep -E ActiveProcessorCount # 或直接通过 JMX # java.lang.management.OperatingSystemMXBean.getAvailableProcessors()3. 观察 GC 线程数是否符合预期jinfo -flag ParallelGCThreads pid若补丁未生效优先检查so 文件路径是否与LD_PRELOAD一致、LD_PRELOAD是否被后续脚本覆盖应使用追加而非覆盖、以及环境变量注入是否发生在 JVM 进程启动之前。与 vjstar 其他最佳实践的配合docker-cpus 补丁只是 vjstar 模块服务化应用性能与可用性最佳实践的一部分它与其他实践共同构成容器化 JVM 的完整治理方案JVM 启动参数见 jvm-options.sh涵盖内存、GC、日志、排查与 JMX 等全量参数按 JDK 版本自动适配闲时主动 GC见 ProactiveGcTask.java 与 CleanUpScheduler.java在夜半闲时检测老生代占用达到阈值如 50%后主动触发一次 CMS GC通过随机时延避免所有实例同时清理对应的可运行示例见 ProactiveGcTaskDemo.java滑动窗口计数器见 RequestSlidingWindow.java用于任意时刻最近一分钟请求数统计、熔断计算等场景。小结容器中 JVM 读取宿主机 CPU 核数是容器化迁移的常见坑。唯品会在vjstar中沉淀的 docker-cpus 补丁以LD_PRELOAD截获sysconf(_SC_NPROCESSORS_CONF)的方式在不修改应用代码、不依赖特定 JDK 版本的前提下为 JVM 注入真实核数配合-server模式至少 2 核的下限保护可以安全地用于生产环境。完整脚本与配套的 JVM 参数最佳实践均可在仓库的 vjstar/src/main/script/docker-cpus/README.md 与 vjstar 模块中直接查阅与复用。赞分享开发工具可观测性后端【免费下载链接】vjtoolsThe vip.coms java coding standard, libraries and tools项目地址https://gitcode.com/gh_mirrors/vj/vjtools点击查看免费下载相关推荐MEGAcmd开发者指南理解架构、编译源码与贡献代码MEGAcmd开发者指南理解架构、编译源码与贡献代码 MEGAcmd是一款功能强大的命令行交互和脚本应用专为访问MEGA云存储服务设计。本指南将帮助开发者深vjstar 服务化应用性能与可用性最佳实践JVM 参数、容器 CPU 识别、闲时主动 GC 与滑动窗口计数器全解析vjstar 服务化应用性能与可用性最佳实践JVM 参数、容器 CPU 识别、闲时主动 GC 与滑动窗口计数器全解析 vjstar 是 vjtools 仓库中开发工具可观测性后端上一篇告别手动操作github-release 一键搞定 GitHub Releases 全流程下一篇CardKit部署指南在Web应用和服务器环境中正确部署图像编辑器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 VJTools 容器化实践：用 libsysconfcpus 让 JVM 获取真实 CPU 核数
开发工具可观测性后端【免费下载链接】vjtoolsThe vip.coms java coding standard, libraries and tools项目地址https://gitcode.com/gh_mirrors/vj/vjtools点击查看免费下载容器中的 JVM 默认通过sysconf(_SC_NPROCESSORS_CONF)读取宿主机的 CPU 核数导致 GC 线程数、Netty 线程数等按宿主机规模配置造成线程泛滥与资源争抢。本文以唯品会开源项目 vjtools 中vjstar模块的 docker-cpus 方案 为核心讲解基于 libsysconfcpus 的通用补丁原理、镜像编译步骤与启动脚本改造方法并给出-server模式下的 2 核下限等关键注意事项帮助你在任何 JDK 版本上为容器 JVM 注入真实 CPU 配额。问题背景容器里 JVM 看到的核数为什么是假的Docker 容器通过--cpus或cpuset限制进程可用的 CPU但 JVM 在启动时并不读取容器的 cgroup 配额而是直接调用操作系统接口sysconf(_SC_NPROCESSORS_CONF)获取系统配置的处理器数量。在宿主机上部署多个容器时这个返回值是宿主机的总核数而非容器被分配到的核数。这个误差会沿 JVM 的运行时参数一路放大GC 线程数Parallel GC / CMS 默认按CPU核数 * 5/8计算并行线程数多余线程造成无谓的上下文切换Netty 等框架的默认线程数如 Netty 的 EventLoop 默认按2 * CPU核数创建线程数虚高直接拉高内存占用ForkJoinPool 公共池、定时线程池等均以Runtime.availableProcessors()为基准同样失真。官方修复并不覆盖所有版本。vjstar模块在 vjstar/README.md 中明确指出据说 JDK8 的最新版解决了这个问题但其他版本的 JDK 则建议使用此补丁。 因此唯品会vip.com在生产上采用基于 libsysconfcpus 的方案为各个版本的 JDK 提供一个通用解决方案。补丁原理LD_PRELOAD 截获 sysconf 系统调用libsysconfcpus.so 的原理非常精巧它利用 Linux 动态链接器的LD_PRELOAD机制抢先加载一个同名的sysconf函数实现从而截获 JVM 获取 CPU 核数所用的系统调用sysconf(_SC_NPROCESSORS_CONF)将其返回值改为读取环境变量LIBSYSCONFCPUS。整体调用链如下JVM 启动 └─ Runtime.availableProcessors() └─ sysconf(_SC_NPROCESSORS_CONF) ← 被 LD_PRELOAD 的 libsysconfcpus.so 截获 └─ 返回环境变量 LIBSYSCONFCPUS 的值而非宿主机核数只要在 JVM 进程启动前设置好两个环境变量整个过程对应用代码完全透明LIBSYSCONFCPUS告诉截获层容器实际分到了几个核LD_PRELOAD指向编译好的libsysconfcpus.so且必须放在最前面保证它优先于其他库被加载。第一步编译 libsysconfcpus.so 并放入镜像从 libsysconfcpus 项目获取源码并编译出共享库这一步通常在构建镜像时完成git clone libsysconfcpus 项目地址 cd libsysconfcpus make # 产物为 libsysconfcpus.so将编译产物安装到镜像的标准路径例如/usr/local/lib/libsysconfcpus.so。后续脚本中的LD_PRELOAD路径需与此保持一致。若你的基础镜像缺少编译工具链应尽量在构建阶段编译完成后再将 so 文件单独拷贝进运行镜像避免在运行镜像中保留编译环境。第二步编写启动脚本并注入环境变量vjstar仓库在 vjstar/src/main/script/docker-cpus 目录下给出了可直接套用的启动脚本。脚本完成两件事定义环境变量LD_PRELOAD把libsysconfcpus.so放在最前面达到截获的目的读取容器平台注入的 CPU 核数环境变量转换为 libsysconfcpus 所需的LIBSYSCONFCPUS。脚本原文以仓库为准#!/bin/sh if [ x$CONTAINER_CORE_REQUEST ! x ]; then LIBSYSCONFCPUS$CONTAINER_CORE_REQUEST if [ ${LIBSYSCONFCPUS} -lt 2 ]; then LIBSYSCONFCPUS2 fi export LIBSYSCONFCPUS fi export LD_PRELOAD/usr/local/lib/libsysconfcpus.so:$LD_PRELOAD逐行解读脚本片段作用if [ x$CONTAINER_CORE_REQUEST ! x ]; then判断容器平台是否注入了核数环境变量。x前缀是 POSIX Shell 防止变量为空时产生语法歧义的惯用写法LIBSYSCONFCPUS$CONTAINER_CORE_REQUEST把容器分配的核数转交给 libsysconfcpus 读取的环境变量if [ ${LIBSYSCONFCPUS} -lt 2 ]; then LIBSYSCONFCPUS2; fi强制核数下限为 2规避-server模式启动死锁问题见下文export LD_PRELOAD/usr/local/lib/libsysconfcpus.so:$LD_PRELOAD将 so 文件置于LD_PRELOAD最前面并保留原有项确保截获优先生效关于环境变量命名的两个说明原文档中提到部署容器时会额外传入一个环境变量CONTAINER_CORE_LIMIT代表分配的 CPU 核数而仓库脚本实际读取的是CONTAINER_CORE_REQUEST。两者并不一致使用时需按自己的情况修改如果你的容器平台注入的是CONTAINER_CORE_LIMIT或 Kubernetes 的resources.limits.cpu换算值请把脚本中的变量名替换为对应名称。若容器平台未注入任何核数环境变量LIBSYSCONFCPUS不会被设置此时 libsysconfcpus 将退化为透传真实的sysconf返回值不会破坏原有行为。关键警告-server模式至少需要 2 核原文档特别强调当 JVM 以-server启动时至少需要 2 核否则在启动时会被死锁。这正是脚本中LIBSYSCONFCPUS2下限存在的原因——即使容器只分配了 1 核也要向 JVM 报告 2 核避免服务器模式下线程与优化逻辑不足导致启动卡死。这个下限建议在生产环境保持默认不要随意下调。第三步与 JVM 启动参数脚本集成vjstar模块同时提供了完整的 JVM 启动参数推荐脚本。集成时将上述 docker-cpus 脚本与 jvm-options.sh 一起引入应用启动流程# 1. 先执行 docker-cpus 脚本完成 LD_PRELOAD 与 LIBSYSCONFCPUS 注入 source ./docker-cpus.sh # 2. 再加载 JVM 参数推荐脚本内部会按 JDK 版本自动适配 source ./jvm-options.sh # 3. 使用输出的 JAVA_OPTS 启动应用 java $JAVA_OPTS -jar your-app.jar值得留意的是jvm-options.sh 中有一条与容器 CPU 感知直接相关的注释如果 JVM 并不独占机器机器上有其他较繁忙的进程在运行将 GC 线程数设置得比默认值CPU核数5/8更低以减少竞争反而会大大加快 YGC 速度。在容器场景下这恰好印证了 CPU 核数失真会传导到 GC 线程数的论断——补丁修正核数后GC 线程数才会按容器配额计算而多容器共享宿主机时仍可按需进一步手工压低-XX:ParallelGCThreads与-XX:ConcGCThreads。验证补丁是否生效补丁注入后可通过以下方式验证1. 检查进程环境变量# 查看 JVM 进程的 LD_PRELOAD 与 LIBSYSCONFCPUS cat /proc/pid/environ | tr \0 \n | grep -E LD_PRELOAD|LIBSYSCONFCPUS2. 观察 JVM 实际感知的核数jinfo -flag PrintFlagsFinal pid 2/dev/null | grep -E ActiveProcessorCount # 或直接通过 JMX # java.lang.management.OperatingSystemMXBean.getAvailableProcessors()3. 观察 GC 线程数是否符合预期jinfo -flag ParallelGCThreads pid若补丁未生效优先检查so 文件路径是否与LD_PRELOAD一致、LD_PRELOAD是否被后续脚本覆盖应使用追加而非覆盖、以及环境变量注入是否发生在 JVM 进程启动之前。与 vjstar 其他最佳实践的配合docker-cpus 补丁只是 vjstar 模块服务化应用性能与可用性最佳实践的一部分它与其他实践共同构成容器化 JVM 的完整治理方案JVM 启动参数见 jvm-options.sh涵盖内存、GC、日志、排查与 JMX 等全量参数按 JDK 版本自动适配闲时主动 GC见 ProactiveGcTask.java 与 CleanUpScheduler.java在夜半闲时检测老生代占用达到阈值如 50%后主动触发一次 CMS GC通过随机时延避免所有实例同时清理对应的可运行示例见 ProactiveGcTaskDemo.java滑动窗口计数器见 RequestSlidingWindow.java用于任意时刻最近一分钟请求数统计、熔断计算等场景。小结容器中 JVM 读取宿主机 CPU 核数是容器化迁移的常见坑。唯品会在vjstar中沉淀的 docker-cpus 补丁以LD_PRELOAD截获sysconf(_SC_NPROCESSORS_CONF)的方式在不修改应用代码、不依赖特定 JDK 版本的前提下为 JVM 注入真实核数配合-server模式至少 2 核的下限保护可以安全地用于生产环境。完整脚本与配套的 JVM 参数最佳实践均可在仓库的 vjstar/src/main/script/docker-cpus/README.md 与 vjstar 模块中直接查阅与复用。赞分享开发工具可观测性后端【免费下载链接】vjtoolsThe vip.coms java coding standard, libraries and tools项目地址https://gitcode.com/gh_mirrors/vj/vjtools点击查看免费下载相关推荐MEGAcmd开发者指南理解架构、编译源码与贡献代码MEGAcmd开发者指南理解架构、编译源码与贡献代码 MEGAcmd是一款功能强大的命令行交互和脚本应用专为访问MEGA云存储服务设计。本指南将帮助开发者深vjstar 服务化应用性能与可用性最佳实践JVM 参数、容器 CPU 识别、闲时主动 GC 与滑动窗口计数器全解析vjstar 服务化应用性能与可用性最佳实践JVM 参数、容器 CPU 识别、闲时主动 GC 与滑动窗口计数器全解析 vjstar 是 vjtools 仓库中开发工具可观测性后端上一篇告别手动操作github-release 一键搞定 GitHub Releases 全流程下一篇CardKit部署指南在Web应用和服务器环境中正确部署图像编辑器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考