A little thought and practice of Java Memory Architecture

In some high-concurrency programs, or a lot of memory for the calculation of the program, sometimes encountered some of the problems: The program just started to run very fast, and then run slowly down, even to a certain time there will be oom or StackOverflow and other errors. To understand the root causes of these errors, it is necessary to understand how the JVM divides, manages, and reclaims memory, and this blog will discuss these topics from the perspective of bloggers ' knowledge of the JVM and practical experience.

JVM Memory Structure

Once in the memory structure of the JVM, I am afraid there will be a lot of terminology: new generation? Laosheng generation? Permanent generation? Wait, let's just leave these names behind, based on our Java Foundation, what should it look like?

First: The program is multi-threaded (single thread is just one extreme of multithreading), to know that the CPU is switching back and forth between multiple threads, is to keep contextual information, then this information should be stored. To put it simple, at least every thread should know that if the CPU is going to execute itself, where should it start? So in the JVM memory structure, there should be a zone a, and the a zone should be the exclusive area of each thread.

Second: Whether it is the code we write, or the use of third-party tools, it is necessary to load the class loader, which indicates that there should be a region B dedicated to store this information, such as compiled classes, methods, constant pool and so on. Have we ever encountered an OOM error when the server started? This may be due to the fact that the server startup memory is small and requires too much load class. This area B should be open-shared for each thread.

Third: From the beginning of learning Java, we know the concept of memory heap and stack, and we all say that the new object is stored in the heap, to know that Java is object-oriented, so that this piece should occupy a larger space, but also memory management, recycling a core point. heap, which every thread can access, if the heap is running out of space, but still needs to allocate space for the object, it will be oom.

Four: Since the above mentioned heap, then the following will have to say the concept of the stack. In multi-threading, we want to form a stack closure to achieve thread-safe purposes, such as threadlocal, using local variables instead of member variables. In fact, the stack space is the private of each thread, the stack is stored in the method of local variables, methods, such as entry information. Each call method involves both the stack and the stack, and if there is a recursive method called thousands of or even tens of thousands of times, it is possible to throw StackOverflow because so much information in the stack causes the stack to overflow.

Synthesis above, in fact, we will easily get the following:

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M01/7E/D4/wKioL1cKEliwEfW2AAArv8UmPoc364.png "title=" Sogou _ 2016-04-10_16-40-52.png "alt=" Wkiol1ckeliwefw2aaarv8umpoc364.png "/>

The program counter, which is referred to above as a area, the method area is the B area.

Based on the above discussion, the program counters and stacks follow the thread's lifecycle, and the heap and method areas are managed by the JVM's GC mechanism, so let's discuss the generational garbage collection mechanism in the JVM.

Generational garbage collection mechanism

The JVM subdivided the heap into 2 generations: The new generation, the Laosheng generation (the old age), and the method area called the permanent generation. Let's look at a diagram first:

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/7E/D7/wKiom1cKGVDDi0mpAAApSBi2-GU657.png "title=" Sogou _ 2016-04-10_17-13-42.png "alt=" Wkiom1ckgvddi0mpaaapsbi2-gu657.png "/>

The new generation, young genration, is divided into 3 parts, one eden,2 survior. The so-called Eden, the Garden of Eden, as the name implies, is actually a new life, happiness, and survior means survivors. If the object is created, it will be allocated in Eden First, if Eden is insufficient, a minor GC will be done, the Eden can be emptied out, if not recycled, let it enter a survior area, so that the concept of Survivor is out, in fact, is essentially a replication recovery algorithm. So why do we have 2 Survior? Because if eden+1 a survior to minor GC, another survior play a role, apparently one of the 2 Survior is free. Then we should make Eden more space, or the frequent minor GC will consume resources.

Laosheng generation, that is, old genration/tenured genration. If there is not enough space in the young genration area and there are multiple minor GC occurrences, copy the part of young genration into the Laosheng generation area. In fact, this involves an object age problem. When the old Genration area is insufficient, full GC is performed. Knowing the full GC is time-consuming, and if the JVM performs a full GC during the execution of the program, it can seriously affect performance, resulting in a significant increase in program execution time.

Permanent generation, that is, permant generation. Generally do not participate in garbage collection.

From the above analysis, we have found that the new generation, Laosheng generation, the permanent generation of space size in fact may affect our program execution effect, because their size will affect the JVM GC, so we should pay attention to the settings of these parameters.

JVM parameter settings

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M01/7E/D8/wKiom1cKH2rjxQjeAAB3_fr17HM539.png "title=" Sogou _ 2016-04-10_17-39-44.png "alt=" Wkiom1ckh2rjxqjeaab3_fr17hm539.png "/>

-XMS: Heap Initialization size

-XMX: Maximum size of the heap

-xmn:young size of Geration

-XSS: Stack size

-xx:permsize: The initial size of the permanent generation

-xx:maxpermsize: Maximum size for permanent generation

......

How do I monitor the JVM status of a program under Linux?

Under Linux, what do you do if you want to monitor the application's JVM memory usage, such as Eden,s0,s1,ygc,full GC?

First of all, we want to find the program in Linux running PID, very simple, we can use top or PS to find. Here, we think, if it is a multi-threaded program, such as 10 threads to start, whether in the top or PS there will be 10 such a Java command process it? So what exactly is the situation? Let's start by looking at:

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M01/7E/D8/wKiom1cKJGTguweYAABzjEJsN_E574.png "title=" Sogou _ 2016-04-10_18-00-59.png "alt=" Wkiom1ckjgtguweyaabzjejsn_e574.png "/>

The-h option for top is clearly stated: All thread information below this process will be printed. That is, a program that launches multiple threads, the next thread in Linux will correspond to a process!

At this point, we can use Jstack to further analyze the thread's dump file:

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/7E/D5/wKioL1cKJhiDetsKAACWujw9FVA711.png "title=" Sogou _ 2016-04-10_17-59-49.png "alt=" Wkiol1ckjhidetskaacwujw9fva711.png "/>

We can easily get the names of these threads, the priority, the TID (a unique indication of the thread in Java), the NID (which converts the 16-digit number into 10, and the PID in the Top/ps), the running state information, and so on.

Further, we can also use Jstat to analyze memory usage:

650) this.width=650; "src=" Http://s1.51cto.com/wyfs02/M01/7E/D6/wKioL1cKTgqCZZqkAAAgVUm-7mg971.png "title=" Sogou _ 2016-04-10_20-55-21.png "alt=" Wkiol1cktgqczzqkaaagvum-7mg971.png "/>

"About Jstat can use man jstat to get help information."

Through the Jstat command, we will be clear at a glance the process of the new generation, Laosheng generation, the proportion of permanent generations, the number of GC and time-consuming information.

This article is from the "Boundless Mind Infinite" blog, please be sure to keep this source http://zhangfengzhe.blog.51cto.com/8855103/1762431

A little thought and practice of Java Memory Architecture