当 -Xmx 和 -Xms 相同时 jvm 堆大小调整
我有一个独立的java应用程序，其jvm参数是：
-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
正如我们所看到的，-Xmx和-Xms都是2g，但我发现堆大小总是稍微调整大小： 
红线代表总堆大小，蓝色代表 已使用代表已使用 我认为红线应该是直的，但事实并非如此。 但在另一个Web应用程序中，jvm参数是：
-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
它的可视堆使用图表是：
总计堆大小正好是 2g，红线是水平稳定的，我认为应该是这样。
两个应用程序的主要区别在于使用的GC策略，一个是并行GC，另一个是CMS。 GC策略对堆空间大小的调整有影响吗？或者 -Xmn 参数对堆大小调整有一些我不知道的影响？
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 the 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
并行 GC 通过 GC 人体工程学来实现一些技巧，它尝试在运行时调整内部堆大小（旧堆、新堆、永久堆等），以帮助实现肉吞吐量或延迟目标。
监视工具可能不希望看到部分堆大小调整，而是直接报告这些调整大小，而不是对其进行平滑处理。
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.