1. JAVA memory area
Thread private includes:
program counter
l If the java method is being executed, the counter records the address of the bytecode instruction being executed
l If the native method is being executed, the counter is empty
l This area is the only one that does not cause an OutOfMemoryError
virtual machine stack
l Describes the memory model of Java method execution: each method creates a stack frame for storing local variable table, operand stack, dynamic link, method exit and other information
l The local variable table stores the basic data types, object references, and returnAddress types known at compile time (pointing to the address of a bytecode instruction). The memory space of the local variable table is determined by the compiler and remains unchanged at runtime.
l Can cause two exceptions: the stack depth requested by the thread is greater than the depth allowed by the virtual machine - StackOverflowError; the virtual machine cannot apply for enough memory - OutOfMemoryError
native method stack
l Similar to the virtual machine stack, but it serves the Native method
Thread sharing includes:
heap
l The java heap is a memory area shared by all threads, created when the virtual machine starts, used to allocate object instances and arrays
l The heap is the main area managed by the garbage collector. It can be divided into the new generation and the old generation. The new generation is divided into Eden space, From Survivor space, and To Survivor space
l Size can be controlled by -Xmx and -Xms
method area
l Used to store class information loaded by the virtual machine, constants, static variables, code compiled by the real-time compiler, etc.
l GC will recycle the constant pool in this area and unload the type
runtime constant pool
l The constant pool of the Class file is used to store various literals and symbolic references generated during compilation. This part of the content will be stored in the runtime constant pool after the class is loaded.
l The translated direct references are also placed in the runtime constant pool, and the constants generated at runtime are also placed in it
direct memory
l It is not part of the virtual machine runtime data area, nor is it a memory area defined in the Java virtual machine specification. NIO uses the Native function library to directly allocate off-heap memory.
2. The whole process of object allocation, layout and access of the HotSpot virtual machine in the Java heap
object creation
l When the virtual machine encounters a new instruction, it will first check whether the parameters of this instruction can locate a symbolic reference of a class in the constant pool, and check whether the class represented by the symbolic reference has been loaded, resolved and initialized. If not, the corresponding class loading process must be executed first
l Memory allocation
pointer collision
free list
safety
CAS with failed retry
Thread Local Allocation Buffer (TLAB)
l Memory space initialization
l Make necessary settings for the object (such as which class instance this object is, how to find the metadata information of the class, the hash code of the object, the GC generation age of the object, etc.)
l Execute init, complete
Object's memory layout
l Object header
The first part is used to store the runtime data of the object itself, such as hash code (HashCode), GC generation age, lock status flag, thread held lock, biased thread ID, biased timestamp, etc.
The other part is the type pointer, that is, the pointer that the object points to its class metadata. The virtual machine uses this pointer to determine which class the object is instance instance data of.
l Instance data
It is the effective information that the object actually stores, and it is also the field content of various types defined in the program code. Whether it is inherited from the parent class or defined in the subclass, it needs to be recorded and aligned to fill
l Alignment supplement
object access location
use handle
Direct pointer (Sun HotSpot)
3. Garbage collection and memory allocation
reference counting
l Idea: Set a reference counter for the object. Each time the object is referenced, the counter will be +1. When the reference is invalid, the counter will be -1. When the value of the reference counter is 0 at any time, the object can be recycled.
l Java is not applicable Reason: cannot solve the problem of circular reference of objects to each other
accessibility analysis
Taking the GC Roots as the starting point, the search starts from these starting points, and the path passed is called the reference chain. An object is unreachable if there is no chain of references between it and GC Roots.
Objects that can be used as GC Roots are
l Objects referenced in the virtual machine stack (local variable table in the stack frame)
l Objects referenced by class static properties in the method area
l Objects referenced by constants in the method area
l Objects referenced by JNI (Native methods) in the local method stack
During reachability analysis, the object reference type has an impact on the life cycle of the object
There are several types of references in JAVA:
l Strong reference: As long as the reference is still valid, the GC will not recycle it
l Soft reference: not reclaimed when the memory space is sufficient, reclaimed before the memory overflow occurs, and implemented with the SoftReference class
l Weak reference: The object associated with the weak reference can only survive until the next Gc collection, which is implemented with the WeakReference class
l Virtual reference: The object instance cannot be obtained through the virtual reference, and it will not affect the life time of the object. The only purpose: when the object is collected by Gc, a system notification is received. Implemented with the PhantomReference class
An object is truly unavailable and has to go through the marking process twice:
l First perform accessibility analysis, filter out objects that have no reference chain with GC Roots, and perform the first marking and screening. The screening condition is whether it is necessary to execute the finalize() method. If the object has not rewritten the finalize() method, or whether finalize() has been called by the jvm, there is no need to execute it, the GC will recycle the object, and if necessary, the object will be put into the F-Queue, Start a low-priority thread by the jvm to execute it (but not necessarily wait for finalize to complete)
l After the first marking, the GC will mark the object in the F-Queue for the second time. Finalize() is the last chance for the object to save itself. If the object is re-added to the reference chain in finalize(), it will The collection of objects to be removed from the collection, other objects will be marked a second time for recycling
The garbage collection algorithms in JAVA are:
Mark-Sweep
Two stages: mark, clear
Disadvantages: The efficiency of both stages is not high; it is easy to generate a lot of memory fragmentation
Copying
Divide the memory into two blocks of the same size. When the memory of one block is used up, copy the available objects to the other block, and clean up the used block at one time
Disadvantage: half of the memory wasted
Mark-Compact
After marking, move all surviving objects to one end, and then directly clean up the memory outside the end boundary
Generational collection
Divide the heap into young generation and old generation
The new generation uses the replication algorithm
Divide the new generation memory into a large Eden area and two small Survivors; each time you use Eden and a Survivor, copy the surviving objects of Eden and Survivor to another Survivor (HotSpot ratio Eden: Survivor = 8: 1)
Old age uses mark-clean or mark-sort
Algorithm Implementation of HotSpot
enumerate root nodes
The OopMap data structure records which locations are references
Safe point
Which locations can produce OopMap
Selection is based on whether it has characteristics that allow the program to execute for a long time
Preemptive interrupts (not employed) and proactive interrupts
safe area
In a code snippet, the reference does not change
Garbage collector:
Serial (Serial Collector)
Features: single thread, stop the world, using replication algorithm, simple and efficient
Application scenario: The default new generation collector in Client mode
ParNew
Features: It is a multi-threaded version of Serial, using a replication algorithm
Application scenario: a new generation collector commonly used in Server mode, which can work with CMS
Parallel Scavenge
Features: Parallel multi-threaded collector, using replication algorithm, throughput priority, with adaptive adjustment strategy
Application scenario: when high throughput is required
SerialOld
Features: Old generation version of Serial, single-threaded, uses mark-and-collate algorithm
Parallel Old
Old-age version of Parallel Scavenge, multi-threaded, mark-to-collate algorithm
CMS
Process:
l Initial mark: stop the world marks the object that GC Roots can directly associate with
l Concurrent marking: perform GC Roots Tracing
l Remark: stop the world; correct the mark record of the part of the object whose mark is changed due to the user program continuing to operate during concurrent mark
l Concurrent clearing: clearing objects
Features: Aiming at the shortest recovery pause time, using mark-sweep algorithm
Pros: Concurrent collection, low pauses
shortcoming:
l Sensitive to CPU resources
l Unable to process floating garbage (when the user thread is still running during concurrent removal, the garbage generated at this time is floating garbage)
l Generates a lot of space debris
G1
For server-side applications, divide the entire heap into regions of the same size.
Features
l Parallelism and Concurrency
l Generation collection
l Spatial integration: It is based on "marking and sorting" from the overall point of view, and based on "copying" from a local (between two regions) point of view.
l Predictable pause: The user can explicitly specify that in a time segment of length M milliseconds, the time spent on garbage collection shall not exceed N milliseconds.
Process:
l Initial mark: stop the world marks the object that GC Roots can directly associate with
l Concurrent marking: reachability analysis
l Final mark: Correct a part of mark records that are changed due to the user program continuing to run during concurrent mark
l Screening and recycling: The screening and recycling stage first sorts the recycling value and cost of each Region, and formulates a recycling plan according to the user's expected GC pause time
memory allocation rules
Triggering GC involves memory allocation rules: (objects are mainly allocated in Eden, if the local thread allocation buffer is started, it will be allocated on TLAB first)
l Objects are preferentially allocated in Eden
A Minor GC is initiated when there is not enough space in the Eden area
l Large objects directly enter the old age
Typical large objects are very long strings and arrays
l Long-lived objects enter the old age
Each object has an age counter. After each GC, the counter value increases by one. When it reaches a certain level (default 15), it will enter the old age. The age threshold can be set by the parameter -XX:MaxTenuringThreshold
Determination of target age
The sum of the size of all objects of the same age in the Survivor space is greater than half of the Survivor space. Objects whose age is greater than or equal to this age can directly enter the old age without waiting for the age required by MaxTenuringThreshold
l Space allocation guarantee
Before the Minor GC occurs, the JVM will check whether the maximum available continuous space in the old generation is larger than the total space of all objects in the new generation. If it is larger, the Minor GC is safe. If it is not larger, the JVM will check whether the HandlePromotionFailure allows the guarantee to fail. , then change to a Full GC. If the guarantee is allowed to fail, check whether the maximum available continuous space in the old generation is greater than the average size of the objects promoted to the old generation. If it is greater, try to perform Minor GC; Full GC
Finally, it is mentioned that the method area is also recycled:
There are two main parts of the permanent generation: abandoned constants and useless classes
Abandoned constant recycling is similar to object recycling
Useless classes must meet 3 conditions
l All instance objects of the class have been recycled
l The ClassLoader that loaded the class has been recycled
l The Class object of this class is not referenced anywhere, and the methods of this class cannot be accessed through reflection anywhere
4, JVM common commands
JDK command line tools
Jps
View virtual machine processes
Jstat
Monitor various running status information of virtual machines
Jinfo
View and adjust various parameters of the virtual machine
Jmap
Production heap dump snapshots (commonly known as heapdump or dump files)
Query the finalize execution queue, Java heap and permanent generation details, such as space usage, which collector is currently in use
Jhat
Analyze heap dump snapshots
Jstack
The thread snapshot of the current moment of the production virtual machine (generally called threaddump or javacore file)
visualization tool
Jconsole
VisualVM
The most powerful runtime monitoring and troubleshooting tool ever released by the JDK
Has little impact on the actual performance of the application and can be directly applied in production environments
Plug-in form extension
To be continued...