Multiple locks commonly used (may be modified at any time)

In the Java memory model, there are main memories, and each thread has its own memory (for example, a register). For performance, a thread keeps a copy of the variable to be accessed in its own memory. This will cause the same variable to appear in a moment when the value in the memory of one thread may be inconsistent with the value in the memory of another thread, or the value in main memory.

violateIt is not a lock, it is just that the variable is not allowed to use Backup (cache), only read and write from memory, but this is not said to be thread-safe.

Cause: Volatile generally cannot replace sychronized, because volatile does not guarantee the atomicity of the operation, even if only i++, is actually composed of multiple atomic operations: Read I; Inc; Write I, if multiple threads execute i++,volatile at the same time can only guarantee that I is the same piece of memory, but it is still possible to write dirty data. If you add atomic wrapper classes with Java 5, you do not need sychronized for operations such as their increase.

When the generalized reentrant lock is called recursively, the same thread can get the lock again.

Reentrantlock-When no thread holds the lock, the state is 0.    -When a thread acquires a lock, the value of state increases, how many developers can customize it, and the default is 1, indicating that the lock is being occupied by a thread.    -When a thread that already occupies the lock gets to the lock again, the state grows again, and this is re-enter the lock. -When the locked thread releases the lock, the state also subtracts the value that was passed in when it was originally occupied, which defaults to 1. Database Pessimistic lock  Update or manual get Lock (for UPDATE) index column is the column that the lock index filters to (no full table scan) Other column lock table (full table Scan) (multiple query conditions do not affect the above logic, so inventory deductions can limit id+ inventory >0 to update fetch rows)   optimistic Lock  

You need to implement it yourself, the common practice is to record an incremental version, which is validated at the time of submission

Redis implements distributed locks  

Using Setif to implement, in the example provided online, the lock does not guarantee fairness, and the custom sleep can easily lead to thread blocking, plus timeout and business breach (request failed)

No good strategy has been found at the moment. Zookeeper distributed lock  

Take advantage of the features of the temporary self-increment node, observe a node, and then change each time to see if it is the smallest, if it is the smallest, then execute, not the smallest, continue to wait.

This performance is being tested.

See the wrong, trouble points out thank you!

Multiple locks commonly used (may be modified at any time)