How to use VisualVM
Introduction
VisualVM is a tool that allows you to check Java memory usage. It is used to check if there is a tendency for memory leaks when conducting continuous load tests. I think it's not a new tool, but I think it's still an active tool, and some people don't know much about it, so I used a sample program that tends to leak memory and used it easily (as far as I know). In).
Sample program
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.TimeUnit;
public class MemoryLeak {
private static class SampleClassA {
private final List<byte[]> list = new ArrayList<>();
private void malloc() {
list.add(new byte[1024]);
}
private void clear() {
list.clear();
}
}
private static class SampleClassB {
private final List<byte[]> list = new ArrayList<>();
private void malloc() {
list.add(new byte[1024]);
}
private void clear() {
;
}
}
public static void main(String[] args) throws Exception {
SampleClassA sampleA = new SampleClassA();
SampleClassB sampleB = new SampleClassB();
while(true) {
sampleA.malloc();
sampleB.malloc();
sampleA.clear();
sampleB.clear();
TimeUnit.MILLISECONDS.sleep(100);
}
}
}
SampleClass A and Sample Class B each allocate and release 1kB of memory every 100 milliseconds. It looks almost the same, but SampleClass B doesn't actually free up memory.
How to use
Let's test it easily using the above sample program.
1. Start VisualVM
to start. In this example, we use VisualVM in Pleiades of Eclipse (in Windows, you should be able to start it with java / 8 / bin / jvisualvm.exe).
2. Run the program you want to test
This time, execute the above sample program from Eclipse.
When you run it, the running program will appear in VisualVM as shown below (it may not appear if you download VisualVM separately from Eclipse).
Click this to see the current CPU usage and memory usage as shown below.
3. Record the state at the start of the test
Record it later for comparison with the state at the start of the test. For the time being, after executing GC from the monitoring tab, take a screenshot and record the current memory usage (blue part is the current memory usage). Also, if you press the heap dump button from the upper right of the monitoring tab, you can get the class information currently being read as shown below.
4. Leave for a while
Even if the memory usage seems to be increasing temporarily, it seems that the increase may stop in the middle, so leave it for a certain period of time. In the old company, it was monitored by leaving it for about a week, at least 3 days, but it depends on how long the monitoring period should actually be.
5. Compare with post-test results
Since it is troublesome, it will be completed in about 2 hours and compared with the result before the test.
The memory usage after executing GC is about 80MB. Before the test, it was about 10MB, so you can see that it is rising.
By acquiring a new heap dump, you can compare it with the previous heap dump. If you get a heap dump as before and select Compare with another heap dump from the upper right of the class tab, you can see what kind of instance is increasing like the following. In this case, byte [] is increasing.
You can also find out where the instance is referenced from here. Double-click byte [] in the cluster tab, click the appropriate one from the instance on the left, and then open the reference in the lower right. At least one of the byte [] instances is referenced from SampleClass B. You can see (see the type part).
In production, various instances are referenced from various places, but in this case, even if you open the references of other instances, you can see that they are mostly referenced from SampleClass B.
in conclusion
- This time I wrote about memory, but in reality, I should be able to investigate various other things.
- There are some cases (I think) that cannot be grasped by this tool alone, such as an increase in file descriptors due to forgetting to close the file, so it is necessary to separately test using other tools and commands.
Recommended Posts