OpenJDK 9中首次新增了一项实验性功能，JVM可借助该功能检测到自己运行在容器中，进而酌情调整内存限制。尽管过去几年来容器技术日渐流行，但包括JVM在内的很多工具依然需要通过宿主机的参数访问可用资源，经常会遇到内存不足的情况，并会显示各种令人困惑的错误信息。与Java 9一同发布的该功能正是为了在多种使用场景中避免出现此类问题而生。
\u0026#xD;\n\u0026#xD;\n
诸如Docker、Heroku或Kubernetes等容器技术实际上是一种基于Linux操作系统的轻量级虚拟机。这种虚拟机的空间占用更低，意味着可以在消耗更少资源的情况下，更快速地提供与传统虚拟机极为类似的功能，但这种做法也有不足之处：传统虚拟机更成熟，可模拟一整套专用硬件，并可确保大部分现有软件可以按照预期结果运行；但容器技术使用了宿主机的硬件和操作系统，这意味着需要依赖宿主机相关信息的软件在运行过程中可能无法感知容器本身所造成的额外局限。Netflix公司Linux容器服务（也叫做Titus）部门开发者Fabio Kung在2014年撰文介绍了这一情况，虽然时至今日，那篇文章中的部分内容已经有些过时，但依然可以帮助我们充分了解这个问题。
\u0026#xD;\n\u0026#xD;\n
JVM也曾饱受这个问题困扰。如果不使用-Xmx指定内存上限，JVM会将上限设置为物理内存数的一小部分（通常为1/4，但情况可能各异），而这一结果甚至还没有考虑到容器本身所造成的限制。Java 9中新增的这项功能可以判断JVM是否运行在Control Group，即cgroup中（这是一种Linux技术，大部分容器会通过该技术对硬件和其他资源的使用施加强制限制），借此预防出现类似的问题。如果JVM检测到自己运行在cgroup中，随后会试图确定cgroup所定义的内存限制，将该限制视作可用物理内存总量，并将其他每个参数设置为该值的一部分。这依然是一个实验性功能，只有通过-XX:+UseCGroupMemoryLimitForHeap选项激活后方能生效。
\u0026#xD;\n\u0026#xD;\n
Cgroups最早在2008年被纳入Linux内核，并在2013年进行了重新设计，该技术可对资源的使用进行隔离，让应用程序对内存、CPU、IO、网络等资源的访问进行控制。不同应用程序可创建自己的Control Group层次结构，并给每个Group应用不同的限制，这意味着应用程序无法事先知道自己要运行在哪个Group中。也正是因此，JVM只能根据cgroup和可能应用的内存限制进行猜测。
\u0026#xD;\n\u0026#xD;\n
查看英文原文：Java 9 Will Adjust Memory Limits if Running with Docker
