Before starting this article, I’ll assume that you understand the process by which the JVM creates objects and allocates memory addresses, as well as JVM memory partitioning. I’m going to put up a picture for humanitarian reasons, so you can see the contrast.
Is there a multithreaded safety issue with heap allocation?
A: Possible;
new Object();
We all know that this eventually requires a chunk of memory space in the heap, so if the heap is shared by all threads, is there a safety issue in the concurrent creation of objects by the JVM?
In order to solve this problem, we first think of locking, but there is a problem with locking, which affects performance.
TLAB (Thread Local Allocation Buffer)
TLAB is a thread local allocation buffer. It is a thread local allocation buffer. It is a thread local allocation buffer
If an object has not been collected, the number of times it has survived is +1. If the number of times it has not been collected reaches 15, then the object is promoted to the old age.
So we know that object allocation is first carried out in Eden zone, so it is not difficult to understand the above diagram. We divide a region in Eden zone, we call it TLAB, each TLAB is private, so that concurrent creation of objects does not need to do such operations as locking. This solves the existing security problem.
If the allocated TLAB space is used up or the object needs more memory space than the TLAB can provide, then the space can only be allocated in the common Eden or old space.
conclusion
- 1, THE JVM preferred TLAB memory space allocation;
- 2. TLAB occupies 1% of the Eden area. This value can also be customized by parameter.
This problem also leads to another problem: the heap area is not strictly shared by threads.