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

This article will explain in detail how to achieve pessimistic lock and optimistic lock in Java. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Pessimistic lock

Assume that concurrency conflicts occur; the data is locked throughout the data processing. An exclusive lock is a pessimistic lock, and an synchronized is an exclusive lock that assumes the worst and executes only if other threads are not interfered with, causing all other threads that need a lock to hang and wait for the thread holding the lock to release the lock.

Optimistic lock

It is assumed that concurrency conflicts do not occur; the data is processed without locking, and if the processing fails and conflicts arise, try again until successful. When the data contention is not serious, the optimistic lock is better. For example, CAS is an application of optimistic locking thought.

Mutually exclusive synchronization / blocking synchronization (pessimistic strategy)

Synchronization refers to ensuring that shared data is used by only one thread (or some, when semaphores are used) at a time when multiple threads access shared data concurrently. Critical region (CriticalSection), mutex (Mutex) and semaphore (Semaphore) are the main mutual exclusion methods.

Synchronized

Synchronized is the basic means of mutex synchronization in Java. After the synchronized keyword is compiled, two bytecode instructions, monitorenter and monitorexit, will be formed before and after the synchronization block. Both bytecodes need a parameter of reference type to indicate the object to be locked and unlocked. If the synchronized in the Java program explicitly specifies the object parameters, that is, if the reference; of the object is not clearly specified, then according to whether the synchronized modifies the instance method or class method, take the corresponding object instance or Class object as the lock object.

ReentrantLock

ReentrantLock is another means of mutex synchronization provided by JUC in JDK1.5. In basic usage, ReentrantLock and synchronized are very similar, they both have the same thread reentry characteristics, but there are some differences in code writing. One is mutex at API level (lock () and unlock () method is completed with try/finally statement block), and the other is mutex at native syntax level. However, compared with synchronized,ReentrantLock, there are some advanced features, including the following three items: wait interruptible, fair lock, and lock can be bound to multiple conditions.

Wait interruptible

Wait interruptibility means that when the thread holding the lock does not release the lock for a long time, the waiting thread can choose to give up waiting and deal with other things instead. Interruptibility is very helpful in dealing with synchronous blocks with very long execution time.

Fair lock

Fair lock means that when multiple threads wait for the same lock, they must acquire the lock in turn according to the time order in which they apply for the lock, while the unfair lock does not guarantee this. When the lock is released, any thread waiting for the lock has a chance to acquire the lock. Locks in synchronized are unfair, and ReentrantLock is unfair by default, but fair locks can be required through a Boolean constructor.

Bind multiple conditions

Lock binding multiple conditions means that a ReentrantLock object can bind multiple Condition objects at the same time, while in synchronized, the lock object's wait () and notify () or notifyAll () methods can achieve an implied condition. If you want to associate with more than one condition, you have to add a lock, while ReentrantLock does not need to do so, you only need to call the newCondition () method multiple times.

Non-blocking synchronization (optimistic strategy)

The main problem with mutex synchronization is the performance problems caused by thread blocking and waking up, so this synchronization is also called blocking synchronization (Blocking Synchronization). Non-blocking synchronization is an optimistic concurrency strategy that does not require threads to be suspended. If no other thread competes for shared data, the operation succeeds; if there is contention for shared data and conflicts arise, then take other compensation measures (the most common compensation measure is to keep retrying until successful).

Compare and exchange CAS (Compare-and-Swap)

The CAS instruction requires three operands, namely the memory location (which can be simply understood as the memory address of the variable in Java, represented by V), the old expected value (represented by A), and the new value (represented by B). When the CAS instruction is executed, when and only if V meets the old expected value A, the processor updates the value of V with the new value B, otherwise it does not perform the update, but the old value of V is returned regardless of whether the value of V is updated or not. the above process is an atomic operation. After JDK1.5, the CAS operation can be used in the Java program, which is provided by several method wrappers such as compareAndSwapInt () and compareAndSwapLong () in the sun.misc.Unsafe class. The virtual machine does special treatment to these methods internally, and the result of instant compilation is a platform-related processor CAS instruction, no method call, or can be considered unconditional inline.

ABA problem

If a variable V is read as A value for the first time and checks that it is still A value when preparing for assignment, can we say that its value has not been changed by other threads? If its value has been changed to B and then changed back to A during this period, the CAS operation will mistakenly assume that it has never been changed. To solve this problem, the J.U.C package provides an atomic reference class "AtomicStampedReference" with tags, which ensures the correctness of the CAS by controlling the version of the variable value. In most cases, the ABA problem will not affect the correctness of program concurrency. If you need to solve the ABA problem, switching to traditional mutex synchronization may be more efficient than atomic classes.

On how to achieve pessimistic lock and optimistic lock in Java to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.