The underlying optimization of synchronized after JDK1.6

Mainly refer to "In-depth understanding of the Java Virtual Machine" and JavaGuide's underlying optimization after JDK1.6.md

No lock -> Deflection lock -> Lightweight lock -> (Spin lock) -> Heavyweight lock

Locking of biased locks

When a thread accesses the synchronized block and acquires the lock, the thread ID is stored in the Mark Word in the object header of the lock object (operated by CAS). After success, every time the thread holding the biased lock enters the synchronization block related to the lock, the virtual machine can no longer perform any synchronization operations (such as locking, unlocking, and updating the Mark Word, etc.), that is, no longer CAS.

Lightweight lock

When using lightweight locks, there is no need to apply for a mutex. CAS operations are used to lock and unlock lightweight locks.

Guess you like

Origin blog.csdn.net/qq_23204557/article/details/114817804