Shulou(Shulou.com)06/03 Report--

This article will explain in detail the example analysis of the memory structure of JVM. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

I. the process of compiling and executing java code

Source code compilation: Java code is compiled into JVM bytecode (.class file) through the Java source code compiler

Class loading: class loading of JVM is completed through ClassLoader and its subclasses

Class execution: bytecode is loaded into memory, entered into the JVM virtual machine, and interpreted and executed by the interpreter

Note: the Java platform is built by Java virtual machine and Java application interface, and Java language is the channel to enter this platform.

Programs written and compiled in Java can run on this platform

II. Brief introduction of JVM

After compiling the 1.java program once, the java code is compiled into bytecode, that is, the class file, which is then interpreted by different java virtual machines on different operating systems. Finally, it is converted into machine code for different platforms, and finally executed.

The 2.Java virtual machine (JVM) is in the core position, which is the key that the program has nothing to do with the underlying operating system and hardware.

Below the JVM is the port interface, which consists of two parts: the adapter and the Java operating system, in which the part that depends on the platform is called the adapter. JVM is implemented on the specific platform and operating system through the port interface.

At the top of JVM are the basic class libraries and extension class libraries of Java and their API. Applications written in Java API (application) and Mini Program (Java applet) can run on any Java platform regardless of the underlying platform.

The Java virtual machine (JVM) separates the program from the operating system, thus realizing the cross-platform of Java.

3.JVM has a clear task in its life cycle, which is to run the Java program, so when the Java program starts, an instance of JVM is generated; when the program ends, the instance disappears.

4. Three kinds of JVM: ① Sun's HotSpot ② BEA's JRockit ③ IBM's J9 JVM

In JDK1.7 and before, we all use Sun's HotSpot, but as both Sun and BEA are acquired by oracle, jdk1.8 will use the essence of Sun's HotSpot and BEA's JRockit to form jdk1.8 's JVM.

III. JVM architecture

1.Class Loader class loader

Responsible for loading .class files, the class file has a specific file tag at the beginning of the file, and ClassLoader is responsible for loading the class file, etc., and whether it can be run or not is decided by Execution Engine.

① locates and imports binary class files

② verifies the correctness of the imported class

③ allocates initialization memory for classes

④ helps parse symbolic references.

2.Native Interface local interface

The function of the local interface is to integrate different programming languages for the use of Java. Its original intention is to integrate the CAccord Cure + program. When the Java was born, when it ran rampant, in order to gain a foothold, there must be a call to the Cmax Cure + program, so a special area was opened up in memory to process the program marked as

The code for native, which does this by registering the native method in Native Method Stack and loading native libraies when Execution Engine is executed.

At present, this method is used less and less, unless hardware-related applications, such as driving printers through Java programs, or managing production devices in Java systems, are rare in enterprise applications.

Because now the communication between heterogeneous fields is very developed, for example, you can use Socket communication, you can also use Web Service and so on.

3.Execution Engine execution engine: executes the instructions of the package in the method that loads the class, that is, the method.

4.Runtime data area running data area (i.e. virtual machine memory or JVM memory described in the next section)

Open up a piece of memory to store objects and variables needed by Jvm from the whole computer memory, which is divided into: method area, heap, virtual machine stack, program counter, local method stack.

Fourth, JVM memory structure

1. Program counter PC Register

Each thread has a program calculator, which is a pointer to the method bytecode in the method area (the next instruction code to be executed). The next instruction is read by the execution engine, which is a very small memory space. almost negligible.

A program counter (Program Counter Register) is a small piece of memory that can be seen as a line number indicator of the bytecode executed by the current thread. In the conceptual model of virtual machines (only the conceptual model, various virtual machines may be implemented in some more efficient ways), the bytecode interpreter works by changing the value of this counter to select the next bytecode instruction to be executed, and basic functions such as branching, looping, jumping, exception handling, thread recovery and so on all rely on this counter. Because the multithreading of the Java virtual machine is realized by the thread switching in turn and allocating the processor execution time, at any given moment, a processor (a core for a multi-core processor) will only execute instructions in one thread. Therefore, in order to restore to the correct execution position after thread switching, each thread needs to have an independent program counter, and the counters between each thread do not affect each other and store independently. We call this kind of memory area "thread private" memory. If the thread is executing a Java method, the counter records the address of the executing virtual machine bytecode instruction; if the Natvie method is being executed, the counter value is Undefined. This memory region is the only one that does not specify any OutOfMemoryError conditions in the Java virtual machine specification.

two。 Local method stack Native Method Stack

Register the native method in Native Method Stack and load native libraies when Execution Engine is executed

The local method stack is basically similar to the virtual machine stack, except that the virtual machine stack serves the java methods executed by the virtual machine, while the local method stack serves the Native methods.

3. Method area Method Area

Used to store virtual machine load: static variable + constant + class information + runtime constant pool (class information: description information of class version, field, method, interface, constructor, etc.)

