JVM memory allocation and application process
When using the new keyword or any other method to create an object of a class, the JVM needs to allocate memory for the object. The size of the object is determined after the class is loaded, so allocating memory simply allocates a block of equal size in the Java heap. JVM Memory can be allocated in two ways: pointer collision and free list.
Pointer collision mode
If the Java heap memory is neat arrangement, all be used in one side, within the available free to deposit, the middle place a pointer as the cut-off point, in need of new objects allocated memory, as long as to move a pointer to the free memory and object is equal to the size of the distance can be assigned.
Represents the GC collector
ParNew, Serial, G1
Free list mode
If the Java heap memory is not neat arrangement, used memory and free memory is mutual crisscross, this case will not be able to use pointer collision way to allocate memory, the Java virtual machine needs to maintain a list to record what memory is available, for the new object allocate memory, in the list to find a large enough piece of memory allocation, And update the records on the list.
Represents the GC collector
cms
Java VM selection policy
The way the Java VIRTUAL machine allocates memory for newborn objects depends on the garbage collector used. When the garbage collector has collation, the virtual machine uses pointer collisions. When the garbage collector’s collection process does not have a collation process, the free list approach is used.
Now the virtual stack is allocated
This part belongs to the two-part allocation mechanism when the JVM creates Thread objects:
-
Direct allocation: local variables, formal parameter list.
-
Optimized allocation: Escape analysis (allocation on the stack, scalar substitution, etc.).
If the allocation is completed, the memory allocation ends. Otherwise, the allocation fails, or the allocation operation cannot be carried out, and the heap memory will be allocated.
Allocation of New Student Area -Eden Area
TLAB memory allocation strategy
As mentioned above, there are two main memory Allocation mechanisms: if pointer collisions are used, performance problems and pointer Allocation conflicts will occur. The JVM uses an optimization method, namely TLAB (ThreadLocal Allocation Buffer), to allocate memory blocks in advance.
Overall memory allocation process strategy
If TLAB memory allocation fails or there is insufficient space, the JVM will try to initialize a memory region in Eden for the related Java objects. When Eden space is sufficient, the memory allocation ends
When Eden region memory cannot be allocated, a MinorGC occurs (the JVM tries to free all inactive objects in Eden (MinorGC), and if Eden space is still insufficient to fit new objects, it tries to put some of Eden’s active objects into Survivor zone).
At this time, the Survivor area is used as the intermediate exchange area between Eden and Old. If the Survivor area is insufficient to place objects in Eden area, the guarantee allocation will be carried out, or the conditions for direct promotion to the old age have been reached. At this time, if the old area is free, objects in the Survivor area will be moved to the old area.
When the old region runs out of space, the JVM does a major collection in the old region.
After garbage collection is complete, if the Survivor and old zones still cannot store some objects copied from Eden, the JVM cannot create a memory region for the new objects in Eden, then an “Out of memory error “occurs.
- The JVM is preferentially allocated in Eden
- When the Eden space is sufficient, the memory application ends.
JVM lock inflation execution flow mechanism
Lock-free node/biased locking phase
When a thread is created, it will first allocate memory based on the above mentioned memory allocation strategy when the program executes to the synchronized code block. At this time, when the current thread has acquired the relevant lock resource, it will be converted to biased lock because it is in the lock free state:
Lockless tag header
Bias the lock tag header
- Assigns the thread ID of the relevant current thread to the associated tag field.
- In order to improve the performance and the stack space can obtain the relevant race data, the object header Markword field is copied to the stack space internal Lock Record.
Lightweight lock stage
Contention to the lock thread
At the same time, when another thread also compets for the resource, the competition needs to be carried out, because in the process of obtaining the resource, the CAS mechanism is adopted at the bottom to obtain the relevant resource mark. Once the resource is obtained successfully, it can judge whether it belongs to the current lock owner thread by biased lock mark.
The lock field in the Header of the Java object is changed to 00, as shown in the following figure, because only one thread is allowed to acquire the resource at a time.
Threads that are not contended for locks
When the CAS mechanism fails, the relevant spin mechanism is used to try to grab the lock next time.
Heavyweight locking phase
Threads that are not contended for locks
- When a thread that exceeds spin remains in spin and exceeds the spin threshold, it is upgraded to a heavyweight lock.
Or 2. Unheavyweight locks will be upgraded when more threads are in contention and are spinlocks (when there are lots of lightweight locks).
- Until awakened to re-mirror competing lock resource information.
Upgrading to a heavyweight lock results in a thread flag position of 10
Instead of a spin CAS race, execution is blocked directly (using the underlying MUtex /Fast Mutex lock to suspend the execution of the interrupted thread).
Contention to the lock thread
-
When the lock marker changes and becomes a heavyweight lock, the thread synchronizes its own record, finds the discrepancy, synchronizes to the heavyweight lock state, releases the lock, and wakes up the thread in the blocked state.
-
The lock state is temporarily in the heavyweight lock state. There will be an article on lock degradation, which can be complex, different scenarios, and different JVM requirements.
