Connecting a JMX monitoring tool, e.g. JConsole, JMC,... and observing Java heap memory shows continually increasing Java heap memory, even for an idle application.

Java allocation builds up, until a GC, and the cycle repeats.

Monitor a busy application and this overhead disappears at each GC. But if GC is not triggered, we create what looks at first like a leak.

Some of the overhead is unavoidable. Java code performs the monitoring, and builds the JMX responses. ObjectOutputStream and the serialization of an object graph has overhead in the Java heap.

On Linux, the frequent calls to e.g. com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() mean reading String values from a cgroup file, e.g. jdk.internal.platform.cgroupv1.SubSystem.readStringValue(String). Every sample in the Linux cgroup subsystem requires reading a file in /sys/fs/cgroup, and possibly all lines of the file. In an object histogram, the Readers don't build up to a large amount, but the raw String data does.

Testing a simplistic cache of cgroup data did reduce the allocations, but I did a test that took no account of changing cgroup data.
There are likely other alternatives. e.g. Can the buffers be reused and String creation minimised.