在运行时释放OS的java内存。
假设我有一个Swings Java应用程序，我设置最小堆是64MB和最大堆2GB，当用户启动应用程序时，将显示登录屏幕，此时应用程序使用64MB，权限？ 从我的Windows 7中，我可以看到java应用程序从操作系统的内存资源监视器中分配了64MB（实际上，它超过64MB，因为JVM需要一些内存来完成它的任务）。
之后，用户执行了一些非常繁重的工作，然后应用程序使用2G。 然后用户注销应用程序，再次显示登录屏幕（应用程序尚未关闭）。 此时应用程序使用64MB的实际内存（假设这是完美的内存管理应用程序），但是这个应用程序的OS仍在使用2G的RAM，我可以在OS的资源监视器上看到它。
我希望我的应用程序在不需要使用大内存时将内存释放到操作系统。 我可以在运行时使用java应用程序吗？
我的意思是当我的应用程序需要使用64MB的Ram，然后操作系统只给它64MB，当它需要2GB的RAM然后OS给它2GB，之后它需要64MB的ram然后操作系统再给它64MB，我不要浪费2000MB – 64MB = 1936MB。
我能这样做吗？
谢谢，
我在那里发布了我的测试结果。 基本上，MaxHeapFreeRatio不受每个GC实现的尊重，并且，为了使其更糟糕，似乎有足够的堆活动以便及时触发它，即。 可能是你需要2次完整的GC运行来实际释放内存到操作系统。 如果你有一个X GB的突发内存占用，那么你可能需要分配该数量的1或2倍才能触发堆缩小。 或者您手动调用System.gc（）。
如果性能不是问题，并且内存占用非常重要，请尝试：
-XX:UseSerialGC -Xms16M -Xminf=5 -Xmaxf=10 我希望我的应用程序在不需要使用大内存时将内存释放到操作系统。 我可以在运行时使用java应用程序吗？
不，你不能。
在某些情况下，GC会根据自己的意愿将内存释放回操作系统，但我不知道任何允许应用程序告诉GC执行此操作的JVM。 最重要的是，GC在这方面相当保守，因为……作为一般规则…… JVM将以更多内存更高效地运行，并且不断地向OS请求/回馈内存是低效的。
请注意，GC调整选项-XX:MaxHeapFreeRatio可用于指定GC将释放内存之前的可用堆的最大比率。 但是，有并发症。 例如，并非所有可用的GC都遵循此选项。 如果你打算尝试这种方法，我建议你做一些研究……不要指望奇迹。
热点中的serialgc会给内存回复……至少它已经过去了。 你的表现将会下降。
IBM J9 jvm中的所有垃圾收集器都将释放内存。 我不确定这个jvm是免费下载的…
最好的答案是，你为什么担心？ 这些天记忆力很便宜，免费记忆是浪费记忆。 这实际上是个问题吗？ 操作系统无论如何都会将额外的未使用内存分页到磁盘。 最好的答案是忽略它。 🙂
您也可以考虑谷歌搜索堆外存储，也许是Teracotta / eh缓存。
编辑：
我刚刚在JDK1.7u6中注意到，使用带有小Xms和大型Xmx的G1GC，垃圾收集器将在一些垃圾收集之后减少堆的大小，其中多余的对象已被释放。
您可以处置对象并建议垃圾收集器执行其工作，但如果GC认为没有必要，则会忽略该请求。 总而言之，’不’。
请注意分配给Java应用程序的内存。 在应用程序之前设置。 开始，不可调整。
尝试将代码的一部分分离到一个单独的线程中，并在不再需要时将其处理掉。