当前位置: 首页 > 面试题库 >

当内存占用超过特定阈值时强制执行完全垃圾收集

戚俊健
2023-03-14
问题内容

我有一个服务器应用程序,在极少数情况下,可以分配大块内存。

这不是内存泄漏,因为 垃圾收集器可以通过执行完整的垃圾收集来收回这些块正常的垃圾回收会释放太小的内存:在这种情况下,这是不够的。

垃圾收集器认为适当时,即在应用程序的内存占用量接近由-Xmx指定的分配最大值时,将执行这些完整的GC。

如果不是因为 这些有问题的内存分配突然爆发 而导致的,并且由于 jvm无法足够快地执行GC来释放所需的内存
这一事实而导致OutOfMemoryErrors,那没关系。如果我事先手动调用System.gc(),则可以避免这种情况。

无论如何,我宁愿不必自己监视jvm的内存分配(或将内存管理插入到应用程序的逻辑中);如果有一种方法可以运行具有内存阈值的虚拟机,那么它将自动执行完整的GC,以便尽早释放我需要的内存,这将是很好的。

长话短说:我需要一种方法(命令行选项?)来配置jvm,以便在内存占用达到一定阈值时尽早释放大量内存(即执行完整的GC),我不在乎这会使我的应用程序偶尔变慢。

到目前为止,我发现的所有方法都是修改世代大小的方法,但这不是我所需要的(至少不是直接使用)。

非常感谢您的建议,

西尔维奥

PS我正在努力避免大量分配,但是这可能需要很长时间,而我的应用需要一点稳定性

更新 :使用jvisualvm分析应用程序,我可以看到问题出在老一代


问题答案:

从这里开始(这是一个1.4.2页面,但是所有Sun
JVM中都应该存在相同的选项):

假设您使用的是CMS垃圾收集器(我相信服务器默认情况下会打开),则所需的选项是

-XX:CMSInitiatingOccupancyFraction=<percent>

其中%是将触发完整GC的正在使用的内存百分比。

在此处插入标准的免责声明,这样会使GC参数混乱会给您带来严重的性能问题,并因机器而异。



 类似资料:
  • 主要内容:JEP 189 : Shenandoah:一个低暂停时间的垃圾收集器(实验性),JEP 346 : 及时返回未使用的已提交内存,JEP 344:可中止的混合集合Java 12 为其垃圾收集算法引入了多项增强功能。 JEP 189 : Shenandoah:一个低暂停时间的垃圾收集器(实验性) 引入了一个实验性的低暂停时间垃圾收集器 Shenandoah 以减少 GC 暂停时间。它与运行 Java 线程并行工作。这有助于减少 GC 对堆大小的依赖性并使其保持一致。现在垃圾收集暂停时间对于

  • 问题内容: 我正在读取一个很大的文件,并从每一行中提取文本的一小部分。但是,在操作结束时,我的工作记忆很少。似乎垃圾收集器在读取文件后无法释放内存。 我的问题是:有什么办法释放这种记忆?还是这是JVM错误? 我创建了一个SSCCE来演示这一点。它读取一个1 mb(由于16位编码,在Java中为2 mb)的文件,并从每行中提取一个字符(约4000行,因此大约为8 kb)。测试结束时,仍将使用全部2

  • 我很难理解为什么我的Java应用程序正在慢慢消耗pod可用的所有内存,导致Kubernetes将pod标记为内存不足。JVM(OpenJDK 8)由以下参数启动: 我正在监控pod和JVM内存使用的内存,并期望看到一些相关性,例如在主要的垃圾回收机制之后,使用的pod内存也会下降。但是我没有看到这一点。我在下面附上了一些图表: 我正在纠结的是,为什么在16:00之前堆内存显着减少时,pods内存不

  • 问题内容: 因此,我正在远程容器上查看带有jmap的堆,并且我想对其进行强制垃圾收集。如何在不弹出jvisualvm或jconsole和朋友的情况下执行此操作? 我知道您不应该进行强制垃圾回收的实践-您应该弄清楚为什么堆很大/越来越大。 我还意识到System.GC()实际上并没有强制垃圾回收-它只是告诉GC您希望它发生。 话虽如此,有没有一种方法可以轻松地做到这一点?我缺少一些命令行应用程序?

  • 我正在使用JCUDA,想知道JNI对象是否足够聪明,可以在垃圾收集时解除分配?我能理解为什么这可能在所有情况下都不起作用,但我知道它会在我的情况下起作用,所以我的后续问题是:我如何才能完成这一点?有没有我可以设置的“模式”?我需要构建抽象层吗?或者答案真的是“不,永远不要尝试”,那么为什么不呢? 编辑:我只是指通过JNI创建的本机对象,而不是Java对象。我知道所有Java对象都被平等地对待,即垃

  • 主要内容:JEP 304 : 垃圾收集器接口,JEP 307 : G1 的并行 Full GCJEP 304 : 垃圾收集器接口 在 Java 10 之前,GC(垃圾收集器)实现组件分散在代码库中,不容易替换。在 Java 10 中,引入了 Garbage-Collector 接口,以便可以插入替代的 GC 实现。它还有助于将代码库与不同的垃圾收集实现隔离。此功能是 JEP 304 的一部分。 JEP 307 : G1 的并行 Full GC Java 9 引入了 G1(垃圾优先)垃圾收集