I think I already discussed this topic a few times here but it is interesting that requests and limits are N/A for java (JVM) perspective – OpenJDK will use limit as the mark for cpus.

And naturally, given the container’s cpu values are static (except on k8s 1.27) so then the limits will be inelastic.

Objectively, for the JVM basically limits will be used limits. The JVM won’t re-scale on the fly and will be ineslastic, and won’t re-scale on the fly so the number of threads (for instance parallel GC threads won’t change after the JVM has started). So the cpu details won’t fluctuate and this will change the GC threads or some deduced thread (pools that use cpu for calculation).

It is interesting that the JVM will actually round up the cpu for instance, so one pod with 5.2 cpu will end up being 6 cpus (with 2 cores and 2 threads per core for instance), depending on the K8S architecture below.

In any case collect the jcmd $PID VM.info to be able to display the values correctly and look for something like this:

→ CPU:total 4 (initial active 2) (2 cores per cpu, 2 threads per core): so 2 cpus == 4 cores == 8 threads.