内存限制自适应，容器中运行Java 9效果更出众-InfoQ



 写点什么

OpenJDK 9 中首次新增了一项实验性功能，JVM 可借助该功能检测到自己运行在容器中，进而酌情调整内存限制。尽管过去几年来容器技术日渐流行，但包括JVM 在内的很多工具依然需要通过宿主机的参数访问可用资源，经常会遇到内存不足的情况，并会显示各种令人困惑的错误信息。与Java 9 一同发布的该功能正是为了在多种使用场景中避免出现此类问题而生。

诸如 Docker 、 Heroku 或 Kubernetes 等容器技术实际上是一种基于 Linux 操作系统的轻量级虚拟机。这种虚拟机的空间占用更低，意味着可以在消耗更少资源的情况下，更快速地提供与传统虚拟机极为类似的功能，但这种做法也有不足之处：传统虚拟机更成熟，可模拟一整套专用硬件，并可确保大部分现有软件可以按照预期结果运行；但容器技术使用了宿主机的硬件和操作系统，这意味着需要依赖宿主机相关信息的软件在运行过程中可能无法感知容器本身所造成的额外局限。Netflix 公司 Linux 容器服务（也叫做 Titus ）部门开发者 Fabio Kung 在 2014 年撰文介绍了这一情况，虽然时至今日，那篇文章中的部分内容已经有些过时，但依然可以帮助我们充分了解这个问题。

JVM 也曾饱受这个问题困扰。如果不使用-Xmx指定内存上限，JVM 会将上限设置为物理内存数的一小部分（通常为 1/4，但情况可能各异），而这一结果甚至还没有考虑到容器本身所造成的限制。Java 9 中新增的这项功能可以判断 JVM 是否运行在 Control Group，即 cgroup 中（这是一种 Linux 技术，大部分容器会通过该技术对硬件和其他资源的使用施加强制限制），借此预防出现类似的问题。如果 JVM 检测到自己运行在 cgroup 中，随后会试图确定 cgroup 所定义的内存限制，将该限制视作可用物理内存总量，并将其他每个参数设置为该值的一部分。这依然是一个实验性功能，只有通过-XX:+UseCGroupMemoryLimitForHeap选项激活后方能生效。

Cgroups 最早在 2008 年被纳入 Linux 内核，并在 2013 年进行了重新设计，该技术可对资源的使用进行隔离，让应用程序对内存、CPU、IO、网络等资源的访问进行控制。不同应用程序可创建自己的 Control Group 层次结构，并给每个 Group 应用不同的限制，这意味着应用程序无法事先知道自己要运行在哪个 Group 中。也正是因此，JVM 只能根据 cgroup 和可能应用的内存限制进行猜测。

查看英文原文： Java 9 Will Adjust Memory Limits if Running with Docker