您可以尝试指定-XX:MinHeapFreeRatio和-XX:MaxHeapFreeRatio来控制堆的扩展和收缩：
-XX:MinHeapFreeRatio - 当代的可用空间百分比低于此值时，该代将被扩展以达到此百分比。默认值为40。-XX:MaxHeapFreeRatio - 当代的可用空间百分比超过此值时，该代将收缩以达到此值。默认值为70。您还可以通过指定-XX:+UseConcMarkSweepGC来尝试并发GC。根据您的应用程序，这可能会在增加CPU周期的成本下使堆大小更低。
当JVM优化时，它将使用您指定的可用内存。您可以指定较低的内存量，例如-Xmx768m，使其保持在控制范围内，这可能会正常运行，但在负载较重的情况下会增加内存耗尽的风险。实际上，减少整体内存使用的唯一方法是编写使用更少内存的代码 :)
更新 Java 15 增加了两个收集器。在ZGC中一些相关选项包括：
-XX:+UseZGC：启用 ZGC。-XX:+ZProactive和-XX:+ZUncommit：两者默认均已启用。ZGC 会主动释放垃圾对象并将释放的内存返回给操作系统，其余选项调整释放行为的积极程度。-XX:ZCollectionInterval=seconds：GC 运行的频率。设置为几秒钟以确保尽快清理垃圾（默认值为 0，即不能保证 GC 运行）。-XX:ZUncommitDelay=seconds：堆内存未使用多久后必须被取消分配的时间（以秒为单位）。默认情况下，此选项设置为300（即5分钟）。降低此数值可更快地回收内存。-XX:SoftMaxHeapSize：每当应用程序使用超过此限制的内存时，GC 就会更频繁地触发。（这可能是 OP 寻找的答案。）-XX:SoftRefLRUPolicyMSPerMB：不确定此选项的使用频率，但它控制一些缓存对象在内存中保留的时间。原始回答 HotSpot 中有四个（实际上是五个）不同的垃圾收集器，对于每个收集器您的可选项都不同。
-XX:MinHeapFreeRatio和-XX:MaxHeapFreeRatio，可以更直接地控制其行为。但我对串行收集器没有太多经验。-XX:+UseParallelOldGC）具有-XX:MaxGCPauseMillis=<millis>和-XX:GCTimeRatio=<N>。将最大暂停时间设置得更低通常会使收集器缩小堆大小。但是，如果暂停时间已经很短，堆不会变小。另一方面，如果最大暂停时间设置得太低，应用程序可能会花费所有时间来进行收集。将较低的gc时间比率设置通常也会使堆变小。您告诉gc愿意在返回较小的堆的同时投入更多CPU时间进行收集。但是，这只是一个提示，可能没有任何效果。在我看来，针对最小化堆大小的目的，并行收集器几乎无法调整。如果您让它运行一段时间且应用程序的行为保持不变，则此收集器效果更好（它会自动调整）。-XX:+UseConcMarkSweepGC）通常需要更大的堆才能实现其主要目标——低暂停时间，因此我不会讨论它。-XX:+UseG1GC）不像旧收集器那样愚蠢。我发现它会自行选择较小的堆大小。它有很多调整选项，尽管我只是开始研究它们。-XX:InitiatingHeapOccupancyPercent、-XX:G1HeapWastePercent、-XX:G1ReservePercent和-XX:G1MaxNewSizePercent可能会引起兴趣。请查看java标志列表。
System.gc() 方法，但这只是向 JVM 提示它可以或不可以执行垃圾回收，并且无论如何，您都不知道何时进行垃圾回收。正如文档中所述，这只是一个尽力而为的请求。-Xmx1G，那么您告诉 JVM 堆的最大空间为 1GB，既然您已经指定了这个值，我不明白为什么它会试图保持较低的值，如果它知道 1GB 仍然可行（我们处于内存管理语言的上下文中）。如果您不希望堆增加那么多，请降低最大值，这样在分配新对象之前将被强制执行 GC，否则为什么要告诉它使用 1GB？
CMS通常比G1差，尽管您的答案可能早于它。 - Aleksandr DubinskyG1是非常好的垃圾回收器，但在 Java 7 上它对于任何需要频繁进行类加载和卸载的低延迟系统来说都不太适用，因为它无法清理永久代（permgen）。而 Java 8 则不存在这个问题。 - Leliel-XX:+CMSClassUnloadingEnabled- Leliel