Java notes-java Memory area and GC mechanism __gc

This is mainly done in the Java memory area and GC mechanism of knowledge Summary, the following paragraph excerpt from the network, part from the book, the specific links forgotten, because this is the time before the study to do the notes. Also hope that the original people to forgive. 1 Java garbage collection

The Java GC(garbage Collection, garbage collection, garbage collector ) mechanism is one of the main differences between Java and C++/C, as Java developers, In general, there is no need to write memory and garbage cleanup code specifically, memory leaks and overflow problems, and do not need to be as jittery as C programmers. This is because in the Java Virtual Machine (JVM), there are automatic memory management and garbage cleaning mechanisms. In a nutshell, the mechanism marks memory in the JVM (Java Virtual Machine) and determines which memory needs to be recycled, automatically reclaims the memory according to a certain recycling strategy (Nerver Stop) To ensure memory space in the JVM to prevent memory leaks and overflow problems.

With regard to the JVM, it needs to be explained that in the Sun Company's JDK, which is currently the most used, the default virtual machines are hotspot, since the JDK1.2 of 1999 began to be widely used JDK6. Oracle acquired Sun in 2009, plus the previously acquired EBA company, Oracle has two of the 3 largest virtual machines: JRockit and hotspot. Oracle also indicated the intention to integrate the two large virtual machines, but currently in the new release of the JDK7, the default virtual machine is still hotspot, so the virtual machines introduced in this article are hotspot, and the related mechanism is mainly refers to the hotspot GC mechanism.

The Java GC mechanism mainly accomplishes 3 things:
(1) Determine which memory needs to be recycled;
(2) Determining when a GC should be implemented;
(3) How to perform GC.

After such a long period of development (in fact, there is a GC mechanism before the advent of the Java language, such as the Lisp language), the Java GC mechanism is getting better, and almost automatically doing most of the work for us. However, if we are engaged in the development of larger application software, there is a need for memory optimization, we must study the Java GC mechanism.

Learning the Java GC mechanism can help us to troubleshoot various memory overflow or leak problems in our daily work, solve performance bottlenecks, achieve higher concurrency, and write more efficient programs. We will learn from the following four aspects of the Java GC mechanism:
(1) How the memory is allocated;
(2) How to ensure that memory is not incorrectly recycled (ie: which memory needs to be recycled);
(3) The circumstances under which GC is executed and how the GC is executed;
(4) How to monitor and optimize the GC mechanism. 2 Java Memory Regions

To understand the Java GC mechanism, you must first understand the partitioning of memory areas in the JVM. In the Java runtime's data area, the memory area managed by the JVM is divided into the following diagram modules:

of which: 2.1 program counters (Programs Counter Register)

A program counter is a relatively small area of memory that indicates that the byte code executed by the current thread executes to the first line, which is understood to be the line number indicator of the current thread. When the bytecode interpreter is working, a statement instruction is removed by changing the value of this counter. Each program counter is used only to record the line number of a thread, so it is thread-private (one thread has a program counter).

If the program executes a Java method, the counter records the executing virtual machine byte-code instruction address, and if the execution is a local (native, written by C language) method, the counter's value is undefined, because the program counter only records the current instruction address. So there is no memory overflow, so the program counter is the only region in all JVM memory areas that does not have a defined outofmemoryerror. 2.2 Virtual machine stacks (JVM stack)

Each method of a thread executes at the same time as the will create a stack frame (statck frame), stored in the stack frame with local variables table, Operation Stack, dynamic link, method exit, etc., when the method is called, the stack frame in the JVM stack into the stack, when the method is completed, stack frame stack.

The Local variables table stores the relevant local variables of the method, including various basic data types, object references, return addresses, and so on. In a local variable table, only the long and double types occupy 2 local variable spaces (Slot, for 32-bit machines, one Slot is 32 bit), and the others are 1 Slot. It should be noted that the local variable table is at compile time has been determined, the method of operation required to allocate the space in the stack frame is completely determined, in the life cycle of the method will not change.
　　
Two exceptions are defined in the virtual machine stack that throw a statckoverflowerror (stack overflow) if the thread calls a stack depth greater than the maximum depth allowed by the virtual machine; however, most Java virtual machines allow the dynamic expansion of the virtual machine stack size (with a small number of fixed-length). So the thread can always apply for stacks, know that there is not enough memory, at this time, will throw OutOfMemoryError (memory overflow).

