Why Does Java Misbehave in Docker and How Java 10 Fixes It

What problems does Java have in Docker?

Many applications run on the JVM inside containers, including large data services such as Apache Spark and Kafka. As the JVM becomes more tightly integrated with containers, issues emerge, mainly concerning memory and CPU sizing because Java does not recognize that it is running inside a container.

By default, Java's heap size is one‑quarter of the physical memory. For example, on a machine with 2 GB RAM, a Java container limited to 512 MB will report a maximum heap of 512 MB, which is still one‑quarter of the host memory rather than the container limit.

This can cause problems in production, such as the container being killed by the orchestrator.

Workarounds include setting JVM parameters via environment variables in the Dockerfile or using Fabric8‑provided base images, but these are limited and inconvenient. Java 10 resolves these issues.

Java 10 solution

(1) Container memory limits

Running the same example with Java 10 shows the heap correctly limited to 128 MB.

(2) Setting available CPU

By default, each container can use unlimited CPU cycles of the host, but Java 10 allows limiting CPU usage.

CPU weight can also be set, and idle containers can share remaining CPU time.

Idle available CPU:

(3) Estimating required memory and CPU

With resource limits configurable, you can estimate the total CPU and memory needed. For example, an application deployed on ten nodes, with five nodes requiring 512 MB memory and 1024 CPU shares, and the other five requiring 256 MB memory and 512 CPU shares, needs a minimum of 5 GB memory and 8 CPUs.

Calculations:

512 MB × 5 = 2.56 GB

256 MB × 5 = 1.28 GB

Total memory ≈ 5 GB

1024 × 5 = 5 CPUs

512 × 5 = 3 CPUs

Total CPUs = 8

Conclusion

Java 10 correctly detects that it runs inside a container, achieving seamless integration and eliminating many common pitfalls.

Source:

https://medium.com/@jnsrikanth/docker-support-in-java-10-fbff28a31827