Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "how to ensure thread safety in the memory allocation process of Java objects". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Before I get down to business, let me ask a question that doesn't seem to have anything to do with this question: how does the memory allocation process for Java objects ensure thread safety?

How does the memory allocation process of Java objects ensure thread safety?

We know that Java is an object-oriented language, and all the objects we use in Java need to be created. In Java, there are many ways to create an object, but in any case, memory allocation is required during the object creation process.

In the process of memory allocation of an object, it is mainly that the reference to the object points to this memory area, and then initializes the operation.

However, because the heap is globally shared, there may be multiple threads requesting space on the heap at the same time, so what if two threads point object references to the same memory area one after another in a concurrent scenario.

In order to solve this concurrency problem, the memory allocation process of objects must be controlled synchronously. But we all know that no matter which synchronization scheme is used (in fact, the virtual machine may be using CAS), it will affect the efficiency of memory allocation.

The allocation of Java objects is a high-frequency operation in Java, so people come up with another way to improve efficiency. Here we focus on a solution for a HotSpot virtual machine:

When each thread pre-allocates a small piece of memory in the Java heap and then allocates memory to the object, it allocates directly in its own "private" memory, and when this part of the area is used up, it allocates new "private" memory.

This scheme is called TLAB allocation, or Thread Local Allocation Buffer. This part of the Buffer is split from the heap, but is exclusive to local threads.

What is TLAB?

TLAB is a dedicated space divided by the virtual machine in the eden of heap memory and is thread-specific. When the TLAB function of the virtual machine is started, when the thread is initialized, the virtual machine allocates a piece of TLAB space for each thread, only for the current thread, so that each thread has a separate space, and if it needs to allocate memory, it allocates on its own space, so that there is no competition, which can greatly improve the efficiency of allocation.

Notice the descriptions of "thread exclusive", "for current thread use only" and "each thread owns separately" in the above description?

So, because of TLAB technology, heap memory is not completely shared by threads, and some space in its eden area is allocated exclusively to threads.

It is worth noting that we say that TLAB is exclusive to threads, but only in the "allocation" action, while reading, garbage collection and other actions are shared by threads. And there is no difference in use.

In other words, although each thread requests a piece of TLAB in heap memory during initialization, it does not mean that the memory in this TLAB area is completely inaccessible to other threads. Other threads can read it, but it is not possible to allocate memory in this area.

Moreover, after TLAB allocation, it does not affect the movement and collection of objects, that is, although objects may initially allocate memory through TLAB and stored in the Eden area, they will still be garbage collected or moved to Survivor Space, Old Gen, and so on.

It is also important to note that we say that TLAB is allocated in the Eden area because the eden area itself is not very large, and the memory of the Eden space is very small, accounting for only 1% of the total EDN space by default. Therefore, there must be some large objects that cannot be allocated directly in TLAB.

When it comes to large objects that cannot be allocated in TLAB, objects may still be allocated in the eden area or the old age, but this allocation requires synchronous control, which is why we often say that small objects are more efficient than large objects.

Problems brought by TLAB

Although to some extent, TLAB greatly improves the speed of object allocation, but TLAB is not without any problems.

As we said earlier, because the TLAB memory area is not very large, there may often be insufficient situations. There is an example in the practical Java virtual machine:

For example, the TLAB space of a thread has 100KB, in which 80KB is already used. When you need to allocate another 30KB object, it cannot be allocated directly in TLAB. In this case, there are two ways to deal with it:

1. If the amount of space needed by an object exceeds the remaining space in the TLAB, the object is allocated memory directly in the heap memory.

2. If the amount of space needed by an object exceeds the remaining space in the TLAB, the current TLAB is discarded and the TLAB space is re-applied for memory allocation.

The above two schemes have their own advantages and disadvantages. If scenario 1 is adopted, there may be an extreme situation in which only 1KB is left in the TLAB, which will result in most of the objects that need to be allocated later need to be allocated directly in the heap memory.

If solution 2 is adopted, there may be frequent abandonment of TLAB and frequent applications for TLAB, and we know that although allocating memory on TLAB is exclusive to threads, there may be conflicts in the process of dividing TLAB memory from the heap, so the allocation process of TLAB actually needs concurrency control. On the other hand, frequent TLAB allocation loses the meaning of using TLAB.

To solve the problem of these two schemes, the virtual machine defines a value of refill_waste, which can be translated as "maximum waste of space".

When the requested memory allocation is larger than refill_waste, it is selected to be allocated in heap memory. If it is less than the refill_ value, the current TLAB will be discarded and the TLAB will be recreated for object memory allocation.

In the previous example, the TLAB total space 100KB, uses 80KB, and the remaining 20KB. If the value of refill_waste is set to 25KB, then if the memory of the new object is greater than 25KB, then the memory of the new object is allocated directly. If it is less than 25KB, the previous TLAB will be discarded, a TLAB space will be re-allocated, and memory will be allocated to the new object.

Relevant parameters used by TLAB

The TLAB function can be enabled or disabled. You can specify whether to enable TLAB allocation by setting the-XX:+/-UseTLAB parameter.

TLAB defaults to 1% of the eden zone. You can set the percentage of Eden space occupied by TLAB space with the option-XX:TLABWasteTargetPercent.

By default, the space of the TLAB is constantly adjusted at run time to make the system run at its best. If you need to disable automatic resizing of TLAB, you can disable it with-XX:-ResizeTLAB and use-XX:TLABSize to manually specify the size of the TLAB.

The refill_waste of TLAB is also adjustable, with a default value of 64, which means that the space size of about 1 XX:TLABRefillWasteFraction 64 is used as the refill_waste and adjusted with the parameter:-XX:TLABRefillWasteFraction.

If you want to observe the usage of TLAB, you can trace it with the parameter-XX+PringTLAB.

Summary

To ensure thread safety in the memory allocation process of objects, the HotSpot virtual machine provides a technology called TLAB (Thread Local Allocation Buffer).

During thread initialization, the virtual machine allocates a piece of TLAB space for each thread, which is only used by the current thread. When it needs to allocate memory, it allocates on its own space, so there is no competition, which can greatly improve the efficiency of allocation.

Therefore, the phrase "heap is an area of memory shared by threads" is not entirely true, because TLAB is part of heap memory, and it is indeed shared by threads on reads, but exclusive to threads in terms of memory allocation.

TLAB doesn't really have much space, so large objects may still need to be allocated directly in heap memory. In that case, the memory allocation step of the object is to try TLAB allocation first, and then determine whether it should go directly into the old age after running out of space, and then determine whether it is re-eden allocation or old-age allocation.

This is the end of "how to ensure thread safety in the memory allocation process of Java objects". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.