JVM runtime data area-heap (TLAB)

Heap—TLAB allocates memory for objects

Why is there TLAB?

  1. The heap area is a thread shared area, and any thread can access the shared data in the heap area;
  2. Since the creation of object instances is very frequent in the JVM, it is not thread-safe to divide the memory space from the heap area in a concurrent environment;
  3. In order to avoid multiple threads operating the same address, a mechanism such as locking is required, which in turn affects the allocation speed.

What is TLAB?

TLAB(Thread Local Allocation Buffer):

  1. From the perspective of memory model rather than garbage collection, continue to divide the Eden area. JVM allocates a private cache area (mentioned in the stack) for each thread, which is contained in the Eden space;
  2. When multiple threads allocate memory at the same time, using TLAB can avoid a series of non-thread safety issues, and at the same time can improve the throughput of memory allocation, so this memory allocation method can be called a fast allocation strategy;
  3. As far as we know, all JVMs derived from OpenJDK provide the design of TLAB.
    Insert picture description here
  4. Each thread has a TLAB space;
  5. When the TLAB of a thread is full, the public area (blue) can be used.

Description

  1. Although not all object instances can successfully allocate memory in TLAB, JVM is indeed the first choice for memory allocation in TLAB.

  2. In the program, the developer can set whether to open the TLAB space through the option -XX:UseTLAB.

  3. By default, the memory of the TLAB space is very small, occupying only 1% of the entire Eden space. Of course, we can set the percentage of the Eden space occupied by the TLAB space through the option -XX:TLABWasteTargetPercent.

  4. Once the object fails to allocate memory in the TLAB space, the JVM will try to ensure the atomicity of data operations by using the locking mechanism, thereby directly allocating memory in the Eden space.

    Note: Which thread needs to allocate memory is allocated in the local buffer of which thread. Only when the local buffer is used up, synchronization lock is needed when allocating a new buffer area-"In-depth understanding of JVM" third edition.

Code demo

Code example:

//-XX:UseTLAB参数是否开启的情况:默认情况是开启的
public class TLABArgsTest {
    
    
    public static void main(String[] args) {
    
    
        System.out.println("我只是来打个酱油~");
        try {
    
    
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
    
    
            e.printStackTrace();
        }
    }
}
  • Enter jsp in the terminal to view the TLABArgsTest process id;
  • jinfo -flag UseTLAB 36732 (process id), output -XX:+UseTLAB, which proves that TLAB is enabled by default.
    Insert picture description here

TLAB allocation process
Insert picture description here

Summary of parameter settings for heap space

 -XX:PrintFlagsInitial: 查看所有参数的默认初始值
 -XX:PrintFlagsFinal:查看所有的参数的最终值(可能会存在修改,不再是初始值)具体查看某个参数的指令:
       - jps:查看当前运行中的进程;
       - jinfo -flag SurvivorRatio 进程id: 查看新生代中Eden和S0/S1空间的比例.
 -Xms: 初始堆空间内存(默认为物理内存的1/64-Xmx: 最大堆空间内存(默认为物理内存的1/4-Xmn: 设置新生代大小(初始值及最大值)
 -XX:NewRatio: 配置新生代与老年代在堆结构的占比
 -XX:SurvivorRatio:设置新生代中Eden和S0/S1空间的比例
 -XX:MaxTenuringThreshold:设置新生代垃圾的最大年龄(默认15)
 -XX:+PrintGCDetails:输出详细的GC处理日志
         打印gc简要信息:① -XX:+PrintGC   ② -verbose:gc
 -XX:HandlePromotionFailure:是否设置空间分配担保

Description

Before the occurrence of Minor Gc, the virtual machine checks whether the maximum available continuous space in the old generation is greater than the total space of all objects in the new generation.

  • If it is greater than, then the Minor GC is safe;
  • If it is less than, the virtual machine checks whether the -XX:HandlePromotionFailure setting value allows guarantee failure. If HandlePromotionFailure=true, it will continue to 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 than, try to perform a Minor GC, but this time Minor GC is still risky;
    -If it is less than, then perform a Full GC instead.
    If HandlePromotionFailure=false, then perform a Full GC instead.

historic version:

  1. After JDK6 Update 24, the HandlePromotionFailure parameter will no longer affect the space allocation guarantee policy of the virtual machine. Observe the source code changes in openJDK. Although the HandlePromotionFailure parameter is also defined in the source code, it is no longer used in the code.
  2. The rule after JDK6 Update 24 is that as long as the continuous space of the old generation is larger than the total size of the new generation object or the average size of previous promotions, Minor GC will be performed, otherwise Full GC will be performed. That is, HandlePromotionFailure=true.

Guess you like

Origin blog.csdn.net/qq_33626996/article/details/114042737