升级Java 1.8.0_281后Ehcache配置256MB堆外缓存报宿主物理内存仅0B启动错误

• JDK 8u281在Linux环境下新增了cgroup内存资源的自动探测逻辑。如果应用运行在带cgroup内存配额的受限环境（包括Docker容器、Kubernetes Pod、通过systemd为进程配置MemoryLimit的物理机场景），一旦cgroup的挂载路径、权限或版本与JDK的预期逻辑不匹配，会导致OperatingSystemMXBean.getTotalPhysicalMemorySize()方法错误返回0值，而非真实的物理机总内存大小。
• Ehcache 3.9.0初始化堆外缓存时，依赖上述MXBean接口返回的主机物理内存总量做前置校验，拿到0值后就会触发“检测到宿主仅存在0B物理内存，无法为堆外缓存分配256MB空间”的异常。这类报错和服务器实际物理内存是否充足、Swap空间配置没有直接关联，也是之前调整Swap后问题仍无法解决的核心原因。
• 可正常启动的对照服务器，由于未配置cgroup内存限制，JDK走原生的宿主内存读取分支，能正常获取内存数值，因此不会触发同类报错。

• 检查应用运行环境的cgroup配置：
  • 在应用实际运行的执行会话中，执行cat /sys/fs/cgroup/memory/memory.limit_in_bytes，查看返回值是否为0、或是与实际物理内存严重不符的数值
  • 核对应用启动链路，确认是否通过systemd-run、docker run、Kubernetes资源申明等方式为进程设置了内存上限
• 对比两台同Java版本服务器的启动JVM参数差异，定位是否缺少容器环境适配相关开关
• 对比异常服务器与正常服务器的/proc/mounts配置，排查cgroup挂载条目的配置差异

• 修正JDK的cgroup识别逻辑，在应用启动参数中添加适配开关，让JDK正确获取cgroup对应的内存数值：
  • JDK 8u281及以上版本添加-XX:+UseCGroupMemoryLimitForHeap；如果是cgroup v2的运行环境，额外添加-XX:+UseContainerSupport
  • 服务启动后，可通过jinfo -flag UseCGroupMemoryLimitForHeap <进程PID>确认参数已生效
• 绕过Ehcache的物理内存前置校验：在应用启动参数中添加-Dehcache.offheap.memory.check=false，跳过Ehcache对MXBean返回值的校验逻辑，直接按配置值申请堆外内存
• 回退JDK的cgroup探测能力：如果确认当前环境不存在cgroup配置异常，可在启动参数中添加-XX:-UseContainerSupport，让JDK恢复到旧版本的原生宿主内存读取逻辑，避免cgroup探测异常返回0值的问题

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