JVM for JVM architecture
The composition of JDK
JDK: THE JDK is a Java development kit, designed by Sun Microsystems for Java developers. The JDK contains the Java runtime runtime (JRE). The Java runtime (JDK) installation directory contains the Java runtime (JRE) folder bin and the Java runtime (lib) folder. The JVM and lib together are called jre) and a bunch of Java tools (javac/ Java/JDB, etc.) and Java base libraries (i.e., Java apis including Rt.jar).
Java Runtime Environment (JRE) : it is an indispensable Runtime Environment for running programs based on the Java language. It also allows Java developers to distribute their applications to users for use. The JRE contains the Java Virtual Machine (JVM), Runtime Class libraries, and Java Application Launcher, which are necessary components for running Java programs.
JVM (Java Virtual Machine) : Is commonly referred to as the Java virtual machine, which is the core part of the entire Java implementation cross-platform, all Java programs will be first compiled into a. Class class file, which can be executed on the VIRTUAL machine.
The location of the JVM
A JVM is a piece of software that runs on top of an operating system
JVM architecture
Class loader runtime data area JVM memory model execution engine
Class loading subsystem
====================== class loader =======================
The ClassLoader is responsible for loading class files (classs files have specific file identifiers at the beginning of the file), loading the class file’s bytecode contents into memory, and converting these contents into runtime data structures in the method area. The ClassLoader is only responsible for loading the class file, and whether it can run is determined by the Execution Engine.
Class loaders are Also Java classes, and they also need the class loader to load into memory. Obviously, the first class loader that is not a Java class must be used to do this work. This is BootStrap. Is responsible for loading virtual machine recognized libraries (such as rt.jar, rt.jar) stored in D: Program Files (x86)\Java\jdk1.7.0_79\jre\lib, or in the path specified by the -xbootclasspath parameter. All classes starting with Java.* are loaded by Bootstrap ClassLoader. Startup class loaders cannot be referenced directly by Java programs; The loader for all classes in rt.jar is BootStrapLoader.
2, Extension ClassLoader: This loader is implemented by sun.misc.Launcher$ExtClassLoader, which loads the D:\Program Files (x86)\Java\jdk1.7.0_79\jre\lib\ext directory. Or all libraries in the path specified by the java.ext.dirs system variable (such as classes beginning with Javax.*) can be used directly by the developer. All class loaders in the Ext directory are Extension classloaders
Sun.misc.Launcher$AppClassLoader is used to load classes specified by the user’s ClassPath. Developers can use the Application ClassLoader directly. If the application does not have its own custom class loader, this is generally the default class loader in the application.
====================JVM class loading mechanism ==============
Full responsibility: When the current thread’s CLassLoader is responsible for loading a Class, other classes that that Class depends on and references are also responsible for loading, unless classloader.loadClass () is specified for loading
Parent delegate: Let the parent loader try to load the class first, and only try to load the class from its own classpath if the parent loader is unable to load the class. So try not to use the same class as the JDK in development (for example, a custom java.lang.System class), because the parent class loader already has a copy of the java.lang.System class, it will be directly used by the program, and your custom class will not be loaded at all.
Parental delegation model:
The workflow of the parental delegation model is as follows: If a class loader received the request of the class loading, it won’t try to load the first class, but give parent to complete the request, in turn up, as a result, all of the class loading request should be passed to the top finally start the class loader, only when the parent loader in the scope of its search didn’t find the required class, If the load cannot be completed, the child loader will attempt to load the class itself. Parent delegate mechanism:
1. When an AppClassLoader loads a class, it does not attempt to load the class itself. Instead, it delegates the request to the parent class loader, ExtClassLoader. 2. When ExtClassLoader loads a class, it does not attempt to load the class itself in the first place. Instead, it delegates the class loading request to BootStrap ClassLoader. 3. If the BootStrap ClassLoader fails to load (for example, the class cannot be found in $JAVA_HOME/jre/lib), the ExtClassLoader will be used to load the BootStrap ClassLoader. 4. If the ExtClassLoader also fails to load, AppClassLoader will be used to load the ExtClassLoader. If the AppClassLoader also fails to load, ClassNotFoundException will be reported. Significance of parental delegation model:
– The system class prevents multiple copies of the same bytecode in memory – ensures the safe and stable running of Java programs
The loading process of the ================== class ======================
Class loading: The process by which the JVM loads the javAC-compiled class bytecode file into memory, validates, parses, and initializes this data, forms JAVA classes that the JVM can use directly, and finally reclaims (offloads).
Bytecode (.class) files
– Load. Class files from zip, JAR archives, etc. – Extract. Class files from a proprietary database – Dynamically compile Java source files into. Class files. The load phase is when the JVM takes the binary byte stream defined by a Class’s fully qualified name, converts the static storage structure represented by the byte stream into the runtime data structure of the method area, and generates a Java.lang.Class object representing the Class in the Java heap as an access point to the data in the method area. At this stage we developers can intervene. For example, we can specify a class loader to load the byte array or a custom class loader to load it.
2. Linking: The process of merging the binaries of Java classes into the JVM’s running state
A. Verification: Verification is to ensure that the information contained in the byte stream of the Class file meets the requirements of the current VM and does not harm the vm’s own security. B. Preparation: This stage allocates memory for class variables (static variables) and sets their initial values in the method area. For example: public static int flag=1; The initial value for this phase is 0. C. Resolution: The process by which the virtual machine replaces symbolic references in the constant pool with direct references. (A direct reference is a pointer that points directly to the target, a relative offset, or a handle that indirectly locates to the target.) 3. Initialization: Assigns correct initial values to static variables of a class.
The initialization phase is the execution of the class constructor (), which is generated by the compiler automatically collecting the assignment of all class variables in the class and combining the statements in the static statement block. When initializing a class, if the parent class has not been initialized, initialize the parent class first. The virtual machine ensures that a class’s () methods are locked and synchronized correctly in a multithreaded environment. When accessing a static field of a Java class, only classes that truly declare the field are initialized. 4. Usage: The program uses classes loaded by the JVM
5, unloading
The system.exit () method is executed JVM garbage collection mechanism triggers collector normal execution End The program encounters an exception or error during execution and terminates the Java Virtual machine process due to an operating System error
5. Runtime data area
1. Method Area: Method Area is the memory Area shared by each thread; The method area is used to store template information, constants and static variables of classes that have been loaded by virtual machines. Although the Java Virtual Machine specification describes a method area as part of a heap, it is also called a non-heap, which is supposed to distinguish it from the Java heap. According to the Java Virtual Machine specification, OutOfMemoryError is thrown when the method area cannot meet memory allocation requirements. Garbage collection is relatively rare in this area, but it is not the data that enters the method area that is as permanent as the name of the permanent generation. The main goal of this area is to recycle and unload types for the constant pool. The method area is just a specification:
Developing and deploying applications on the HotSpot virtual machine we call the method area “Permanent Generation”. There is no concept of permanent generation for other virtual machines (BEA JRockit, IBM J9, etc.). The HotSpot VIRTUAL machine has no concept of a method area in JKD.8, it uses a meta-space instead of this area. 2, PC registers (program counters) : each thread has a program counter, which is thread private. It is a pointer to the method bytecode in the method area (used to store the address pointing to the next instruction, that is, the instruction code to be executed). The execution engine reads the next instruction. It is a very small memory space that can be almost ignored. It is a line number indicator of the bytecode being executed by the current thread, and the bytecode interpreter changes the value of this counter to select the next bytecode instruction to be executed. If a Native method is executed, the counter is empty; To complete branch, loop, jump, exception handling, thread recovery and other basic functions. Native Stack: The VM Stack is similar to the VM Stack except that the VM Stack serves Java methods executed by the VM, while the Native method Stack serves Native methods. (The stack size is much smaller than the heap)
3, Vm Stack Stack is also called Stack memory, responsible for the operation of Java programs, is created when the thread is created, its life is to follow the life of the thread, the Stack memory is put, there is no garbage collection problem for the Stack, as long as the thread ends the Stack will be released, the life cycle is consistent with the thread, Is thread private. The eight base wood types of variables + object reference variables + instance methods are allocated in the stack memory of the function.
Stack operation principle: The data in the Stack exist in the format of Stack Frame, which is A memory block, A data set, and A data set related to methods and run-time data. When A Method is called, A Stack Frame Fl is generated and pushed into the Stack, and Method A calls Method B. Then the stack frame F2 is also pushed, and B method calls C method, so the stack frame F3 is also pushed. After execution, F3 stack frame is first popped up, then F2 stack frame is popped up, then Fl stack frame is popped up and so on, following the principle of “first in, last out”/” last in, first out “. When each method is executed, a stack frame will be created, which is used to store information such as local variation tables, operands, dynamic links, method exits and so on. From the invocation to the completion of execution of each method, a stack frame will be corresponding to the process from the virtual machine to the stack frame. Depending on the implementation of the particular JVM, the stack size is usually between 256K and 1024K, or about 1M.
JVM stack features:
The memory space required by the local variable table is allocated during compilation. When entering a method, how much memory the method needs to allocate in the frame is completely determined and does not change the size of the local variable table while the method is running. In the Java Virtual Machine specification, two exception states are specified for this area: a StackOverFlowError exception (stack overflow) is thrown if the thread requests a stack deeper than the virtual machine allows; If the virtual machine stack can be dynamically extended (and most Java virtual machines can now, although the Java Virtual Machine specification also allows fixed-length Java virtual machine stacks), OutOfMemoryError will be thrown if sufficient memory cannot be allocated during the extension (there is not enough memory). Native Method Stacks do the same thing as the virtual machine stack, the only difference is that the virtual machine stack performs Java methods (i.e. bytecode) services for the virtual machine, while the Native Method stack services Native methods used by the virtual machine. The virtual machine specification does not mandate the use of methods, languages, or data structures in the local method stack, so specific virtual machines are free to implement it. There are even virtual machines (such as the Sun HotSpot VIRTUAL machine) that simply merge the local method stack with the virtual machine stack. StackOverFlowError and OutOfmMemoryError exceptions are also thrown by the local method stack.
5. Java Heap: Is the largest chunk of Java VIRTUAL machine managed memory. The Java heap is a memory-management area shared by all threads. The sole purpose of this memory area is to hold instances of objects, and almost all object instances are allocated memory in the heap. This is described in the Java virtual machine specification: all object instances and array on the heap allocation, but with the development of the JIT compiler and escape technology mature gradually, stack allocation, replacement scalar optimization technology will lead to some subtle changes, all objects are allocated on the heap is not so “absolute”.
Finally, if you think this article is good, then pay attention to forward it!