The default minimum value is 16MB and the maximum value is 64MB. You can limit the size of the method area through the-XX:PermSize and-XX:MaxPermSize parameters.

For developers who are used to developing and deploying programs on the HotSpot virtual machine, many people like to call the method area "Permanent Generation". In essence, the two are not equivalent, simply because the design team of the HotSpot virtual machine chooses to extend the GC generational collection to the method area, or to use permanent generation to implement the method area. For other virtual machines (such as BEA JRockit, IBM J9, etc.), there is no concept of permanent generation. Even the HotSpot virtual machine itself, according to the official roadmap information, now has plans to abandon the permanent generation and "move" to Native Memory to implement the method zone. The Java virtual machine specification has very loose restrictions on this area, and you can choose not to implement garbage collection in addition to not requiring contiguous memory and having the option of fixed size or expandability like the Java heap. Relatively speaking, garbage collection behavior is relatively rare in this area, but it is not that the data enters the method area as "permanent" as the name of the permanent generation. The goal of memory recovery in this area is mainly aimed at constant pool recovery and type unloading. Generally speaking, the recovery "results" of this area are not satisfactory, especially type unloading, and the conditions are very harsh. But the recovery of this part of the area is really necessary. Several serious BUG that have appeared in Sun's BUG list are caused by memory leaks due to incomplete recycling of this area by an earlier version of the HotSpot virtual machine. According to the Java virtual machine specification, an OutOfMemoryError exception will be thrown when the method zone cannot meet the memory allocation requirements.

4. Stack JVM Stack

Various basic data types known to the compiler (boolean, byte, char, short, int, float, long, double), object references (reference pointers, not objects themselves)

The stack is the memory model for java method execution:

When each method is executed, a "stack frame" is created to store local variables (including parameters), operation stack, method exit, and so on.

Each method is called to the process of execution, corresponding to a stack frame in the virtual machine stack from the stack to the stack process.

(local variable table: stores various basic data types known to the compiler (boolean, byte, char, short, int, float, long, double), object references (reference pointers, not objects themselves)

Of these, 64-bit data of long and double types takes up space for two local variables, while only one of the remaining data types.

The memory space required by the local variable table is allocated during compilation. When entering a method, how many local variables need to be allocated in the stack frame is completely determined. The stack frame does not change the size space of the local variable table during operation)

The lifetime of the stack follows the lifetime of the thread. When the thread is created, the stack memory is released at the end of the thread, which is private to the thread.

5. Heap Java Heap

All object instances and arrays are allocated on the heap, and the only purpose of this memory area is to store object instances.

The heap is the largest block of memory managed by the Java virtual machine. The Java heap is an area of memory shared by all threads and is created when the virtual machine starts.

Heap is the most important area to understand the Java GC mechanism.

Structure: Cenozoic (Eden region + 2 Survivor zones) old age and permanent generation (HotSpot has)

New Generation: newly created object-- > Eden area

After GC, the surviving object enters Survivor area 1 from Survivor area 0 in Eden area.

GC again, the surviving object enters Survivor area 0 from Survivor area 1 of Eden area.

Old age: if the object survives long enough in the new generation without being cleaned up (that is, after several Young GC), it will be copied to the old age.

If the newly created object is relatively large (such as a long string or a large array) and there is insufficient space in the new generation, the large object will be allocated directly to the old age (large objects may trigger advance GC, should be used less, and short-lived large objects should be avoided)

The space of the old age is generally larger than that of the new generation, it can store more objects, and the frequency of GC in the old age is less than that of the younger generation.

Permanent generation: can be simply understood as the method area (in essence, the two are not equivalent)

As mentioned above: for developers who are used to developing and deploying programs on HotSpot virtual machines, many people like to call the method area "permanent generation", which is not equivalent in nature.

Simply because the design team of the HotSpot virtual machine chose to extend GC generational collection to the method area, or to use permanent generations to implement the method area.

There is no concept of permanent generation for other virtual machines (such as BEA JRockit, IBM J9, etc.)

Even the HotSpot virtual machine itself, according to the official roadmap information, now has plans to give up the permanent generation and "move" to Native Memory to implement the method area.

Jdk1.6 and before: constant pool allocation in the permanent generation

Jdk1.7: yes, but it has been gradually replaced permanently.

Jdk1.8 and beyond: no permanent generation (java.lang.OutOfMemoryError: PermGen space, this kind of error will not appear in JDK1.8)

6. Direct memory Direct Memor

Direct memory is not memory managed by JVM. It can be understood that direct memory is machine memory other than JVM. For example, if you have 4G memory and JVM occupies 1G, then the rest of 3G is direct memory.

There is a memory allocation method based on channel (Channel) and buffer (Buffer) in JDK. The native function library implemented by C language is allocated in direct memory and referenced by DirectByteBuffer stored in the JVM heap.

OutOfMemoryError exceptions may also occur because the direct memory is limited by the memory of the local machine.

This is the end of this article on "sample Analysis of JVM memory structure". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.