This article introduces some simple troubleshooting methods for finding large JVM memory problems. There are three main methods:

  • Run the jmap-histo command to query the classes that occupy large memory
  • Dump heap memory. If a file is too large, run jHAT on the server to check the heap memory status of dump files
  • Dump heap memory, download the heap file to the local, using VisualVM to check the dump file heap memory status

The simulated JVM has a high memory footprint

The simulation project uses JDK8

Here we use springBoot to start the project in order to be closer to the actual project. If you try to start the project by yourself, you can directly use @test. After starting, there will be fewer classes in the thread, and it will be clearer to check the heap memory

packageCom.cflong. JVM troubleshooting;import lombok.AllArgsConstructor;
import lombok.Data;

/** * MemoryBase simulation object **@author cflong
 * @date2021/05/13 21:24:27 * /
@Data
@AllArgsConstructor
public class MemoryBean {
    
    private String name ;

    private int age;

    private String remark;
}
Copy the code
packageCom.cflong. JVM troubleshooting;import java.util.ArrayList;
import java.util.List;

/** * Simulates high memory usage **@author cflong
 * @date2021/05/08 18:06:44 * /
public class MemoryTakeHighTest {

    public static void test(a) throws InterruptedException {
        List<MemoryBean> list = new ArrayList<>(1000);
        int i = 0;
        while (i < 10000) {
            list.add(new MemoryBean("name".12.new String("Test large memory remarks, test large memory remarks," +
                    "Test large memory remarks, test large memory remarks, test large memory remarks," +
                    "Test large memory remarks, test large memory remarks, test large memory remarks," +
                    "Test large memory remarks, test large memory remarks, test large memory remarks,")));
            i++;
        }
        Thread.sleep(1000000000); }}Copy the code
package com.cflong;

importCom.cflong.JVM troubleshooting. MemoryTakeHighTest;import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class TestJvmOomApplication {

    public static void main(String[] args) throws Throwable {
        SpringApplication.run(TestJvmOomApplication.class, args);
        // Analog memory usage is too highMemoryTakeHighTest.test(); }}Copy the code

How to find memory problems

You can run the top command in Linux to query the memory usage of the server:After using the top command, the following image will appear. By default, the CPU is sorted by the server. We can adjust it for memory sorting, sorting different service keys differently.

  • Linux: Click “M” directly in the window to use memory sort, as shown below:

  • MacOS: Directly click o in the window, and the input box will appear. Enter “mem” in the input box and press enter, and the memory sort will be used, as shown below:

From the above table, we can see something like the following:We only know that this is a Java program, but is not necessarily our own program, and may not be our target Java program, then can through the life the ps – ef | grep pid (process) to query the process is the program, the following figure:

ps -ef|grep <pid>
Copy the code

Here we can find that the program is our own development, this time really into the JVM memory footprint check.

If you practice, you can use the JPS command to quickly find all the Java process numbers, as shown in the following figure

Find classes with high memory

jmap -histo

Jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo = jmap-histo

Of course, the problem may also occur in classes such as String and HashMap, which require more complex screening methods and are not within the scope of this study. We can discuss it later.

jamp -histo <pid> | head -20
Copy the code

​

jhat

Dump heap memory. If files are too large, run the jhat command on the server to check the heap memory status of dump files. Run the jmap command in the service area to dump heap information of the service.

Jamp -dump:format=b,file= file name. hporf <pid>Copy the code

In the command, format=b is a fixed value, file is the name of the dump file, and the suffix is hporf

If the dumped files are too large to be exported to the service area for analysis, you can run the jhat command to start the analysis service for memory analysis.

Jhat file name. Hporf (just dumped file)Copy the code

After executing the late command, the picture will appear, showing that the analysis service has been started, the port is 7000, we use the browser to access the IP :700 (I use Jhat locally, so the IP is localhost).

Let’s scroll down to the bottom and click on the Show Heap Histogram link

We can see that the heap hogs are in descending order, and that they contain a 10,000-object MemoryBean class that we built ourselves, which is where the problem class is located. ​

VisualVM

Dump heap memory, download the heap file to the local, using VisualVM to check the dump file heap memory status

How to install VisualVM is not described in detail here, we can search for it

Open VisualVM and click “File” “Load”.

Drop down select heap DUMP(.hprof,.*】, select the file dumped from the previous method

Select [Class] and we can see the descending order of the heap occupying classes. We can see that it contains a MemoryBean class of 10000 objects, which is the location of the problem class.

There are three simple ways to check for large JVM memory usage. Thank you for correcting any errors. If you think you have written well, you can follow me. I will update more good dry goods.