Each thread corresponds to a virtual machine stack, so the virtual machine stack is also thread-private.
　　 2.3 Local methods Stack (Native method Statck)

Local method stack in effect, the operating mechanism, exception types and so on are the same as the virtual machine stack, the only difference is: the virtual machine stack is the implementation of Java methods, and the local method stack is used to execute the native method, in many virtual machines (such as the Sun's JDK default hotspot virtual machine), The local method stack is used with the virtual machine stack.

The local method stack is also thread-private.
　　 2.4 Heap Area (HEAP)

Heap area is the most important area to understand the Java GC mechanism, not one. In the memory managed by the JVM, the heap area is the largest piece, and the heap area is the main memory area managed by the Java GC mechanism, and the heap area is shared by all threads and created when the virtual machine is started. Heap area exists to store object instances, in principle, all objects are allocated memory on the heap area (but in modern technology, it is not so absolute, there are also directly distributed on the stack).

In general, according to the Java Virtual Machine specification, heap memory needs to be logically continuous (physically unwanted), can be fixed size or extensible when implemented, and the current mainstream virtual machines are extensible. If you do not have enough memory allocations or extensions after the garbage collection has been performed, you will throw a Outofmemoryerror:java heap space exception.
　　
There is much more to the heap area, which is described in detail in the next section, "Java Memory allocation mechanism."
　　 2.5 Method Areas

In the Java Virtual Machine specification, the method area is treated as a logical part of the heap, in fact, the method area is not a heap (non-heap); In addition, many people blog, the Java GC's generational collection mechanism is divided into 3 generations: The green age, the old age, the permanent generation, these authors define the method area as " Permanent generation, which is because, for previous implementations of the Hotspot Java Virtual machine, the idea of generational collection was extended to the method area and the method area was designed as a permanent generation. However, most virtual machines other than hotspot do not treat the method area as a permanent generation, hotspot itself, and also plan to cancel the permanent generation. In this article, because the author mainly uses Oracle JDK6.0, it will still use the term permanent generation.

A method area is an area shared by individual threads to store class information that has been loaded by a virtual machine (that is, information that needs to be loaded when the class is loaded, including version, field, method, interface, etc.), final constant, static variable, compiler Just-in-time code, and so on.
　　
The method area is not physically required to be contiguous, you can choose a fixed size or a scalable size, and the method area has one more limit than the heap: You can choose whether to perform garbage collection. Generally, the garbage collection performed on the method area is very small, this is also one of the reasons why the method area is called a permanent generation (HotSpot), but it does not mean that there is no garbage collection on the method area, and that the garbage collection on it is mainly for the memory reclaim of the constant pool and the unload of the loaded class.
　　
Garbage collection in the method area, the conditions are harsh and very difficult, the effect is not satisfactory, so generally do not do too much thinking, can be left for further in-depth study later use. The Outofmemoryerror:permgen space exception is defined on the method area and is thrown when there is not enough memory.

The runtime (Runtime Constant Pool) is part of the method area used to store literal constants, symbolic references, translated direct references (symbolic references that encode a string representing the position of a variable, an interface) generated at compile time. A direct reference is a translated address based on a symbolic reference that will complete the translation at the class link stage; The Run-time constant pool, in addition to storing compile-time constants, can also store constants generated at runtime (such as The Intern () method of the String class, which maintains a constant pool of If the called character "ABC" is already in a constant pool, the string address in the pool is returned, otherwise a new constant is added to the pool and the address is returned.
　　 2.6 Direct Memory (Memory)

Direct memory is not a JVM-managed memory, so it can be understood that direct memory is the machine memory outside the JVM. For example, you have 4G of memory, the JVM occupies 1G, the remaining 3G is direct memory, JDK has a channel (Channel) and buffers (buffer) memory allocation, the C language implemented by the native function library in direct memory, Referenced using the directbytebuffer stored in the JVM heap. Because direct memory is limited by the memory of this machine, outofmemoryerror exceptions may occur.

This column will continue to update the Java knowledge ...