OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode) 8u131 And aboveįrom 8u131 Version starting support UseCGroupMemoryLimitForHeap and MaxRAMFraction These two options, use CGroupMemory The size of as JVM heap size, MAXRAMFraction Is used to control the amount of memory actually available, For example, set to 1 Word is CGroupMemoryLimit All, Set to 2 Half of the words ,3 Word is 1/3, And so on To configure -Xmx and -Xms Then we can achieve the results we want $ docker run -rm -m 2GB openjdk:8u121-alpine java -XshowSettings:vm -Xmx2000m -Xms2000m -version OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode) To configure JVM Parameters

OpenJDK Runtime Environment (IcedTea 3.3.0) (Alpine 8.121.13-r0) Heap Size (Estimated): 3.48G, Failed to correctly identify CGroup Resource constraints $ docker run -rm -m 2GB openjdk:8u121-alpine java -XshowSettings:vm -version Configure the initial heap size -Xms, The default value is ： In memory 1/64.Configure the maximum heap size -Xmx, The default value is ： In memory 1/4.JDK Version below 8u131 Version of JVM Will not automatically recognize CGroup Resource constraints, You need to manually set the initial heap size and the maximum heap size, Otherwise, the default value will be set according to all memory of the host ： The following operations are performed on one 4C 16G On the server. In the container JVM The process can automatically recognize CGroup Resource constraints, Get the correct memory and CPU Information to dynamically adjust itself.

Stay kubernetes in, We'll show you yaml Configuration in file CPU、 Memory requests and limits, We want. This will lead to JVM Read all the information of the host CPU And memory, Once the container uses more resources than the limit, it will be docker Kill. Take Java Application containerization solves the portability problem better, But there are also some unfriendly situations, For example, the lower version JDK（ lower than Java 8u131） It doesn't recognize CGroup Resource constraints.

Java 8 update 131