jvm heap resize when -Xmx and -Xms are the same though

I have a stand-lone java app, which jvm params are:

-Xmx2g -Xms2g -Xmn1g -XX:PermSize=96m -XX:+DisableExplicitGC 
-XX:+UseFastAccessorMethods  -XX:+UseParallelGC -XX:+UseParallelOldGC 
-XX:MaxTenuringThreshold=63 -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true

as we can see, -Xmx and -Xms are all 2g, but I found the heap size always resize a bit:

the red line represents the total heap size, the blue one represents used I think t开发者_开发技巧he red line should be straight, but it wasn't. But in another web app, which jvm params are:

-Xmx2g -Xms2g -Xmn512m -XX:PermSize=196m -Xss256k -XX:+DisableExplicitGC 
-XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled 
-XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m 
-XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=70 -XX:-ReduceInitialCardMarks 
-Djava.awt.headless=true -Djava.net.preferIPv4Stack=true

its visual heap usage chart is:

The total heap size is exactly as much as 2g and the red line is horizontal stable, that's what I think it should be.

The main difference of the two apps are the GC strategy used, one is parallel GC and the other is CMS. Does the GC strategy has any effect on the resizing of the heap space? Or the -Xmn param has some effects on heap resizing that I didn't know?

Parallel GC does some tricks through something known as GC ergonomics, which attempt to resize the internal heap sizes (OLD, new, perm etc) at runtime to help meat throughput or latency goals.

Its possible that the monitoring tool is not expecting to see parts of the heap resize and is reporting these resizes directly rather than smoothing it out.