JAVA memory analysis 1 – starting with two programs

This time, let's look at some content about JVM memory analysis.

Two procedures

Procedure I

First, let's look at two programs. Here is program 1: jvmstacktest. Look at the code below:

This class is very simple. The body of the jvmstacktest is a recur () method. The recur () method is a recursive method. The so-called recursive method is to call the method itself in the method body. In the recur () method, a class member variable count is referenced to record the number of recursions, and an output is made to prompt the end of method execution. The main method of jvmstacktest also has little content, that is, it creates an instance of jvmstacktest and calls the recur () method, uses try {} catch () {} to catch possible exceptions or errors, and finally outputs the number of recursions of the recur () method before the end of program execution.

There are some problems with this program. The problem lies in the recur () method: recur () is a recursive method, but there is no jump statement, which means that the recur () method will recurse indefinitely. We need to realize that resources are limited. If a service occupies resources indefinitely but never releases resources, it will inevitably lead to problems. Every time the recur () method is called, some resources will be occupied. Too much resources will lead to insufficient available resources and exceptions or errors. Run this program to see what errors will be reported:

After 1862 recursions, stackoverflowerror is reported, that is, stack overflow error. Please remember this error message first. We will explain why this error is reported later.

Procedure II

Let's look at program 2. Jvmheaptest:

The jvmhaptest is also very simple. It defines a list type class member variable list, specifies that the units stored in the list must be arrays through generics, and then continuously adds array instances to the list through the loop () method. The size of each array is 1024, that is, 1KB. The main method is also similar to jvmstacktest, that is, create a class instance to call the loop method, catch possible exceptions through try / catch, and finally output the length of the list at the end of program execution.

Looking at the loop () method, it is obvious that this class also has problems: the loop () method in this class has an endless loop, especially in this endless loop, it is still adding elements to a class member list. When the total size of the added elements exceeds a certain upper limit, an error will be reported. What is the specific error? Run it to see:

As expected, an error occurred. When an error occurs, the length of the list is 7 and the error reported is outofmemoryerror. According to the error message "Java heap space", it can be seen that the OUTOFMEMORY error occurs on the heap, that is, on the heap.

Through these two programs, we demonstrate two common memory errors: stackoverflow and OUTOFMEMORY, namely stack overflow and memory overflow. These two errors have one thing in common: they occupy a certain part of the system resources (infinite recursion of program 1 and dead loop of program 2) without limit, so that they exceed a certain upper limit. What we need to understand is what the resources here are and what the upper limit is.

JVM memory overview

As for resources, we have repeatedly mentioned several times before, mainly memory. However, compared with the memory we usually mention, the memory here is more finely divided. We usually say that the notebook has 4G memory and 8g memory, which is the machine memory of the notebook. This memory is called direct memory or physical memory. When we start a java program, we will get a space for the JVM to use independently from the direct memory, which can be called JVM memory. JVM memory can be roughly divided into two categories: stack memory and heap memory. As shown below:

Note that it is a very rough method to divide memory into stack memory and heap memory. We will talk about the exact method later.

Look at the figure above. The slender bar on the left identifies stack memory and the ellipse on the right identifies memory. Stack memory is usually much smaller than heap memory.

Stack memory

The stack memory stores the information of method execution, including local variable table, operation stack, dynamic link, method exit and so on. I wonder if you have noticed that there are smaller rectangles in the identification diagram of stack memory. This small rectangle identifies the stack frame. Stack frame is the smallest unit of stack memory. Each time a method is executed, a stack frame is created. Each process from calling a method to execution completion corresponds to the process of a stack frame from entering the stack to leaving the stack in the virtual machine stack.

At this point, we can go back to our first program. We now know what resources are occupied by this program, resulting in stackoverflow. There is an infinite recursion in the recur () method in jvmstacktest, which will create infinite stack frames for the recur () method. When the virtual machine can no longer create stack frames, a stackoverflow error will be generated.

There is another point to note here. Some books have mentioned that if the stack depth requested by a thread is greater than the depth allowed by the virtual machine, a stackoverflowerror exception will be thrown; If the virtual machine stack can be expanded dynamically, an outofmemoryerror exception will be thrown when enough memory cannot be applied for during expansion. This statement is correct, but there is some overlap: because the stack can be dynamically expanded, the virtual machine cannot continue to create stack frames. Is it beyond the stack depth or insufficient stack memory. This problem is inconclusive, but I have tested it many times and thrown stackoverflow errors. But don't forget that it is theoretically possible to throw OUTOFMEMORY errors.

Heap memory

Generally, it can be considered that heap memory is the largest part of JVM memory, where almost all object instances are stored. Heap memory is also the main area of garbage collection management.

Our second program keeps adding long arrays to the list through an endless loop, which takes up a lot of heap space. Finally, if there is not enough space to store new instances, OUTOFMEMORY error will be generated. Why is there no garbage collection in this program? Because our object instances, that is, those arrays, are stored in a class member list. This class member list is always referenced, and its contents cannot be recycled. We will explain the content of garbage collection in detail later, so we won't mention it here.

Only OUTOFMEMORY errors will occur in this area of heap memory.

Some configuration of JVM

As we said earlier, stackoverflow and OUTOFMEMORY are generated because "too many system resources are occupied, exceeding an upper limit". We already know what system resources are. What is the upper limit. There are three configuration items:

The default value of XSS is 1m;

The default value of XMS is 1 / 64 of the direct memory;

The default value of Xmx is 1 / 4 of direct memory.

In the IDE, this configuration can be completed at the following locations:

You can try to adjust these configurations to see if the results are different.

Well, that's all for today. Bye!

##########################