Optimistic and pessimistic locking data are used to solve competition problems in concurrency scenarios, but it is two completely different ideas. Their use is very extensive, is not limited to a programming language or database.
The concept of optimistic locking
The so-called optimistic locking, referring to the operation when data is very optimistic, optimistic that others will not modify data simultaneously, optimistic locks are not locked, only when to perform the update will modify to judge whether others in the meantime the data, the data is modified if others give up, otherwise perform the operation.
Pessimistic locking concept
The so-called pessimistic locking, referring to the operation when data is relatively pessimistic, pessimistically think others will modify data simultaneously, pessimistic locking in operation data is data directly to the lock, the lock will be released until after the operation is completed, in other people can not be locked during the operation data.
Optimistic locking implementation
Optimistic locking implementations are mainly two types of CAS (Compare and Swap, compare and exchange) mechanism, one is the version number of mechanisms.
CAS mechanism
CAS operation includes three operands, namely memory location to be read (V), comparing the expected value (A) and the new value (B) intended to be written, logic operation, if the value of the memory location V equal to the expected value A, this position is updated to the new value B, or does not operate. In addition, many operations are CAS spin, meaning that, if the operation is not successful, would have been retried until the operation succeeds.
The version number of mechanisms
The basic idea of the mechanism of the version number, a version field is increased in the data used to indicate the version number of the data, each time data is modified version number is increased by one. When a thread when the query data, reads the version number of the data out together, after the need to update the data in the thread, when it will be read before the version number is compared with the current version number, if consistent, the operation is performed, and if not, then abort the operation.
Pessimistic locking implementation
Pessimistic locking implementation that is locked, locked either in the Code level (such as the synchronized keyword in Java), you can (such as MySQL, exclusive lock) at the database level.
Optimistic and pessimistic locking lock strengths and weaknesses and usage scenarios
Optimistic and pessimistic locking and no better or worse, they have their own appropriate scene.
Functional limitations
Compared with the pessimistic optimistic locking lock, applicable scene has been more limited, whether it is the version number CAS mechanism or mechanisms.
For example, the mechanism can only guarantee atomic CAS single variable operation, when it comes to a plurality of variables, CAS mechanism is powerless, and it can be synchronized to the entire block of code lock processing; another example, if the version number of mechanisms query data in table 1 is for the time, but when the data is updated for table 2, it is difficult to achieve optimistic locking by a simple version number.
Level of competition
In less competitive (concurrency conflicts occur relatively small probability) scenario, optimistic locking advantage. Because the pessimistic locking will lock code block or data, other threads can not access the same time, we must wait on a thread releases the lock to enter the operation will affect the speed of response concurrent. In addition, the locking and releasing locks need to consume additional system resources, it will also affect the processing speed concurrent.
In the fierce competition (concurrency conflicts appear high probability) scenario, pessimistic locking the advantage. Because the optimistic lock when to perform the update, because the data may be modified and updated repeatedly fail, and then continue to retry, resulting in waste of CPU resources.
Whether optimistic lock is locked
Optimistic locking itself is not locked, only when updated to judge whether the data will be updated by other threads, such as AtomicInteger is an example. But sometimes optimistic locking may cooperate with locking operations, such as MySQL in the implementation of the updated data when the operation will add exclusive lock. Therefore be understood as optimistic locking itself is not locked, only when updating data may only be locked.
CAS shortcomings
The main disadvantage of CAS have the ABA problem, the cost problem of high competition and limited functionality itself.
ABA problem
The so-called ABA problem, refers to a thread when manipulating data, there is another thread to perform a series of operations data, but re-read the data in the thread when the data has been modified and that a thread start reading the same data, the thread will not know that the data has been modified, then the CAS operation is judged to be a success.
ABA problem in some scenes may not cause any harm, but in some scenarios it might cause problems. CAS is the top of the stack, such as operating data, stack data, although after two (or more) change after the restoration of the original value, but it is likely that the stack has changed, change the stack data could cause some problem.
For the ABA problem, the more effective the program is the introduction of the version number. As long as the value in memory changes, the version number is incremented, when the CAS during the operation not only compare the value of memory, but also compare version numbers, only when both are not changed, CAS operations to execute successfully. Java classes that are applicable in AtomicStampedReference version number to resolve the problem of ABA.
Overhead problem of high competition
The probability of concurrent conflict is large highly competitive scenario, if the CAS operation has failed, would have been retried, causing a large CPU overhead problem. To address this problem, a simple idea is the introduction of exit mechanism, if the number of retries exceeds a certain threshold, it failed to force quit. Of course, it is best to avoid using optimistic locking in a highly competitive scenario.
Their functional limitations
CAS features is relatively limited, to ensure that only a single variable such as CAS (or a single memory value) atomic operation. This means that atomicity does not necessarily guarantee thread safety when it comes to multiple variables (or multiple memory values), CAS can not help it. In addition, CAS implementation requires hardware support level processor in Java ordinary users can not be used directly, only by means of atomic class at atomic packets to use, limited flexibility.
" New friends do not know the old temper, old friends did not know a new life. "