The memory managed by the Java Virtual machine includes several runtime data memory: A method area, a virtual machine stack, a local method stack, a heap, a program counter, where the method area and the heap are data areas shared by the thread , and several others are thread-isolated data areas.
2.2 Run-Time data regions
2.2.1 Program counter
The program counter is a small piece of memory that can be seen as the line number indicator that is executed by the current thread. The bytecode interpreter works by changing the value of this counter to select the next instruction that needs to be executed, and the basic functions such as branching, looping, jumping, exception handling, thread recovery, and so on, need to rely on this counter to complete. If the thread is executing a Java method, this counter records the address of the executing virtual machine bytecode instruction, which is empty if the native method is being executed. This memory area is the only area in the Java Virtual Machine specification that does not stipulate any outofmemotyerror conditions.
2.2.2 Java Virtual Machine stack
Java Virtual machine stacks, like program counters, are also thread-private, with the same life cycle as threads.
The virtual machine stack describes the memory model that the Java method executes: Each method creates a stack frame to store information such as local variable tables, operand stacks, dynamic links, method exits, and so on. Each method from the call until the completion of the process, corresponding to a stack frame in the virtual machine stack into the stack of the process.
Usually said memory is divided into: heap and Stack, where the stack memory is the virtual machine stack, or the virtual machine stack in the local variable table part.
The local variable table holds the various basic data types that are known during the editing period (Boolean, Byte, char, short, int, float, long, double), The object reference (refrence) type and the ReturnAddress type, which points to the address of a byte-code directive.
The 64-bit length of long and double data takes up two local variable space, while the remaining data types occupy only 1. The amount of memory space required by the local variable table is allocated in the compiler, and when entering a method, this method needs to allocate how much local variable space in the frame is fully deterministic and does not change the size of the local variable table while the method is running.
The Java Virtual Machine specification provides two exceptions for this area: if the thread requests a stack depth greater than the virtual machine allows, the Stackoverflowerror exception is thrown. If the virtual machine is not able to request enough memory when it expands, it will run out of OutOfMemoryError exception
2.2.3 Local Method Stack
The role of the local method stack and the virtual machine stack is very similar, and the difference is that the virtual machine stack executes the Java method (that is, bytecode) service for the virtual machine, while the local method stack is the native method service used by the virtual machine.
Stackoverflowerror and Outofmemoryerroy exceptions are also thrown in the local method stack area
2.2.4 Java Heap
For most applications, the Java heap (Java heap) is the largest piece of memory managed by a Java virtual machine. The Java heap is a piece of memory that is shared by all threads and created when the virtual machine is started. The only purpose of this memory area is to hold object instances, and almost all object instances and arrays are allocated on the heap.
The Java heap is the main area of garbage collector management, so the Java heap is often referred to as the "GC heap".
In the memory recovery angle, the collector basically uses the Generational collection algorithm, the Java heap can be subdivided into: the new generation and the old age, in the finer Point has Eden space, from Survivor space, to survivor space and so on.
memory allocation angle, the thread-shared Java heap may divide multiple thread-private allocation buffers.
The Java heap can be in a physically discontinuous memory space, as long as it is logically contiguous, according to the Java Virtual Machine specification. When implemented, it can be either fixed or extensible, although the current mainstream virtual machines are implemented in a scalable way (via-XMX and-xms control). A OutOfMemoryError exception is thrown if there is no memory in the heap to complete the instance assignment and the heap can no longer be expanded.
2.2.5 Method Area
The method area is used to store data such as class information, constants, static variables, and code compiled by the immediate compiler that have been loaded by the virtual machine.
Although the Java Virtual Machine specification describes the method area as a logical part of the heap, it has an alias called Non-heap (not a heap) that is separated from the Java heap.
The Outofmemoryerroy exception is thrown when the method area does not meet the memory allocation requirements.
2.2.6 running a constant-volume pool
The runtime Constants pool is part of the method area. In addition to descriptive information such as the version, field, method, interface, and so on, the class file contains a constant pool (Constants pool Table) that holds the various literal and symbolic references generated during the compilation period.
Java virtual machines have strict specifications for each part of a class file (which naturally includes Chang), and each byte is used to store which data must conform to the requirements of the specification before it is recognized, loaded, and executed by the virtual machine. However, for running a constant pool, the Java Virtual Machine specification does not require any details, and the virtual machines implemented by different providers can implement this memory area according to their own requirements. In general, in addition to saving the symbolic references described in the class file, the translated direct references are also stored in the run-time-constant pool.
Another important feature of running a constant pool relative to a class file's const pool is its dynamic nature, where the Java language does not require constants to be generated by the compiler, and new constants may be put into the pool during runtime . This feature is used by developers more than the Intern () method of the String class.
Since the run-time-constant pool is part of the method area, it is naturally constrained by the memory of the method area, which throws a OutOfMemoryError exception when the constant pool is no longer able to request memory.
2.3 Hotspot Virtual Machine Object Quest 2.3.1 Object creation
Virtual opportunity to a new directive, first checks whether the parameter of the directive is able to locate the symbolic reference of a class in a constant pool, and checks whether the class represented by the symbol reference has been loaded, parsed, and initialized. If not, you must first perform the appropriate class loading process.
After the class load check passes, the virtual machine then allocates memory for the new object. The amount of memory required for an object can be fully determined after the class is loaded, and the task of allocating space to an object is equivalent to dividing a size of memory from the Java heap.
Assuming that the memory in the Java heap is absolutely regular, all the used memory is on one side, the free memory is on the other side, and a pointer is placed in the middle of the dividing point indicator, the allocated memory is to move that pointer over the free space to a distance equal to the size of the object, this distribution is called Pointer collision .
If the memory in the Java heap is not regular, the memory used and the idle memory are interleaved, the virtual machine needs to maintain a large enough space for the object instance and update the records on the list, which is called the " free list ".
In the case of concurrency, it is possible to allocate memory for object A, the pointer has not yet been modified, and object B uses the original pointer to allocate memory.
There are two ways to solve this problem,
One is to synchronize the action of allocating memory space--in fact, the virtual machine uses CAs to match the failure retry to ensure the atomicity of the new operation;
The other is that the memory allocation action is divided into different spaces by thread, that is, each thread allocates a small chunk of memory in the Java heap, called the local thread allocation cache (Tlab). Synchronization locks are required for the thread to allocate memory and the Tlab on which thread it is allocated. If the virtual machine uses Tlab, you can
-xx:+usetlab parameters to set.
After the memory allocation is complete, the virtual machine needs to initialize the allocated memory space to a value of 0 (excluding the object header), and if Tlab is used, this work can also be done in advance to Tlab allocation. This step ensures that the instance fields of the object can be used directly in Java code without assigning values, and the program can access the 0 values corresponding to these field data types.
Next, the virtual machines make the necessary settings for the object. For example, this object is the instance of which class, how to find the metadata information of the class, the object's hash code, the object's GC generational age, and so on. This information is placed in the object header of the object.
After the work is done, a new object has been created from the virtual machine's point of view, but from the Java program's point of view, object creation has just begun: The method has not been executed and all fields are zero. So, in general, after executing the new instruction, the method is followed and the object is initialized in the programmer's Hospital so that a truly usable object is fully produced.
Memory layout for 2.3.2 objects
In a hotspot virtual machine, the layout of objects stored in memory can be divided into 3 regions: the object header (header), the instance data (Instance), and its padding (Padding).
The object header of the hotspot virtual machine includes which part of the information, the first part is used to store the object's own run-time data, such as hash (hashcode), GC generational age, lock status flag, thread-held lock, biased thread ID, biased timestamp, etc. This part of the data is 32bit and 64bit in length in 32-bit and 64-bit virtual machines respectively.
The other part of the object header is the type pointer, which is the pointer to its class metadata, which the virtual machine uses to determine which class the object is an instance of. Not all virtual machine implementations must retain type pointers on the object data. In other words, finding the metadata information for an object does not necessarily go through the object itself.
Also, if an object is a Java array, there must be a piece of data in the object header that records the length of the array. Because the virtual machine can determine the size of the Java object through the metadata information of ordinary Java objects, the size of the array cannot be determined from the metadata of the array.
Access positioning for 2.3.3 objects
Objects are created to work with objects. There are two ways to access the current mainstream, using a handle and a direct pointer.
With a handle, a chunk of memory will be partitioned into the Java heap as a handle pool, where the handle address of the object is stored, and the handle contains the specific address information of the object instance data and the type data reference.
Use direct handles to access
Using a direct handle to access, the greatest benefit of the layout of the Java heap object is that the reference store a stable handle address that changes only the instance data pointer in the handle when the object is moved, and reference itself does not need to be modified.
The greatest benefit of using pointer access is that it is faster, which saves time overhead for pointer positioning.
2.4 Combat: OutOfMemoryError Exception 2.4.1 java heap Overflow
The Java heap is used to store object instances, as long as the objects are constantly created, and the GC roots to the object to avoid the garbage collection mechanism from clearing these objects, a memory overflow exception occurs when the number of objects reaches the maximum heap capacity limit.
To solve the anomaly in this area, the general approach is to analyze the dump-dump snapshot by means of a Memory image analysis tool (such as Eclipse Memory Analyzer), with a focus on confirming that the objects in memory are required, That is, the first to know whether there is a memory leak (memories Analyzer) or memory overflow (memories Overflow)
2.4.2 Virtual machine stack and local method stack overflow (slightly)
The-xoss parameter (set local method stack) exists, and the stack capacity is set only by the-XSS parameter.
A Stackoverflowerror exception is thrown if the thread requests a stack depth that is greater than the maximum allowed depth for the virtual machine.
Throws a OutOfMemoryError exception if the virtual machine cannot request enough memory space on the scale stack.
2.4.3 method area and run-time-constant pool overflow (slightly)
-xx:permsize and-xx:maxpermsize Limit the method area size, thereby indirectly restricting the capacity of the constant pool.
The method area is used to store information about class, such as its name, access modifier, Chang, field description, method description, and so on. The basic idea for testing these areas is that the runtime generates a large number of classes to fill the method area until it overflows. think about spring, huh?
2.4.4 Native Direct memory overflow (slightly)
The direcmemory capacity is specified by-xx:maxdirectmemorysize and, if not specified, the default is the same as the Java heap maximum (-xmx specified).
Memory overflow caused by directmemory, an obvious feature in the heap dump file will not see the obvious exception, if the reader found that after the dump file is very small, and the program directly or indirectly using NIO, then you can consider whether this is the reason.
Deep understanding of Java Virtual Machine--JVM advanced features and Best Practices (2nd edition) PDF download:
http://download.csdn.net/detail/xunzaosiyecao/9648998
Jiankunking Source: http://blog.csdn.net/jiankunking
Deep understanding of JVM reading notes one: Java memory area and memory overflow exception