I recently looked at some cases of Java Memory leakage and discussed it with several old buddies. I found that there are still many details that I didn't know before in the JVM. I will analyze them a little here. Let's take a look at the internal structure of JVM --
JVM mainly includes two subsystems and two components. The two subsystems are the class loader subsystem and the execution engine subsystem. The two components are the runtime data area component and the Native Interface component.
Function of the Class Loader subsystem: loads the content of the class file to the Method Area in the runtime data area based on the given fully qualified name class name (such as Java. Lang. object ). Java programmers can use the extends java. Lang. classloader class to write their own class loader.
Execution engine subsystem: executes commands in classes. The core of any JVM specification implementation (JDK) is the execution engine. Different JDK, such as Sun's JDK and IBM's JDK, depend mainly on their respective execution engine.
Native Interface Component: it interacts with native libraries and is an interface for interaction with other programming languages. When the native method is called, it enters a completely new world that is no longer subject to virtual machine restrictions. Therefore, it is easy to see native heap outofmemory that cannot be controlled by JVM.
Runtime data area component: This is what we often call JVM memory. It is mainly divided into five parts --
1,Heap(HEAP): Only one heap space exists in a Java virtual instance.
2,Method Area (Method Area): information about the mounted class is stored in the memory of the method area. When a virtual machine loads a type, it uses the class loader to locate the corresponding class file, then reads the class file content and transmits it to the virtual machine.
3,Java stack(Java stack): virtual machines only execute two types of operations directly on java stack: frame-based pressure stack or outbound stack.
4,Program counter(Program counter): Each thread has its own PC register, which is also created when the thread is started. The content of the PC register always points to the next address that will be executed. The address here can be a local pointer or offset corresponding to the start instruction of the method in the method area.
5,Native method Stack(Local method stack): the address for saving the native method to enter the Region
In the preceding five parts, only heap and method area are shared and used by all threads. java stack, program counter, and Native method Stack are thread-specific, each thread has its own part.
To understand the JVM system structure, let's take a look at the JVM memory reclaim problem --
Sun's JVM generational collecting principle is as follows: dividing objects into young, tenured, and perm ), use different algorithms for objects of different lifecycles. (Based on Object lifecycle analysis)
Shows the Generation Distribution in the Java heap.
1. Young (young generation)
The young generation is divided into three zones. One Eden zone and two vor zones. Most objects are generated in the Eden area. When the Eden zone is full, the surviving objects will be copied to the primary vor zone (one of the two). When the primary vor zone is full, the surviving objects in this region will be copied to another region vor. When the region VOR is full, the surviving objects will be copied from the first region vor, will be copied to the old area (tenured. Note that the two regions of the same vor are symmetric and irrelevant. Therefore, the same zone may be copied from Eden at the same time.
Objects, and objects copied from the previous primary vor, but only objects copied from the first primary vor in the old area. In addition, there is always a blank vor area.
2. tenured (elder generation)
The old generation stores objects that survive from the young generation. Generally, the old generation stores objects with long life periods.
3. Perm (permanent generation)
Used to store static files. Currently, Java classes and methods are supported. Persistent generation has no significant impact on garbage collection, but some applications may dynamically generate or call some classes, such as hibernate, in this case, you need to set up a large persistent storage space to store the classes added during the running process. The persistent generation size is set through-XX: maxpermsize =.
For example, when an object is generated in a program, a normal object will allocate space in the young generation, if the object is too large, it may also be generated directly in the old generation (it is observed that a 10 MB space is generated each time when a program is running, and messages are sent and received, this part of memory will be allocated directly in the old generation ). The young generation will initiate memory reclaim when the space is allocated. Most of the memory will be recycled, and some of the surviving memory will be copied to the from Area of the same vor, after multiple recycles, if the from Area Memory is allocated, the memory will be recycled and the remaining objects will be copied to the to area. When the to zone is full, memory will be recycled again and the surviving objects will be copied to the old zone.
Generally, we say that JVM memory recycling always refers to heap memory recycling. It is true that only the content in the heap is dynamically applied for allocation, therefore, the young and old generations of the above objects refer to the heap space of the JVM, while the persistent generation is the method area mentioned earlier and does not belong to the heap.
After learning about this, I will repost some suggestions on memory management from richen Wang, a tech-savvy guy --
1. manually set the generated useless object and the intermediate object to null to accelerate memory recovery.
2. Object pool technology if the generated object is a reusable object, but its attributes are different, you can use the object pool to generate fewer objects. If there are idle objects, they will be taken out and used from the object pool, without generating new objects, which greatly improves the object reuse rate.
3. JVM tuning improves the garbage collection speed by configuring JVM parameters. If memory leakage does not occur and the above two methods cannot guarantee the garbage collection, you can consider using JVM optimization, but it must be tested on the physical machine for a long time, because different parameters may cause different effects. For example, the-xnoclassgc parameter.
Two recommended memory detection tools
1,Jconsole JDKThe built-in memory monitoring tool is available in the jconsole.exe directory of JDK bindirectory. You can double-click it to run it. There are two connection modes: the first is local mode, for example, the process running during debugging can be directly connected, and the second is remote mode, which can be connected to the process started as a service. Remote connection: Add-DCOM. Sun. Management. jmxremote. Port = 1090 to the JVM startup parameter of the target process.
-DCOM. sun. management. jmxremote. SSL = false-DCOM. sun. management. jmxremote. authenticate = false 1090 indicates that the listening port number must be modified when used, and then connected by IP and port number. The tool can monitor the memory size, CPU usage, and class loading at that time, and also provides the manual GC function. The advantage is high efficiency and fast speed. It can monitor the operation of the product without affecting its operation. The disadvantage is that you cannot see specific information such as classes or objects. The usage method is simple. You can click a few times to know how the function works. If you do not understand it, You can query documents online.
2,JprofilerBilling tools, but there are solutions everywhere. After the installation is complete, configure a local session according to the configuration debugging method to run. It can monitor the memory, CPU, thread, and so on at that time, specifically list the memory usage, and analyze a class. There are many advantages and disadvantages that affect the speed, and some classes may not be woven into the method. For example, when I use jprofiler, the backup has never been successful, and there will always be some class errors.