# Optimistic and pessimistic locking
lock up a macro classification can be divided into pessimistic locking and optimistic locking. Note here that the locks can be locked in the database, it can be in the Java development language such as lock technology. Optimistic and pessimistic locking lock is really just a kind of concept (a general term for a particular kind of lock) is not a language or a proprietary technology lock technology.
Optimistic locking is an optimistic idea that think reading and writing less, low probability of concurrent write encounter, every time the data are to pick up other people think is not modified, it will not be locked, but will be updated when in the meantime determine what others did not go to update the data, take the first reads the current version at the time of writing, then lock operation (compare to keep up with a version number, as if the update), if it fails we will have to repeat read - comparison - write operation. Basic optimistic locking in java are realized by CAS operation, CAS is an update of an atomic operation, compares the current value with the incoming value is the same as the update fails otherwise. Shared lock database is an optimistic locking.
Pessimistic locking is pessimistic that the idea that believes write more, experiencing a high probability of concurrent write, pick up data every time the thought that others will modify, so every time the lock when reading and writing data, so people think this will block read and write data until I got the lock. java typical pessimistic locking lock is in the Synchronized, AQS framework is the first attempt to acquire cas optimistic locking lock, get less, will be converted to a pessimistic lock, such as ReentrantLock. Database exclusive lock is also a pessimistic locking.
Fair locking and non-locking fair #
thread gets preempted under lock mechanism, the lock can be divided into equity and non-equity lock lock lock fair representation order thread acquires the lock of the lock request is in accordance with the thread of time to decide sooner or later, that is the first request lock thread will first acquire the lock. Rather than the fair broke into the lock at run time, which is not necessarily first come first served.
ReentrantLock provides a fair and non-realized fair locks.
Fair locks: ReentrantLock pairLock = new ReentrantLock (true ).
Unfair lock: ReentrantLock pairLock = new ReentrantLock (false ). If the constructor does not pass parameters, the default non-fair lock.
For example, assume that A thread already owns the lock, the thread B at this time the lock request which will be suspended. When the thread A releases the lock, if the current thread C has also need to acquire the lock, the lock if unfair manner, according to the thread scheduling policy, one thread B and C both thread may acquire the lock, which does not require any other time interference, and if you need to use a fair lock C should hang, let B get the current locks.
Try to use unfair lock on the premise of no demand for fairness, because fairness lock will bring performance overhead.
Exclusive lock and a shared lock #
can only be held under lock single thread or multiple threads can be held in common, the lock can be divided into exclusive lock and a shared lock.
Exclusive lock at all times ensure that only one thread can be locked, ReentrantLock is exclusively implemented. Shared lock can be held by multiple threads simultaneously, e.g. ReadWriteLock read-write locks, which allows a resource can be simultaneously read operation multithreading.
Exclusive lock is a pessimistic locking, because the resources have to add each access the mutex lock, limiting concurrency, because the read operation does not affect the consistency of the data, but only allows exclusive lock at the same time by a thread read the data, other threads must wait for the current thread releases the lock to be read.
Shared lock is an optimistic locking, which relaxed the conditions for locking allows multiple threads simultaneously read.
Reentrant lock #
When a thread to get an exclusive lock is held by another thread, the thread is blocked, then when one thread acquires the lock has acquired its own again whether it will be blocked? If not blocked, then we say that the lock is reentrant, that is, as long as the thread acquires the lock, you can unlimited number of times (strictly limited number) to enter the lock code is locked.
The Copy
public void helloA the synchronized () {
...
}
public void helloB the synchronized () {
...
helloA ();
}
In the above code, the first method will first acquire call helloB lock built, then print output. After helloA method call will go to get a lock built before the call, if the built-in lock is not reentrant, the calling thread will always be blocked.
Indeed, synchronized internal reentrant lock is locked. Reentrant lock principle is maintained in a locked internal thread mark, used to indicate the lock which is currently occupied by a thread, and then associate a counter. A start counter value is 0, the lock is not occupied by any thread. When a thread gets the lock, the value of the counter becomes 1, you will find yourself lock owner is not being blocked pending At this time the other thread to acquire the lock again.
But I found that when the thread acquired the lock again lock owner acquires the lock of their own, will add the +1 counter value, after the release of the lock counter value of -1. When the counter value is 0, locked inside thread is reset to indicate null, this time blocked thread can be awakened to compete to acquire the lock.
Spin lock #
Since Java threads is operating system thread-one correspondence, so that when a thread after obtaining the lock (such exclusive lock) fails, the state is switched to the kernel is suspended. When the thread gets the lock time and need to switch to the kernel state and wake up the thread. The switch from the user state to state kernel overhead is relatively large, to a certain extent, will affect the concurrent performance. Spinlock is, when the current thread to acquire the lock if the lock has been found to be possessed by other threads, it does not immediately blocked their own, without giving up the right to use the CPU, several attempts to get (the default number is 10, you can use -XX: PreBlockSpinsh parameter setting the value), it is likely behind several attempts in the other thread has released the lock. If the specified number of attempts still did not get to lock the current thread will be blocked pending. Seen in this light is to use a spin lock in exchange thread CPU time blocking and scheduling overhead, but they are probably wasted CPU time.
