"Java in-depth study" 3, JVM memory management mechanism

Transferred from: http://blog.csdn.net/lengyuhong/article/details/5953544

Recently looked at the Java memory leakage of some cases, with the original several brothers discussed, in-depth research found that there are many in the JVM is still a lot of unknown details, here a little analysis. Let's take a look at the internal structure of the JVM--


, the JVM mainly consists of two subsystems and two components. The two subsystems are the class loader subsystem and the execution engine (execution engine) subsystem, and the two components are the runtime data area (run time) components and the native interface (local interface) components respectively.

The function of the class loader subsystem is to load the contents of a class file into the method area in the Runtime data zone, given a fully qualified name Class name (such as Java.lang.Object). Java programmers can extends Java.lang.ClassLoader classes to write their own class loader.

Execution Engine SUBSYSTEM: Executes the instructions in the classes. The core of any JVM specification implementation (JDK) is the execution engine, and the different JDK such as Sun's JDK and IBM's JDK are largely dependent on the quality of their respective execution engine implementations.

Native interface component: interacts with Native libraries and is an interface for other programming language interactions. When the native method is called, it enters a completely new world that is no longer restricted by the virtual machine, so it is also easy to have native heap OutOfMemory that the JVM cannot control.

Runtime Data Area component: This is what we often call the JVM's memory. It is mainly divided into five parts--
1. Heap: Only one heap space exists in a Java virtual instance
2. Method Area: The information of the loaded class is stored in the memory of method zone. When a virtual machine loads a type, it uses the class loader to locate the appropriate class file and then reads the class file contents and transfers it to the virtual machine.
3. Java stack (Java stacks): Virtual machines only perform two operations on the Java stack directly: stack or stack in frames
4, program Counter (Programs counter): Each thread has its own PC register, which is also created when the thread starts. The contents of the PC register always point to the next hungry address where the instruction will be executed, where the address can be either a local pointer or an offset relative to the method's start instruction in the method area.
5, Native method Stack (local methods stack): Save Native method to enter the address of the zone

Only the heap and method area are shared by all threads, while Java stack, program counter, and native method stack are thread-grained, each with its own part.

Understand the system structure of the JVM, and then look at the JVM memory recovery problem--
The principle of Sun's JVM generational collecting (garbage collection) is that it divides objects into younger generations (young), older generations (tenured), persistent generations (Perm), and uses different algorithms for objects of different lifecycles. (Based on the object life cycle analysis)


