AWS Java Container Best Practices for JVM Memory, CPU, and Classpath

Containers share the host kernel, meaning syscalls from within a container are handled by the host's kernel, regardless of the user space distribution. This shared kernel behavior can influence low-level operations like directory listings that the JVM relies on, even with container-aware JVMs.

Classpath issues arise from nondeterministic ordering in wildcard classpath expansion (e.g., lib/*) and when multiple JARs with different class versions exist. This can lead to ClassNotFoundException or NoClassDefFoundError, often surfacing after host updates or redeployments due to underlying filesystem behavior.

To mitigate classpath issues, the recommended approach is to bundle dependencies into fat JARs. If not feasible, alternatives include using frameworks with deterministic packaging (Spring Boot nested JARs, Quarkus, Micronaut), detecting version conflicts at build time, relocating conflicting dependencies, and preferring explicit classpath ordering over wildcards.

Resource allocation mismatches occur when the JVM's default settings for memory and CPU don't align with container limits. This can lead to OutOfMemory (OOM) kills if the JVM allocates too much heap or oversubscribes resources, especially when older JVMs read host memory or when non-heap memory pushes usage over the limit.

Routine host operating system updates, including kernel patches on Fargate or AMI updates on EC2, can alter filesystem behavior. These changes can indirectly affect how the JVM resolves classpaths or detects resources, leading to unexpected application failures without any changes to the container image or application code.