Article Directory
Optimistic lock and pessimistic lock are not a real lock, but a design idea. Optimistic lock and pessimistic lock are essential for understanding back-end multi-threading and database, so this article will discuss this in detail The concept and implementation of the two locks.
I don't like to see what people say "optimistic locking and pessimistic locking in Java". I have to think about who owns which. . .
Optimistic lock
Optimistic lock, you know its name, think of things very purely, it always thinks that resources and data will not be modified by others, so reads will not be locked, but optimistic locks will judge when writing operations Whether the current data has been modified. Mechanisms such as version numbers can be used.
Optimistic locking is mostly suitable for multiple types of applications, which can improve throughput.
achieve
-
Use a self-increasing integer to represent the data version number.
If these double writes do not interfere with each other, the male fetches, the version number is 0, the male writes, the version number +1; the female fetches, the version number is 1, and the female writes, the version number is 2.
If these double writes interfere with each other, the male fetches, the version number is 0; the male has not yet written, the female fetches, the version number is 0; the male writes, the version number is 1; the female writes, the version number is found If the number does not match, the writing fails, and the amount and version number should be read again. -
Use timestamp to achieve.
Pessimistic lock
Pessimistic lock is a kind of pessimistic thought. It always believes that the worst case may occur. It believes that data is likely to be modified by others. Therefore, pessimistic lock will always lock resources or data when holding data. When other threads want to request this resource, they will block until the pessimistic lock releases the resource. Many such locking mechanisms are used in traditional relational databases, such as row locks, table locks, etc., read locks, write locks, etc., which are all locked before operations. The realization of pessimistic locking often relies on the lock function of the database itself.
achieve
You can use the lock mechanism of the database.
Optimistic lock vs. pessimistic lock
I can only say that each has its own merits.
Optimistic locking is suitable for the case of relatively few writes, that is, when conflicts really rarely occur, which can save the overhead of locking and increase the overall throughput of the system. But if conflicts often occur, this will actually reduce performance, so pessimistic locks are more appropriate in this case.
Pessimistic locking will cause longer access to the database and poor concurrency, especially for long transactions.
Optimistic locks are used more in reality.
Putting the above example here becomes: after one party gets the lock, the other party waits until one party releases the lock and the other party continues to operate.
Spin locks & mutex locks
Spin locks and mutex locks have been used all the time, but they were simply called locks before. It turns out that someone has a name.
wait() don't you know? don't you know timewait()?
Mutual exclusion lock: blocking and waiting
Spin lock: wait two times and ask: okay? I am in a hurry! Okay? You hurry up. . . Hahahahaha
The principle of spin lock is relatively simple. If the thread holding the lock can release the lock resource in a short time, then those threads waiting for the competing lock do not need to switch between the kernel state and the user state to enter the blocking state, they only need Wait for a while (spin), wait until the thread holding the lock releases the lock to obtain it, thus avoiding the consumption of user processes and kernel switching.
Because spin locks avoid operating system process scheduling and thread switching, spin locks are usually suitable for short periods of time. For this reason, the kernel of the operating system often uses spin locks. However, if the lock is locked for a long time, the spin lock will be very performance-consuming, and it prevents other threads from running and scheduling. The longer the thread holds the lock, the greater the risk that the thread holding the lock will be interrupted by the OS (Operating System) scheduler. If an interruption occurs, then other threads will remain spinning (repeatedly trying to acquire the lock), and the thread holding the lock does not intend to release the lock, which results in an indefinite delay until the thread holding the lock can complete And release it so far.
A good way to solve the above situation is to set a spin time for the spin lock and release the spin lock immediately when the time is up. Adaptive spin lock means that the spin time is not fixed, but is determined by the previous spin time on the same lock and the state of the lock. It is basically considered that the time for a thread context switch is the best one time.
Long tail flow optimization
Just swipe it and it's over. Are you sure not to collect it?
You look so good-looking, don’t you focus on it? Hehe