As shown, it is distributed across generations in the Java heap.
1. Young (younger generation)
The young generation is divided into three districts. One Eden area, two survivor districts. Most objects are generated in the Eden area. When the Eden Zone is full, the surviving objects will be copied to the Survivor area (one of two), and when the survivor area is full, the surviving objects of this area will be copied to another survivor area, when the survivor is full, Objects that are copied from the first survivor area and that are still alive will be duplicated in the old age zone (tenured. It should be noted that the two areas of the survivor are symmetrical and have no relationship, so the same area may exist at the same time from Eden copied objects, and from the previous survivor copied objects, and copied to the old quarter only from the first survivor to come over the object. Moreover, there is always an empty survivor area.
2. Tenured (old generation)
Older generations store objects that survive from younger generations. In general, older generations are storing long-term objects.
3. Perm (Permanent Generation)
Used to store static files, now Java classes, methods, and so on. The persistence generation has no significant impact on garbage collection, but some applications may dynamically generate or invoke some classes, such as Hibernate, at which point a large, persistent generation space is required to store the new class in these runs. The persistent generation size is set by-xx:maxpermsize=.

For example, when an object is generated in a program, the normal object allocates space in the younger generation, and if the object is too large, it may be generated directly in the old generation (it is observed that each time a program is run, a 10 trillion space is generated for sending and receiving messages, and this memory is allocated directly to the old generation). The young generation will initiate a memory recovery when the space is allocated, most of the memory will be recycled, a portion of the surviving memory will be copied to the survivor from zone, and after multiple collections, if the From zone memory is also allocated, then a memory recycle will occur and the remaining objects will be copied to the to area. When the to area is full, a memory recycle occurs and the surviving objects are copied to the old quarter.

Usually we say that the JVM memory recycle is always referred to as heap memory recycling, indeed only the content in the heap is dynamically requested to allocate, so the young and old generations of the above objects refer to the JVM's heap space, and the persistent generation is the previously mentioned method area, which is not part of the heap.

After understanding these, the following reprint a keen to delve into the technology of the buddy Richen Wang some suggestions on memory management--
1. Manually set the generated garbage object, the intermediate object to null, and speed up the memory reclamation.
2. Object pooling technology If the resulting object is a reusable object, but the attributes are not the same, you can consider using an object pool to produce fewer objects. If a free object is removed from the object pool, no new objects are generated, which greatly increases the object's reuse rate.
3, JVM tuning by configuring the parameters of the JVM to increase the speed of garbage collection, if there is no memory leak and the above two methods can not guarantee the recovery of memory, you may consider using the JVM tuning method to solve, but must go through the physical machine long-term testing, because different parameters may cause different effects. such as-XNOCLASSGC parameters.

Two recommended memory detection tools
1, Jconsole JDK comes with memory monitoring tool, path JDK bin directory under Jconsole.exe, double-click to run. There are two ways to connect, the first is the local way, such as the process that runs when debugging can be directly connected, the second is a remote way, you can connect the process started as a service. The remote connection is: Add-dcom.sun.management.jmxremote.port=1090-dcom.sun.management.jmxremote.ssl=false to the JVM startup parameters of the target process- Dcom.sun.management.jmxremote.authenticate=false 1090 is the port number of the listener to be modified when used, and then connect using the IP plus port number. This tool allows you to monitor the size of the memory at that time, the amount of CPU usage, and the loading of classes, as well as the functionality of the manual GC. The advantages are high efficiency, fast speed, monitoring the operation of the product without affecting the operation. The disadvantage is that you cannot see specific information such as classes or objects. The use of a few simple clicks to know how the function, there is no understanding of the Internet can query the document.

2, Jprofiler Charge of the tool, but everywhere there is a way to crack. After installation, configure the good one local session to run in the configuration debug mode. You can monitor memory, CPU, thread, and so on, which can be used to specify the memory usage, and can also be analyzed for a class. A lot of advantages, shortcomings too affect the speed, and some classes may not be woven into the method, for example, I use Jprofiler has not been successful backup, there will always be some class errors

A simple concept:

• Heap and non-heap (non-heap) memory
  According to the official statement, "Java virtual machines have a heap, the heap is a runtime data region, and all class instances and arrays of memory are allocated from here." The heap is created when the Java virtual machine is started. "" The memory outside the heap in the JVM is called non-heap (non-heap memory) ". You can see that the JVM primarily manages two types of memory: heap and non-heap. In a nutshell, a heap is a Java code-readable memory that is left to the developer, not a heap, which is left to itself by the JVM, so the method area, the JVM internally processes or optimizes the required memory (such as the JIT-compiled code cache), each class structure (such as running a constant pool, field, and method data) And the code for methods and construction methods are in non-heap memory.

• Heap memory allocation
  The initial memory allocated by the JVM is specified by-XMS, the default is physical memory 1/64;JVM the maximum allocated memory is specified by-XMX, which defaults to 1/4 of the physical memory. When the default free heap memory is less than 40%, the JVM increases the heap until the maximum limit of-xmx, and when the free heap memory is greater than 70%, the JVM reduces the heap until the minimum limit of-XMS. So the server generally sets-xms,-xmx equal to avoid resizing the heap after each GC.

• Non-heap memory allocation
  The JVM uses-xx:permsize to set the non-heap memory initial value, which defaults to 1/64 of the physical memory, and the maximum non-heap memory by Xx:maxpermsize, which by default is 1/4 of physical memory.

• JVM Memory Limit (max)
  First, the JVM memory is limited to the actual maximum physical memory (nonsense!). hehe), assuming that the physical memory is infinitely large, the maximum value of the JVM memory is very much related to the operating system. Simply put, 32-bit processor Although the controllable memory space has 4GB, but the specific operating system will give a limit, this limit is generally 2GB-3GB (generally under the Windows system is the 1.5g-2g,linux system is 2g-3g), and more than 64bit processors will not be limited

Articles in the same series:

Java Virtual machine Memory management mechanism (i): http://blog.csdn.net/lengyuhong/archive/2010/10/20/5953544.aspx

Java Virtual machine Memory management mechanism (ii): http://blog.csdn.net/lengyuhong/archive/2010/10/20/5953594.aspx

Java Virtual machine Memory management mechanism (III): Http://blog.csdn.net/lengyuhong/archive/2010/10/19/5952008.aspx

"Java in-depth study" 3, JVM memory management mechanism