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

This article mainly introduces how to use StampedLock, the introduction in the article is very detailed, has a certain reference value, interested friends must read!

In the face of the problem of resource management in critical areas, there are generally two sets of ideas:

The first is to use a pessimistic strategy. Pessimists think that every time I visit a shared variable in the critical area, someone will always conflict with me, so every time I visit, I have to lock the whole object and unlock it after completing the visit.

On the contrary, optimists believe that although the shared variables in the critical area will conflict, the conflict should be a low-probability event, and in most cases, it should not happen, so I can visit it first. if there is no conflict when I run out of data, then my operation will be successful; if I find that there is a conflict after I have finished using it, then I will either try again or switch to a pessimistic strategy.

It is not difficult to see from here that reentering locks and synchronized is a typical pessimistic strategy. As you may have guessed, StampedLock provides a tool for optimistic locking, so it is an important supplement to reentrant locks.

Basic use of StampedLock

A very good example is provided in the StampedLock documentation so that we can quickly understand the use of StampedLock. Let me take a look at this example, and the description of it is all written in the comments.

Here again explain the meaning of the validate () method. The function signature looks like this:

Public boolean validate (long stamp)

Its acceptance parameter is the postmark returned by the last lock operation. If the lock has not applied for a write lock before calling validate (), it returns true, which means that the shared data protected by the lock has not been modified, so the previous read operation is sure to ensure data integrity and consistency.

Conversely, if the lock has a successful write lock application before validate (), it means that the previous data read and write operations conflict, and the program needs to retry or upgrade to a pessimistic lock.

Comparison with reentrant lock

From the above example, it is not difficult to see that in terms of programming complexity, StampedLock is actually much more complex than locking, and the code is not as simple as it used to be.

So why do we use it?

The most essential reason is to improve performance! In general, the performance of this optimistic lock is several times faster than that of a normal reentrant lock, and the performance gap becomes wider and wider as the number of threads increases.

In short, the performance of StampedLock is to crush reentrant locks and read-write locks in a large number of concurrency scenarios.

But after all, there is nothing perfect in the world, and StampedLock is not omnipotent. Its disadvantages are as follows:

Coding is troublesome. If optimistic reading is used, the conflicting scenarios should be handled by themselves.

It is non-reentrant, and if you accidentally call it twice in the same thread, your world will be clean.

It does not support wait/notify mechanism

If the above three points are not a problem for you, then I believe StampedLock should be your first choice.

Internal data structure

In order to help you better understand StampedLock, here is a brief introduction to its internal implementation and data structure.

In StampedLock, there is a queue where threads waiting on the lock are stored. The queue is a linked list, and the elements in the list are an object called WNode:

When there are several threads waiting in the queue, the entire queue may look like this:

In addition to this wait queue, another particularly important field in StampedLock is long state, a 64-bit integer that StampedLock uses cleverly.

The initial value of state is:

Private static final int LG_READERS = 7; private static final long WBIT = 1L {/ / blocking in pessimistic read lock lock.readLock ();}); t2.start (); / guarantee that T2 blocks in read lock Thread.sleep (100); / / interrupt thread T2, which will cause the CPU of thread T2 to soar t2.interrupt () T2.join ();}}

In the above code, after interrupting T2, the CPU occupancy of T2 will be 100%. At this time, T2 is blocking the readLock () function, in other words, after the interruption, the read lock of StampedLock may be full of CPU. What is the reason for this? The little fool of the mechanism must have thought of it, because there are too many spins in the StampedLock! Yes, your guess is correct.

The specific reasons are as follows:

If there is no interruption, the thread blocking on readLock () will enter park () to wait after several spins, and once it has entered park () to wait, it will not occupy CPU. But the park () function has a feature, that is, once the thread is interrupted, park () will return immediately, the return does not count, it does not throw you any exceptions, then this is embarrassing. Originally, you wanted the thread of unpark () when the lock was ready, but now the lock is not good, you just interrupt, and park () returns, but, after all, the lock is not good, so you spin again.

It turns around and goes back to the park () function, but sadly, the thread's interrupt flag keeps on, and park () won't block, so the next spin starts again, and the endless spin doesn't stop, so CPU is full.

To solve this problem, essentially within StampedLock, when park () returns, you need to determine that the interrupt is marked as, and do the correct handling, such as exiting, throwing an exception, or cleaning up the interrupt bit, can solve the problem.

Unfortunately, at least in JDK8, there is no such treatment. So there is the problem that CPU is full after interrupting readLock () above. Please pay attention.

The above is all the contents of this article "how to use StampedLock". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

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.