我們知道linux線程同步有Mutex,spin lock,條件變量,rw lock等多種同步機(jī)制，InnoDB并沒有直接使用系統(tǒng)的同步機(jī)制，而是自己定義了互斥結(jié)構(gòu)數(shù)據(jù)結(jié)構(gòu)kernel_mutex,將系統(tǒng)的spin lock,mutex,和條件變量融合一起

如圖,kernel_mutexmutex對象的中重要的結(jié)構(gòu)成員為os_event和lock_word。

• kernel_mutex主要涉及mutex_create,mutex_enter,mutex_exit函數(shù)，會分別使用glibc的malloc()和free()調(diào)用動態(tài)分配和釋放內(nèi)存

• 封裝mutex和條件變量，圖中綠色框區(qū)域
  MySQL線程之間發(fā)送異步信號來進(jìn)行同步主要通過os_event_struct結(jié)構(gòu)體中的os_mutex(封裝os的pthread_mutex_t)和cond_var(封裝os的pthread_cond_t)成員對象實現(xiàn)。當(dāng)InnoDB在獲取鎖的時候，首先先努力自旋一段時間，如果超過innodb_sync_spin_loops的閾值，就會通過函數(shù)os_event_wait_low()在os_event_struct->cond_var上等待。如圖，當(dāng)某個線程釋放了鎖的時候，通過os_cond_broadcast嘗試發(fā)送廣播喚醒所有等待os_event_struct->cond_var條件變量的線程.這些線程被喚醒后又繼續(xù)競爭爭搶os_event_struct->os_mutex

• spin lock，圖中黃色框區(qū)域
  通過lock_word做spin wait。線程想要爭搶鎖的時候先判斷這個值，如果lock_word為1就繼續(xù)自旋等待。如果發(fā)現(xiàn)其他線程釋放了鎖該值變?yōu)?的時候，就通過test_and_set改為1，"告訴"其他線程這把鎖被持有了

InnoDB這樣設(shè)計的目的都是延緩線程被掛起并進(jìn)入os wait的速度，因為每一次進(jìn)入os wait等待被喚醒或者喚醒都會進(jìn)行一次上下文切換.但是也只能是延緩，并不能阻止，如果持續(xù)惡化得不到環(huán)境，最后仍然會進(jìn)入os的等待隊列，將會產(chǎn)生大量的上下文切換。但是有兩個問題:

• kernel_mutex是個全局鎖，保護(hù)事務(wù)，buffer pool,鎖，等InnoDB存儲引擎實現(xiàn)的大部分對象.當(dāng)MySQL突然有大量訪問，并發(fā)一旦非常高的時候，mutex沖突非常劇烈，此時臨界區(qū)變得非常大，同時也會浪費cpu很多時間空轉(zhuǎn)。所以這也解釋了sys cpu大量消耗在自選空轉(zhuǎn)中

• 并且并發(fā)高的時候會頻繁調(diào)用malloc()申請內(nèi)存，而glibc本身的malloc()本書頻繁調(diào)用系統(tǒng)mutex_lock()和unlock()，在多線程高并發(fā)場景下并且資源不足的場景下，也會造成系統(tǒng)各種mutex競爭嚴(yán)重。大量線程被掛起等待os pthread_cond_broadcast廣播被喚醒，隨之而來的是大量的上下文切換

通過dstat看到此時cpu每秒有近20W次的上下文切換，綜上所述，sys cpu負(fù)載高主要以下:

• (1)cpu內(nèi)核態(tài)spin,大量線程cpu在內(nèi)核態(tài)自旋等待

• (2)系統(tǒng)上下文切換,又分為:

• spin仍然失敗的，最終進(jìn)入os wait，調(diào)用pthread_cond_wait等待條件滿足時被喚醒

• malloc()頻繁加減os mutex，且系統(tǒng)內(nèi)存緊張