The difference between synchronized and Java.util.concurrent.locks.Lock [turn]

Brief answer:

1.Lock can complete almost all synchronized functions, and there are some features that the latter does not have, such as lock voting, timed lock waiting, interruptible lock waiting, etc.

2.synchronized is the Java language level, is a built-in keyword, lock is a package that appears in JDK 5, when used, synchronized synchronous code block can be automatically released by the JVM; Lock requires the programmer to manually release it in the Finally block, If not released, it can cause unpredictable consequences (in a multithreaded environment).

Synchronized Quick review:

1. What happens to the code after the code block is added to the synchrozized?

Answer: There are two changes. One is atomicity (atomicity) and one is visibility (visibility). Atomicity means that only one thread at a time can get a code lock and go into a block of code surrounded by synchronized. The visibility is the consistency of the variable changes in different scopes. The emphasis on variable visibility and consistency is due to the fact that in Java memory, memory caches and compiler optimizations can cause a variety of anomalous behavior under multithreaded conditions. In general, threads are in a way that does not have to be immediately visible to other threads (regardless of the threads in registers , processor -specific caches (CPU caches), or other compiler Optimizations), not constrained by the value of the cached variable, but after the Synchronized keyword is added, the runtime will ensure that a thread-to-variable update is preceded by an update to an existing synchronized block. When you enter another block that is protected by the same monitor (lock) synchronized , the updates to the variables are immediately visible. Similar rules exist in the volatile variable

2. Why do I need Java.util.concurrent.lock?

The main synchronized is the older implementation mechanism, designed earlier and has some functional limitations:

--it cannot interrupt a thread that is waiting to acquire a lock

-You can't get a lock by voting, and if you don't want to wait, you can't get a lock.

--synchronization also requires that the release of the lock be made only in the same stack frame as the stack frame where the lock was obtained

3. Re-entry lock Reentrantlock

java.util.concurrent.lockThe framework in a Lock lock is an abstraction that allows the implementation of a lock to be implemented as a Java class, rather than as a language feature.

This leaves space for a variety of Lock implementations that may have different scheduling algorithms, performance characteristics, or locking semantics.

ReentrantLockClass is implemented Lock , it has the synchronized same concurrency and memory semantics, but adds some features like lock polling , timed lock waiting , and interruptible lock waiting .

In addition, it provides better performance in the case of intense contention. (In other words, when many threads are trying to access a shared resource, the JVM can spend less time dispatching the thread and more of it to the execution thread.) ）

What does the reentrant lock mean? Simply put, it has a lock-related get counter, if one of the threads that owns the lock gets the lock again, then the fetch counter increases by 1, and then the lock needs to be freed two times to get a true release. This mimics synchronized the semantics; If a thread enters a synchronized block protected by a monitor that the thread already owns, it allows the thread to proceed, and when the thread exits the second (or subsequent) synchronized block, does not release the lock, only the thread exits it enters the first of the monitor protection synchronizedblock, the lock is released.

New Reentrantlock (); Lock.lock (); Try {   //  Update ObjectState}finally  {  lock.unlock ();}

As you can see from the above code, Lock there is a clear distinction between synchronized and--lock that must be released in the finally block. Otherwise, if the protected code throws an exception, the lock may never be released! This difference may seem like nothing, but in fact it is extremely important. Forgetting to release a lock in a finally block may leave a time bomb in the program, and when the bomb explodes one day, it takes a lot of effort to find the source. With synchronization, the JVM will ensure that the lock is automatically freed.

The difference between synchronized and Java.util.concurrent.locks.Lock [turn]