在阅读一些关于性能调优的笔记时，我确实注意到了在设置内存大小时的建议：
Java 应用程序应将初始和最大永久代大小调整为相同的值，因为增长或收缩永久代空间需要完整的 GC。在设置堆大小时给出了类似的建议，即-Xmx=-Xms。
我的问题是，那我们为什么要设置 -Xms 呢？
此外， 如果 -Xmx 和 -Xms 的值不同，而不是 -Xmx 和 -Xms 的大小相同，为什么会经常触发 GC。
在我的第二个问题中添加更多内容，如果我从最小堆大小 64M 和最大 512M 开始，我相信除非我的应用程序使用的内存达到 512M，否则不会触发完整 GC。
同样，如果我从 -Xmx 和 -Xms 的 512M 开始，当我的应用程序内存使用达到此限制时，JVM 仍然会触发完全 GC。那么为什么建议将 max 和 min 设置为相同的值呢？
设置标志是在 VM 进行分代增量收集之前设计的。在那种情况下，所有的收藏品都是完整的。在更现代的收藏家中，完整的收藏品很少见。这很好，因为增量收集通常是几毫秒，所以 UI 体验不会改变。大型竞技场的完整收藏可能需要几秒钟或更长时间。改变竞技场大小 - 正如文件所说 - 保证每次都会导致完整的集合。
该指南并非 100% 完美。很少有几种应用程序允许竞技场发展是合理的。
-Xms=64m -Xmx=512m并不意味着“以 64 到 512 MB 之间的堆启动”。它指示 JVM 在启动时请求 64MB 的已提交内存和 512MB 的保留内存。堆开始时为 64MB，当它填满时，将扩展到为其保留的空间。因此，对于 64MB 的 Xms，您会在堆填满 64MB 之前看到完整的集合。
如果您以较低的 Xms 值启动应用程序并打开 GC 日志记录 ( -verbose:gc -Xloggc:FILENAME)，则日志文件将显示堆和生成大小在应用程序运行时如何变化。
较小的 Xms 可能会更频繁地收集次要集合，因为新一代会更小（假设您使用比例生成大小而不是显式），因此会更快地填充。
-Xms < -Xmx 的一个原因是允许 JVM 不预先分配整个 Xmx，以便其他应用程序可以使用差异（可能是一段时间）。血淋淋的细节在这里：http ://www.ibm.com/developerworks/library/j-memusage/