如果熟悉C++多線程的童鞋可能有了解到實現(xiàn)的互斥鎖的機制還有這個寫法

lock_guard<mutex> guard(mt);

那么這句話是什么意思呢？為什么又要搞個這樣的寫法呢？

這個也是構(gòu)造互斥鎖的寫法，就是會在lock_guard構(gòu)造函數(shù)里加鎖，在析構(gòu)函數(shù)里解鎖，之所以搞了這個寫法，C++委員會的解釋是防止使用mutex加鎖解鎖的時候，忘記解鎖unlock了。

#include <iostream>
#include <thread>
#include <string>
#include <mutex>
using namespace std;

mutex mt;
void thread_task()
{
    for (int i = 0; i < 10; i++)
    {
        lock_guard<mutex> guard(mt);
        cout << "print thread: " << i << endl;
    }
}

int main()
{
    thread t(thread_task);
    for (int i = 0; i > -10; i--)
    {
        lock_guard<mutex> guard(mt);
        cout << "print main: " << i << endl;
    }
    t.join();
    return 0;
}

這里說析構(gòu)函數(shù)里解鎖，那么到底什么時候調(diào)用析構(gòu)函數(shù)呢？構(gòu)造函數(shù)加鎖我們好理解，寫下這個語句的時候調(diào)用lock_guard<mutex> guard(mt)，那么調(diào)用析構(gòu)函數(shù)應(yīng)該是大括號{}結(jié)束的時候，也就是說定義lock_guard的時候調(diào)用構(gòu)造函數(shù)加鎖，大括號解鎖的時候調(diào)用析構(gòu)函數(shù)解鎖。

雖然lock_guard挺好用的，但是有個很大的缺陷，在定義lock_guard的地方會調(diào)用構(gòu)造函數(shù)加鎖，在離開定義域的話lock_guard就會被銷毀，調(diào)用析構(gòu)函數(shù)解鎖。這就產(chǎn)生了一個問題，如果這個定義域范圍很大的話，那么鎖的粒度就很大，很大程序上會影響效率。

所以為了解決lock_guard鎖的粒度過大的原因，unique_lock就出現(xiàn)了。

unique_lock<mutex> unique(mt);

這個會在構(gòu)造函數(shù)加鎖，然后可以利用unique.unlock()來解鎖，所以當(dāng)你覺得鎖的粒度太多的時候，可以利用這個來解鎖，而析構(gòu)的時候會判斷當(dāng)前鎖的狀態(tài)來決定是否解鎖，如果當(dāng)前狀態(tài)已經(jīng)是解鎖狀態(tài)了，那么就不會再次解鎖，而如果當(dāng)前狀態(tài)是加鎖狀態(tài)，就會自動調(diào)用unique.unlock()來解鎖。而lock_guard在析構(gòu)的時候一定會解鎖，也沒有中途解鎖的功能。

當(dāng)然，方便肯定是有代價的，unique_lock內(nèi)部會維護一個鎖的狀態(tài)，所以在效率上肯定會比lock_guard慢。

所以，以上兩種加鎖解鎖的方法，加上前面文章介紹的mutex方法，具體該使用哪一個，要依照具體的業(yè)務(wù)需求來決定，當(dāng)然mt.lock()和mt.unlock()不管是哪種情況，是肯定都可以使用的。

對我而言，總感覺這個lock_guard有點雞肋而已，完全可以用mutex來替代，忘記解鎖的話一般都可以通過調(diào)試發(fā)現(xiàn)，而且一般情況下都不會忘記。僅僅只是因為怕忘記解鎖這個原因的話，真的感覺有點多此一舉，徒增學(xué)習(xí)成本罷了。

當(dāng)然也許C++委員會有他們自己的考慮，對于我們而言，也只能記住就是了。