1. Java code compilation and execution process
1. Source code compilation: compile Java code into JVM bytecode (.class file) through Java source code compiler
2. Class loading: Class loading of the JVM is completed through ClassLoader and its subclasses
3. Class execution: the bytecode is loaded into the memory, enters the JVM virtual machine, and is interpreted and executed by the interpreter
Note: The Java platform is built by the Java virtual machine and the Java application program interface, and the Java language is the channel to enter the platform.
Programs written and compiled in the Java language can run on this platform
2. Introduction to JVM
1. After the java program is compiled once, the java code is compiled into a bytecode, that is, a class file, and then interpreted on different operating systems by relying on different java virtual machines, and finally converted into machine codes of different platforms, and finally obtained implement
2. The Java virtual machine (JVM) is at the core, which is the key that the program has nothing to do with the underlying operating system and hardware.
Below the JVM is the porting interface. The porting interface consists of two parts: the adapter and the Java operating system. The part that depends on the platform is called the adapter. The JVM is implemented on the specific platform and operating system through the porting interface.
Above the JVM are Java's basic class library and extended class library and their APIs. Applications and small programs (Java applets) written using Java APIs can run on any Java platform regardless of the underlying platform.
The Java virtual machine (JVM) realizes the separation of the program and the operating system, thereby realizing the cross-platform of Java
3. The 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 the JVM is generated; when the program finishes running, the instance also disappears
4. Three kinds of JVM: ① HotSpot of Sun Company ② JRockit of BEA Company ③ J9 JVM of IBM Company
In JDK1.7 and before, we used Sun’s HotSpot, but since both Sun and BEA were acquired by oracle, jdk1.8 will use the essence of Sun’s HotSpot and BEA’s JRockit to form The JVM of jdk1.8.
3. JVM architecture
1.Class Loader class loader
Responsible for loading .class files, class files have a specific file mark at the beginning of the file, and ClassLoader is responsible for loading class files, etc. As for whether it can run, it is determined by the Execution Engine.
① Locate and import binary class files
② Verify the correctness of imported classes
③ Allocate initialization memory for the class
④ Help resolve symbol references.
2. Native Interface local interface
The role of the local interface is to integrate different programming languages for Java. Its original intention is to integrate C/C++ programs. When C/C++ was rampant when Java was born, if you want to gain a foothold, you must call C/C++ programs, so in A special area is opened up in the memory for processing marked as
Native code, its specific method is to register the native method in the Native Method Stack, and load the native libraies when the Execution Engine executes.
At present, this method is used less and less, except for hardware-related applications, such as driving printers through Java programs, or Java system management production equipment, which is relatively rare in enterprise-level applications.
Because the communication between heterogeneous fields is very developed now, for example, Socket communication can be used, and Web Service can also be used.
3. Execution Engine Execution engine: Execute the instructions wrapped in the method of loading the class, that is, the method.
4.Runtime data area running data area (ie: virtual machine memory or JVM memory introduced in the next section)
Open up a piece of memory from the entire computer memory to store objects, variables, etc. that Jvm needs to use, divided into: method area, heap, virtual machine stack, program counter, and local method stack.
Four, 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), and the execution engine reads the next instruction, which is a very small memory space. Almost negligible.
The program counter (Program Counter Register) is a small memory space, and its function can be regarded as the line number indicator of the bytecode executed by the current thread. In the conceptual model of the virtual machine (only a 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 one to be executed Basic functions such as bytecode instructions, branches, loops, jumps, exception handling, and thread recovery all need to rely on this counter to complete. Since the multithreading of the Java virtual machine is realized by switching threads in turn and allocating processor execution time, at any given moment, a processor (a core for a multi-core processor) will only execute one thread instructions in . Therefore, in order to return to the correct execution position after thread switching, each thread needs to have an independent program counter. The counters between threads do not affect each other and are stored independently. We call this type of memory area "thread private". " memory. If the thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed; if the thread is executing a Natvie method, the counter value is empty (Undefined). This memory region is the only one that does not specify any OutOfMemoryError conditions in the Java Virtual Machine Specification.
2. Native Method Stack
Register the native method in the Native Method Stack, and load the native libraies when the Execution Engine executes
The local method stack is basically similar to the virtual machine stack, the difference is that the virtual machine stack serves the Java method executed by the virtual machine, while the local method stack serves the Native method
3. Method Area
Used to store virtual machine loading: static variables + constants + class information + runtime constant pool (class information: class version, field, method, interface, constructor and other description information)
The default minimum value is 16MB, and the maximum value is 64MB. The size of the method area can be limited by the -XX:PermSize and -XX:MaxPermSize parameters
For developers who are accustomed to developing and deploying programs on the HotSpot virtual machine, many people are willing to call the method area "Permanent Generation" (Permanent Generation). The two are not equivalent in essence, just because the HotSpot virtual machine The design team chose to extend the GC generational collection to the method area, or use the 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 for the HotSpot virtual machine itself, according to the official roadmap information, there is now a plan to abandon the permanent generation and "move" to Native Memory to implement the method area. The Java virtual machine specification has very loose restrictions on this area. In addition to not requiring continuous memory like the Java heap and can choose a fixed size or expandable, you can also choose not to implement garbage collection. Relatively speaking, garbage collection behaviors rarely occur in this area, but it does not mean that data enters the method area and exists "permanently" like the name of the permanent generation. The goal of memory recovery in this area is mainly for the recovery of constant pools and the unloading of types. Generally speaking, the recovery "score" in this area is relatively unsatisfactory, especially the unloading of types. The conditions are quite harsh, but in this part of the area Recycling is indeed necessary. In Sun's BUG list, several serious BUGs have appeared because the low-version HotSpot virtual machine did not fully reclaim this area, resulting in memory leaks. According to the Java virtual machine specification, when the method area cannot meet the memory allocation requirements, an OutOfMemoryError exception will be thrown.
4. Stack JVM Stack
Various basic data types known to the compiler (boolean, byte, char, short, int, float, long, double), object reference (reference pointer, not the object itself)
The stack is the memory model for java method execution:
When each method is executed, a "stack frame" is created to store local variable table (including parameters), operation stack, method exit and other information.
The process from the call to the execution of each method corresponds to the process of a stack frame from pushing to popping in the virtual machine stack.
(Local variable table: stores various basic data types known to the compiler (boolean, byte, char, short, int, float, long, double), object reference (reference pointer, not the object itself),
Among them, the 64-bit long and double type data will occupy the space of 2 local variables, and the other data types will only occupy 1 space.
The memory space required by the local variable table is allocated during compilation. When entering a method, how many local variables this method needs to allocate in the stack frame is completely determined. The stack frame will not change the size of the local variable table during operation. space)
The life cycle of the stack follows the life cycle of the thread. It is created when the thread is created, and the stack memory is released when the thread ends, which is private to the thread.
5. Heap Java Heap
All object instances and arrays are allocated on the heap, and the sole purpose of this memory area is to store object instances
The heap is the largest chunk of memory managed by the Java virtual machine. The Java heap is a memory area shared by all threads, created when the virtual machine starts
The heap is the most important area to understand the Java GC mechanism, no one
Structure: Cenozoic generation (Eden area + 2 Survivor areas) Old generation permanent generation (HotSpot has)
New generation: newly created objects --> Eden area
After GC, the surviving objects enter Survivor area 1 from Survivor area 0 in Eden area
GC again, the surviving objects enter Survivor area 0 from Survivor area 1 in Eden area
Old generation: If the object has survived long enough in the young generation without being cleaned up (that is, it has survived several Young GCs), it will be copied to the old generation
If the newly created object is relatively large (such as a long string or a large array), and the space in the new generation is insufficient, the large object will be directly allocated to the old generation (large objects may trigger early GC, so it should be used less, and short-lived large objects should be avoided. object)
The space of the old generation is generally larger than that of the new generation, which can store more objects, and the number of GCs that occur in the old generation is less than that of the young generation
Permanent Generation: It can be simply understood as a method area (the two are not equivalent in essence)
As mentioned above: For developers who are accustomed to developing and deploying programs on the HotSpot virtual machine, many people are willing to call the method area "permanent generation", and the two are not equivalent in essence.
It's just because the design team of the HotSpot virtual machine chose to extend the GC generational collection to the method area, or use the 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 for the HotSpot virtual machine itself, according to the official roadmap information, there is now a plan to abandon the permanent generation and "move" to Native Memory to implement the method area
Jdk1.6 and before: the constant pool is allocated in the permanent generation
Jdk1.7: Yes, but it has been gradually "going to the permanent generation"
Jdk1.8 and later: no permanent generation (java.lang.OutOfMemoryError: PermGen space, this error will not appear in JDK1.8)
6. Direct memory Direct Memor
Direct memory is not managed by the JVM. It can be understood that direct memory is machine memory other than the JVM. For example, if you have 4G of memory and the JVM occupies 1G, the remaining 3G is direct memory.
There is a memory allocation method based on channels (Channel) and buffers (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.
Since the direct memory is limited by the memory of the machine, the exception of OutOfMemoryError may also occur.