https://www.cnblogs.com/aspirant/p/6930436.html
ReentrantLock provides more advanced features for its own lock and unlock: fair lock, timed lock, conditional lock, pollable lock, interruptible lock. It can effectively avoid deadlock liveness problems
Read-write locks resolve mutual exclusion between read and read. Read-write locks are suitable for reading more and writing less, and can achieve better concurrency.
In addition to synchronized, we can also use the reentrant lock
(ReentrantLock) in the java.util.concurrent (hereinafter referred to as JUC) package to achieve synchronization. In basic usage, ReentrantLock is very similar to synchronized, and they both
have the same thread re -entry The entry feature is only a little different in code writing. One is a mutex at the API level
(the lock() and unlock() methods are done with try/finally blocks), and the other is a
mutex . However, compared with synchronized, ReentrantLock adds some advanced functions, mainly the following three items: waiting for
interruptible, fair lock, and lock can be bound to multiple conditions.
Waiting can be interrupted 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. The interruptible feature is very helpful for processing synchronized blocks with very long execution time.
A fair lock means that when multiple threads are waiting for the same lock, they must obtain the lock in the order of time of applying for the lock;
an unfair lock does not guarantee this. When the lock is released, any thread waiting for the lock has Chance to acquire lock.
Locks in synchronized are unfair, and ReentrantLock is also unfair by default, but
fair locks can be required through the constructor with a boolean value.
Lock binding multiple conditions means that a ReentrantLock object can bind multiple Condition objects at the same time, and in
synchronized, the wait() and notify() or notifyAll() methods of the lock object can implement an implicit
condition , if To be associated with more than one condition, an additional lock has to be added, and ReentrantLock is
No need to do this, just call the newCondition() method multiple times.
https://www.cnblogs.com/qjjazry/p/6581568.html
An implementation of optimistic locking - CAS (Compare and Swap compare and exchange):
There are three operands in a CAS operation - the memory location to be read or written (V), the expected old value to be compared (A), and the new value to be written (B). If the value of memory location V matches the expected original value of A, then the processor will automatically update the location value to the new value of B. Otherwise the processor does nothing. In either case, it returns the value at that location before the CAS instruction. (Some special cases of CAS will only return whether CAS succeeded, not extract the current value.) CAS effectively says " I think position V should contain value A; if it does, put B in this position; Otherwise, don't change the position, just tell me the current value of this position ." This is actually the same as the conflict check + data update principle of optimistic locking.
Here again, optimistic locking is an idea. CAS is an implementation of this idea.
Volatile variables in the Java language can be thought of as a "lesser synchronized"
You can only use volatile variables instead of locks in limited circumstances. For a volatile variable to provide ideal thread safety, both of the following conditions must be met:
- Writes to variables do not depend on the current value.
- The variable is not contained in an invariant with other variables.
To deal with the above isolation levels, the following methods are used:
事务隔离五种级别：
TRANSACTION_NONE 不使用事务。
TRANSACTION_READ_UNCOMMITTED 允许脏读。
TRANSACTION_READ_COMMITTED 防止脏读，最常用的隔离级别,并且是大多数数据库的默认隔离级别
TRANSACTION_REPEATABLE_READ 可以防止脏读和不可重复读，
TRANSACTION_SERIALIZABLE 可以防止脏读，不可重复读取和幻读，（事务串行化）会降低数据库的效率