jmap-histo&堆操作会给jvm带来开销?

问题描述

如标题所述，jmap -histo和jmap -heap分别给jvm带来了多少开销?

如果内存敏感的Java进程位于OutOfMemory的边缘(例如，大约96％的堆已满，并且无法由完整的gc清除)，那么其中一项操作可能会带来jvm到内存不足?

解决方案

jmap -histo和jmap -heap的工作方式不同:jmap -histo使用动态附加机制，而jmap -heap通过HotSpot Serviceability Agent工作. 在此处进行说明... >

因此，jmap -histo由JVM本身执行，但是jmap -heap在工具进程中运行，而JVM进程被挂起.在这两种情况下，都不会创建新的Java对象，该工具不会导致OutOfMemoryError.

在两种情况下都停止了应用程序线程:jmap -histo停止Java线程，而jmap -heap停止整个JVM进程.暂停的持续时间可能会相当长，尤其是对于大堆而言.例如.遍历4GB的堆可能要花费几秒钟.

As the title states, how much overhead does jmap -histo and jmap -heap bring to a jvm respectively?

If a memory sensitive Java process is at the edge of OutOfMemory (e.g around 96% of heap is full, and can't be cleared by full gc), is it possible for one of the operations to bring the jvm to OutOfMemory?

解决方案

jmap -histo and jmap -heap work differently: jmap -histo uses Dynamic Attach Mechanism, and jmap -heap works through HotSpot Serviceability Agent. The difference is described here.

Therefore, jmap -histo is executed by JVM itself, but jmap -heap runs in a tool process while JVM process is suspended. In both cases no new Java objects are created, the tool will not cause OutOfMemoryError.

In both cases application threads are stopped: jmap -histo stops Java threads, and jmap -heap stops the whole JVM process. The duration of the pause can be rather long especially for large heaps. E.g. it may take several seconds to walk through 4GB heap.

这篇关于jmap-histo&堆操作会给jvm带来开销?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！