JVM Basics
Relationship of the JVM to the operating system
Java Virtual Machine The full name of the JVM is Java Virtual Machine, also known as Java Virtual Machine. It recognizes files with the.class suffix and can parse its instructions, eventually calling functions on the operating system to do what we want.
After the Java program is written, the runtime is compiled into bytecode using the Javac tool in the JDK, and the Java bytecode (.class) is run by the JVM (JVM can also run JAR, which is bytecode in nature). Translated to the machine code of the host operating system (JVM runtime interprets the class file as it is executed, rather than first translating all the bytecode into machine code and running it again), the Java program runs successfully. The implementation process of JVM under different operating systems is different, and the platform implementation difference of JVM results in the same implementation effect of the same Java program under different platforms, that is, we often say Java program cross-platform.
Unlike Java programs, after compiling into.class files using Javac, you need to use Java commands to actively execute them. The operating system does not recognize these.class files. So the JVM is a translation.
With the JVM as an abstraction layer, Java can be implemented across platforms. The JVM just needs to execute the.class file correctly to run on platforms such as Linux, Windows, and MacOS.
From cross-platform to cross-language
Cross-platform: The Person class we wrote runs the same on different operating systems (Linux, Windows, MacOS, etc.). This is the cross-platform nature of the JVM. In order to realize the cross-platform type, different operating systems have different JDK version of www.oracle.com/java/techno…
Cross-language: The JVM only recognizes bytecodes, so the JVM is decoupled-that is, not directly related to the language. Instead of translating Java files, the JVM recognizes class files, which are commonly referred to as bytecodes. There are also languages like Groovy, Kotlin, Jruby, etc., which are actually compiled into bytecode and therefore run on the JVM. This is the cross-language feature of the JVM.
The JVM is a translation of a Class into machine-readable code. However, it is important to note that the JVM does not generate its own code, but requires other people to write the code, and requires a lot of dependent Class libraries. What is JRE? In addition to containing the JVM, it provides a number of libraries (jar packages, which provide plug-and-play functions such as reading or manipulating files, connecting to the network, using I/O, etc.) that are the basic libraries provided by the JRE. The JVM standard, along with a bunch of base libraries implemented, makes up the Java Runtime Environment, commonly known as the JRE (Java Runtime Environment). But for programmers, JRE is not enough. When I write it, I compile it, I debug it, I package it, and sometimes I decompile it. That’s why we use the JDK, because the JDK also provides some very useful gadgets, such as Javac (compiled code), Java, JAR (packaged code), Javap (decomcompiled < disassembled >), etc. This is the JDK. Specific can be downloaded documents can go through the official website: www.oracle.com/java/techno… The JVM is a Java program, first compiled by Javac into a.class file, then loaded by the JVM into the method area, where the execution engine executes the bytecode. When executed, it is translated into operating system-specific functions. The JVM exists as a translation of.class files, entering bytecode and calling operating system functions. The process is as follows: Java file -> Compiler > bytecode ->JVM-> machine code. Explain execution with GIT:
The structure of the JVM
1. Program counter
Small memory space, line number indicator of bytecode executed by the current thread; Each thread is stored independently and does not affect each other. A program counter is a small memory space that is used to record the addresses of bytecodes executed by individual threads. For example, branches, loops, jumps, exceptions, thread recovery, and so on all depend on the counter. Because Java is a multithreaded language, when the number of threads executing exceeds the number of CPU cores, threads compete for CPU resources based on time slice polling. If a thread runs out of time or is robbed of CPU resources prematurely for other reasons, the exiting thread needs a separate program counter to record a running instruction. The program counter is also the only memory area in the JVM that is not OOM(OutOfMemory)
2. What data structure is a virtual machine stack? FILO is a data structure in which the virtual machine stack stores data, instructions, and return addresses required by the current thread’s method of execution while the JVM is running. The Java virtual machine stack is thread-based. Even if you only have a main() method, it runs as a thread. In the life cycle of a thread, the data involved in the calculation is frequently pushed on and off the stack, and the life cycle of a stack is the same as that of a thread. Each piece of data in the stack is a stack frame. Each time a Java method is called, a stack frame is created and merged into the stack. Once the corresponding call has been made, the stack is removed. When all frames are off the stack, the thread terminates. Each stack frame contains four areas :(local variable table, operand stack, dynamic link, return address) the stack size is 1 MB by default, and can be adjusted with the parameter -xss, such as -xss256k
Local variables table: as the name implies is a table of local variables, used to store our local variables. First of all, it is a 32 bit length, main store our Java eight basic data types, generally under 32 bits can be stored, if it is 64 the use of high and low bits occupy two can also be stored, if it is local objects, such as our Object, we only need to store it a reference address. Operation data stack: The operand stack, which holds the operands that our method executes, is a stack, a first-in, last-out stack, and the operand stack, which is used to operate on, can be any Java data type, so we know that when a method starts, the operand stack is empty, The operand stack run method is a dynamic connection of on-stack/off-stack operations that the JVM runs all the time: The Java language feature polymorphism (requires the class runtime to determine the exact method). Return address: normal return (call address as the return of the program counter), abnormal words (through the exception handler table < > in the stack frame to determine) stack frame execution effects on memory area Mnemonic explain address: bytecode cloud.tencent.com/developer/a…
In the JVM, interpretation based execution is a stack-based engine, the operand stack.
3. Local method stack
The local method stack is similar to the Java virtual machine stack, which is used to manage calls to Java functions, and the local method stack, which is used to manage calls to local methods. But native methods are not implemented in Java, they are implemented in C. The native method stack is an area very similar to the virtual machine stack that serves native methods. You can even think of the virtual machine stack and the local method stack as the same area. It is not mandated by the VIRTUAL machine specification and can be implemented on all versions of the virtual machine. HotSpot directly blends the local method stack with the virtual machine stack. An area shared by threads
4. Method area
Method area/persistent Generation Many developers refer to method area as “persistent generation”, but the two are not equivalent. The HotSpot VIRTUAL machine uses persistent generation to implement method areas, but other virtual machines, such as Oracle’s JRockit and IBM’s J9, do not have persistent generation. Therefore, the method area is only part of the specification in the JVM, so to speak, in the HotSpot VIRTUAL machine the designers implemented the method area of the JVM specification using persistent generation.
The method area is used to store class-related information that has been loaded by virtual machines, including class information, static variables, constants, runtime constant pool, and string constant pool. When the JVM executes a class, it must be loaded first. When a class is loaded (loading, validating, preparing, parsing, and initializing), the JVM first loads a class file. The class file contains information about the class version, fields, methods, and interfaces, as well as the Constant Pool Table. Used to hold various literal and symbolic references generated during compilation. Literals include strings (String a= “b”), constants of primitive types (final modified variables), and symbolic references include fully qualified names of classes and methods (for example, the String class, Its fully qualified name is Java/lang/String), the field name and descriptor, and the method name and descriptor. When a class is loaded into memory, the JVM stores the contents of the class file’s constant pool into the runtime constant pool. During the parsing phase, the JVM replaces symbolic references with direct references (the index value of the object). For example, a string constant in a class file is stored in the class file constant pool. After the JVM loads the class, the JVM puts the string constant into the runtime constant pool and, during the parsing phase, specifies the index value of the string object. The runtime constant pool is shared globally. Multiple classes share the same runtime constant pool. Only one copy of the same string in the constant pool will exist in the class file. The method area, like the heap space, is also a shared memory area, so the method area is shared by threads. If two threads are trying to access the same class information in the method area, and the class has not yet been loaded into the JVM, only one thread is allowed to load it, and the other thread must wait. In the HotSpot virtual machine, the pool of static variables and runtime constants for the persistent generation has been moved to the heap in the Java7 release, the rest is stored in the JVM’s non-heap memory, and the Java8 release has removed the persistent generation implemented in the method area. Class metadata is used instead of the previous permanent generation, and the storage location of the metadata is the local metadata size parameter: jdk1.7 and before (initial and maximum) : -xx :PermSize; – XX: MaxPermSize; After jdk1.8 (initial and maximum) : -xx :MetaspaceSize; -xx :MaxMetaspaceSize jdk1.8
The JVM parameter reference: docs.oracle.com/javase/8/do…
5, heap
The heap is the largest area of memory on the JVM, where almost all of the objects we request are stored. When we say garbage collection, the object of operation is the heap. Heap space is usually claimed at startup, but not always used. As objects are created frequently, the heap space becomes more and more occupied, and objects that are no longer in use need to be irregularly reclaimed. This is called Garbage Collection (GC) in Java. When an object is created, is it allocated on the heap or on the stack? This has to do with two things: the type of the object and its location in the Java class. Java objects can be divided into basic data types and ordinary objects. For normal objects, the JVM creates the object on the heap first, and then uses references to it elsewhere. For example, store this reference in a local variable table in the virtual machine stack. For basic data types (byte, short, int, long, float, double, char), there are two cases. When you declare an object of primitive data type in the method body, it is allocated directly on the stack. In other cases, it’s all on the heap.
Heap size parameters: -xms: minimum heap size; -xmx: indicates the maximum value of the heap. -XMN: Cenozoic size; – XX: NewSize; Cenozoic minimum value; -xx :MaxNewSize: indicates the maximum value in the new generation. For example – Xmx256m
Instance to expand 
Differentiate between heap and stack in depth
- function
In the way of stack frame storage method call process, and storage method call process of basic data type variables (int, short, long, byte, float, double, Boolean, char, etc.) and object reference variables, its memory allocation on the stack, variables out of scope will be automatically released; Heap memory is used to store objects in Java. Whether a member variable, a local variable, or a class variable, the object they point to is stored in heap memory;
- Thread exclusive or shared
The stack memory belongs to a single thread, and each thread has a stack memory. The variables stored in the stack memory can only be seen in its owning thread, that is, the stack memory can be understood as the private memory of the thread. Objects in heap memory are visible to all threads. Objects in heap memory can be accessed by all threads.
- The size
The stack will be far less memory than heap memory of memory stack overflow parameters: – Xss1m, specific defaults need to check the website: docs.oracle.com/javase/8/do…
Out of memory
1. Stack overflow
The HotSpot version has a fixed stack size and does not support extension. Java. Lang. StackOverflowError method invocation is difficult to appear commonly, if appear may be infinite recursion. The takeaway from the virtual stack is that the execution of a method is inherently slower than a loop that implements the same function, so both recursion and non-recursion (loop implementation) make sense in tree traversal. Recursive code is concise, while non-recursive code is complex but fast. OutOfMemoryError: The machine does not have enough memory because threads are being created and the JVM is requesting stack memory. (Generally can not demonstrate, demonstrate the machine also died)
2. Heap overflow
Memory overflow: Request memory space, exceeds the maximum heap memory space. If there is a memory overflow, increase the -xms, -xmx parameters. If it is not a memory leak, that is, the object in the memory is must survive, so long you should check the JVM heap parameters Settings, compared with the memory of the machine, to see whether there is any can adjust the space, and out of the code to check whether there is a certain object life cycle is too long, hold time is too long, storage structure design is unreasonable, and so on and so forth, Minimize memory consumption while the program is running.
3. Overflow of method area
(1) run-time constant pool overflow (2) The Class object saved in the method area is not recycled in time or the Class information takes up more memory than we configured.
All instances of this Class have been reclaimed, i.e. there are no instances of this Class in the heap. 2. The ClassLoader that loaded the class has been reclaimed. 3. The java.lang.Class object corresponding to this Class is not referenced anywhere, and its methods cannot be accessed anywhere through reflection.
4. Local direct memory overflow
The direct memory size can be set using MaxDirectMemorySize (the default is the same as the maximum heap memory size), so an OOM exception will occur. Memory overflow caused by direct memory overflow, a relatively obvious feature is that there is no obvious exception in the HeapDump file. If OOM occurs, and the Dump file is very small, you can consider to focus on the direct memory cause.