After moving last weekend, the broadband in the home has not been good, with telecom customer service reflected N times finally about a master tomorrow morning to migrate broadband, can end more than a week without the painful day of the network. This period of time is also all kinds of busy, did not update the blog for a week, do not write before that kind of state and passion should slowly fade, always feel the heart panic of a force, how can this line? ! Take advantage of tomorrow weekend, jot down some of this week’s learning material on the company computer. Recently I am reading a classic Java book: In-depth Understanding of Java Virtual Machine 2nd Edition. I also read it a few years ago, but I was not good enough at that time, so I did not read it. Now looking back, found that really write very good, a lot of knowledge points can understand, but also very deep, harvest a lot. Later, I plan to write a series of blogs according to the content of this book to study and review the knowledge related to Java virtual machine in depth.
Overview of JVM memory model
The JVM memory model is also quite simple.
1. Composition: Java heap, Java stack (i.e. virtual machine stack), local method stack, method area and program counter.
2. Shared or not: Method area and heap area are shared by threads, virtual machine stack, local method stack and program counter are thread private, also known as thread isolated, and each area stores different contents. These two points must be kept in mind as the foundation of the JVM memory model.
Second, program counter
The program counter in the JVM is a small area of memory, but it’s an interesting one. There are three main features:
1, store content: for Java common methods (i.e. methods without native keyword modification), store the address of the current instruction during execution. For Native methods, this is empty (undefined). Why? This is because the local method may have exceeded the MEMORY address of the JVM.
Thread private: Why are program counters thread private? According to store content understanding, if be threads share, that a thread execution, don’t know your current address is which thread execution, some threads, some threads slow, fast after will enter the next step, such as slow thread after come back found his address is changed, not broken?
Is the only region of the JVM that does not report an OutOfMemoryError.
3. Virtual machine stack
Virtual machine stack mainly stores a stack frame, each stack frame stores the local variable table, operand stack, dynamic link and method exit information and so on. The local variable table stores some local variables defined in the method, object references, parameters, and method return address, etc. The space occupied by the local variable scale can be determined at compile time. During the operation of the method, the space of the local variable scale will not be changed, which is well understood in combination with the contents stored in the local variable scale. The operand stack can be thought of as moving data from the current operation onto and off the stack. For 64-bit long and double types, each operand occupies 2 slot width, and for other types, one slot width. Each method call creates a stack frame, which corresponds to the process of moving a stack frame from the virtual machine stack to the stack. About the content of the stack frame can refer to a netizen wrote a blog: blog.csdn.net/xtayfjpk/ar… Very good and detailed. Here is a stack frame diagram, see at a glance.
There are two cases of vm stack memory overflow:
The thread requested a stack that was deeper than the virtual machine allowed, and StackOverflowError was raised, so when we saw this exception in our code, we should have thought that the virtual machine stack might be out of order.
An OutOfMemoryError is raised when sufficient memory cannot be allocated when the virtual stack can be dynamically extended (as most JVMS can, although fixed size virtual stacks are allowed).
Local method stack
The function of the local method stack is similar to that of the virtual machine stack, but it serves for the INVOCATION of native methods by THE JVM. Moreover, the JVM has no mandatory provisions on the language used by the local method (such as the function realized by Java calling C language, native methods need to be defined to realize), usage mode and data structure. Therefore, different virtual machines can be implemented freely. And the HotSpot VIRTUAL machine directly blends the local method stack with the virtual machine stack. Like the virtual stack, the local method stack throws stackOverflowErrors and OutofMemoryErrors.
5. Method area
The method area is an important area. The Java Virtual Machine specification describes the method area as a logical part of the Heap, but in order to correspond to the Heap, it is also called non-heap. The main stores are static variables, constants (including runtime constants), class loading information, and Java compiled code. This part of the space does not need to be continuous, can choose fixed size and scalability, usually there is no GC in this part of the space, because the GC is collecting static variables, constants and class load information, these object collection is usually not satisfactory, so you can choose not to implement garbage collection. This region is also known as the persistent generation, and OutOfMemoryError is raised when this region is out of memory.
Six, heap area
The Java heap is the fattest part of the JVM’s memory because it stores instances of objects and array objects. This area is shared by threads and is created when the JVM starts. If this amount of space is thread private, the memory must not burst. According to the Java Virtual Machine specification, the contents of the heap can be physically discontinuous, as long as they are logically continuous, can be implemented as fixed size, can be extensible, and are usually extensible. The common memory parameters -xms and -xmx are used to adjust the heap size. The Java heap area is divided into new generation and old generation according to different life cycles. The new generation can in turn be subdivided into Eden and Survivor, which in turn can be subdivided into Survivor1 and Survivor2, both of which usually use only one and the other to hold surviving objects while GC is going on. Out most of the new object is stored in Eden area, if it is a large objects, such as a large array or a List object, you can through the JVM parameter – XX: PretenureSizeThreshold will exceed the specified the size of the object directly into old age, it is important to note that When writing programs, you should try to avoid large, dead objects from the old generation because the cost of the old generation GC is higher than that of the younger generation GC. The default size ratio of Eden and Survivor is 8:1:1, and the default GC algorithm of the new generation is the replication algorithm. The default GC algorithm in the old days was tag collation. These two GC algorithms will be covered in the next blog post.
OutOfMemoryError is thrown when there is not enough memory in the heap. For the memory model of the heap, please refer to the following image:
