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

This article mainly explains the detailed explanation of pessimistic lock and optimistic lock of Java concurrent lock. The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn the detailed explanation of pessimistic lock and optimistic lock of Java concurrent lock.

Both synchronized and Lock are pessimistic locks, believing that other threads must modify the data when it is used, so locks are added when the data is obtained to ensure that it is not modified by other threads.

Synchronized code block:

Public synchronized void update () {/ / synchronization resources} Lock code block: public void update () {Lock lock = new ReentrantLock (); lock.lock (); try {/ / synchronization resources} finally {lock.unlock ();}}

Optimistic lock, which assumes that no other thread will modify the data when using the data, so the lock will not be added. It is only when you are about to update that you determine whether the previous data has been modified by another thread. If it is not modified, the modification will be successful, on the contrary, the modification will not be successful. The most typical example here is that the increment operation in the java.util.concurrent concurrent package is achieved through CAS spin.

CAS code block

Public class TestLock {AtomicInteger atomicInteger = new AtomicInteger (0); public int add () {return atomicInteger.incrementAndGet ();}}

What is the full name of CAS,CAS is Compare And Swap (compare and Exchange), which is a lock-free algorithm. Variable synchronization between multithreads is achieved without using locks (no threads are blocked).

Summary: here we can draw a conclusion that pessimistic locks are suitable for scenarios with many write operations, and adding locks first can ensure that the data is correct during write operations. Optimistic lock is suitable for scenarios with many read operations, and the characteristic of unlocking can greatly improve the performance of read operations. However, since jdk1.8, java has optimized synchronized, and its performance has been greatly improved. But the optimistic lock CAS is not so perfect. At present, it has three major problems.

ABA problem (there is a solution after JDK1.5): CAS needs to check whether the memory value has changed when manipulating the value, and the memory value will not be updated until there is no change. But if the memory value is originally A, then B, and then A, then CAS checks and finds that the value has not changed, but it has actually changed. The solution to the ABA problem is to add the version number in front of the variable and add the version number to one every time the variable is updated, so that the change process changes from "A-B-A" to "1A-2B-3A".

Long cycle time and high overhead: if the CAS operation is not successful for a long time, it will cause it to spin all the time, which brings a lot of overhead to the CPU.

Only one atomic operation of shared variable can be guaranteed (there is a solution after JDK1.5): CAS can guarantee atomic operation when operating on a shared variable, but CAS cannot guarantee atomicity when operating on multiple shared variables.

Thank you for your reading, the above is the content of "pessimistic lock and optimistic lock of Java concurrent lock". After the study of this article, I believe you have a deeper understanding of the problem of pessimistic lock and optimistic lock of Java concurrent lock, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.