C C++最全【C++11】thread线程库，C C++开发学习视频

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

// vs下查看
typedef struct
{ 
  /\* thread identifier for Win32 \*/
    void \*_Hnd; 
  /\* Win32 HANDLE \*/
    unsigned int _Id;
} _Thrd_imp_t;

创建了一个线程对象但尚未开始执行该线程。在这种情况下，线程对象关联的线程 ID 可能是一个无效值，需要线程开始后再获取其id

3. 当创建一个线程对象后，并且给线程关联线程函数，该线程就被启动，与主线程一起运行。线程函数一 般情况下可按照以下几种可执行对象提供:

• 函数指针
• 仿函数
• lambda表达式
• 包装器

C++的做法：

函数指针

• 演示：

std::this_thread 命名空间中的函数是静态成员函数

• **yield函数：**使线程主动让出执行权，以便让其他线程继续执行而不被阻塞

4. thread类是防拷贝的，不允许拷贝构造以及赋值，但是可以移动构造和移动赋值，即将一个线程对象关联线程的状态转移给其他线程对象，转移期间不意向线程的执行。

• 举例：

• 但是下面的这种写法是错误的：

我们正确做法是将t2改为右值：

5. 可以通过joinable()函数判断线程是否是有效的，如果是以下任意情况，则线程无效

• 采用无参构造函数构造的线程对象
• 线程对象的状态已经转移给其他线程对象
• 线程已经调用join或者detach结束
• 所以，不能在已经移动的线程对象上调用 join()，这会导致 std::system_error 异常，因为 t1 不再表示一个有效的线程。：

防止出现这种错误，还可以使用**joinable()**函数来规避

lambda表达式常用在线程中

• 总结：

#include <iostream>
using namespace std;
#include <thread>
void ThreadFunc(int a)
{
    cout << "Thread1" << a << endl;
}
class TF
{
public:
    void operator()()
    {
        cout << "Thread3" << endl;
    }
};
int main() {
    // 线程函数为函数指针
    thread t1(ThreadFunc, 10);
    // 线程函数为lambda表达式
    thread t2([]{cout << "Thread2" << endl; });
    // 线程函数为函数对象 
  	TF tf;
    thread t3(tf);
    t1.join();
    t2.join();
    t3.join();
    cout << "Main thread!" << endl;
    return 0;
}

线程函数参数

线程函数的参数是以值拷贝的方式拷贝到线程栈空间中的，因此:即使线程参数为引用类型，在线程中修改 后也不能修改外部实参，因为其实际引用的是线程栈中的拷贝，而不是外部实参。

#include <thread>
void ThreadFunc1(int& x)
{
		x += 10; 
}
void ThreadFunc2(int\* x)
{
		\*x += 10; 
}
int main() {
		int a = 10;
		// 在线程函数中对a修改，不会影响外部实参，因为:线程函数参数虽然是引用方式，但其实际引用的 是线程栈中的拷贝
    thread t1(ThreadFunc1, a);
    t1.join();
    cout << a << endl;
    // 如果想要通过形参改变外部实参时，必须借助std::ref()函数 thread t2(ThreadFunc1, std::ref(a);
    t2.join();
    cout << a << endl;
    // 地址的拷贝
    thread t3(ThreadFunc2, &a); t3.join();
    cout << a << endl;
		return 0;
}

• 注意：如果是类成员函数作为线程参数时，必须将this作为线程函数参数。

join与detach

启动了一个线程后，当这个线程结束的时候，如何去回收线程所使用的资源呢?thread库给我们两种选择:

• join()方式

join():主线程被阻塞，当新线程终止时，join()会清理相关的线程资源，然后返回，主线程再继续向下执行，然后销毁线程对象。由于join()清理了线程的相关资源，thread对象与已销毁的线程就没有关系了，因此一个线程对象只能使用一次join()，否则程序会崩溃。

// join()的误用一
void ThreadFunc() { cout<<"ThreadFunc()"<<endl; } 
bool DoSomething() { return false; }
int main()
{
    std::thread t(ThreadFunc);
    if(!DoSomething())
    return -1;
    t.join();
    return 0; 
}
/\* 说明:如果DoSomething()函数返回false,主线程将会结束，join()没有调用，线程资源没有回收， 造成资源泄漏。
\*/
// join()的误用二
void ThreadFunc() { cout<<"ThreadFunc()"<<endl; } 
void Test1() { throw 1; }
void Test2()
{
    int\* p = new int[10];
    std::thread t(ThreadFunc);
    try
    {
    		Test1(); 
    }
    catch(...) {
        delete[] p;
        throw; 
    }
    t.join(); 
}

// 说明:与上述原因相似

利用RAII思想来自动回收线程

因此:采用join()方式结束线程时，join()的调用位置非常关键。为了避免该问题，可以采用RAII的方式 对线程对象进行封装，比如:

#include <thread>
class mythread
{
public:
    explicit mythread(std::thread &t) :m\_t(t){}
    ~mythread()
    {
        if (m_t.joinable())
            m_t.join();
    }
    mythread(mythread const&)=delete;
    mythread& operator=(const mythread &)=delete;
private:
    std::thread &m_t;
};
void ThreadFunc() { cout << "ThreadFunc()" << endl; }
bool DoSomething() { return false; }
int main() {
    thread t(ThreadFunc);
    mythread q(t);
    if (DoSomething())
        return -1;
		return 0; 
}

• detach()方式

detach():该函数被调用后，新线程与线程对象分离，不再被线程对象所表达，就不能通过线程对象控 制线程了，新线程会在后台运行，其所有权和控制权将会交给c++运行库。同时，C++运行库保证，当线程退出时，其相关资源的能够正确的回收。

就像是你和你女朋友分手，那之后你们就不会再有联系(交互)了，而她的之后消费的各种资源也就不需要你去埋单了(清理资源)。

**detach()**函数一般在线程对象创建好之后就调用，因为如果不是join()等待方式结束，那么线程对象可能会在新线程结束之前被销毁掉而导致程序崩溃。因为std::thread的析构函数中，如果线程的状态是joinable，std::terminate将会被调用，而terminate()函数直接会终止程序。

因此，线程对象销毁前，要么以join()的方式等待线程结束，要么以detach()的方式将线程与线程对象分离。

原子性操作库(atomic)

多线程最主要的问题是共享数据带来的问题（即线程安全）。如果共享数据都是只读的，那么没问题，因为只读操作不会影响到数据，更不会涉及对数据的修改，所以所有线程都会获得同样的数据。但是，当一个或多个线程要修改共享数据时，就会产生很多潜在的麻烦。

• 例：

C++98中传统的解决方式：可以对共享修改的数据可以加锁保护。

#include <iostream>
using namespace std;
#include <thread>
#include <mutex>
std::mutex m;
unsigned long sum = 0L;
void fun(size_t num)
{
    for (size_t i = 0; i < num; ++i)
    {
        m.lock();
        sum++;
        m.unlock();
		} 
}
int main() {
    cout << "Before joining,sum = " << sum << std::endl;
    thread t1(fun, 10000000);
    thread t2(fun, 10000000);
    t1.join();
    t2.join();
    cout << "After joining,sum = " << sum << std::endl;
		return 0; 
}

虽然加锁可以解决，但是加锁有一个缺陷就是:只要一个线程在对sum++时，其他线程就会被阻塞，会影响程序运行的效率，而且锁如果控制不好，还容易造成死锁。

同时，频繁地对较少的临界资源加锁会影响效率，不适合用互斥锁，会导致线程频繁阻塞，适合用自旋锁（但是库里面没有提供，也可以不断try_lock()）。

• 但是这个场景也不太适合用自旋锁，对CPU消耗也很大。

改进：

C++11中还引入了原子操作。所谓原子操作:即不可被中断的一个或一系列操作，C++11引入的原子操作类型，使得线程间数据的同步变得非常高效。

注意:需要使用以上原子操作变量时，必须添加头文件（#include < atomic>）

在C++11中，程序员不需要对原子类型变量进行加锁解锁操作，线程能够对原子类型变量互斥的访问。 更为普遍的，程序员可以使用atomic类模板，定义出需要的任意原子类型。

atmoic<T> t; // 声明一个类型为T的原子类型变量t

注意:原子类型通常属于"资源型"数据，多个线程只能访问单个原子类型的拷贝，因此在C++11中，原子类型只能从其模板参数中进行构造，不允许原子类型进行拷贝构造、移动构造以及operator=等，为了防止意外，标准库已经将atmoic模板类中的拷贝构造、移动构造、赋值运算符重载默认删除掉了。

#include <atomic>
int main() {
    atomic<int> a1(0);
    //atomic<int> a2(a1);
    atomic<int> a2(0);
    //a2 = a1;
		return 0; 
}

• atomic内部类似自旋（自旋锁用了atomic），自旋锁和atomic都适用于临界区很短的场景

atomic中的load函数：

• C++官网示例：

// atomic::load/store example
#include <iostream> // std::cout
#include <atomic> // std::atomic, std::memory\_order\_relaxed
#include <thread> // std::thread

std::atomic<int> foo (0);

void set\_foo(int x) {
  foo.store(x,std::memory_order_relaxed);     // set value atomically
}

void print\_foo() {
  int x;
  do {
    x = foo.load(std::memory_order_relaxed);  // get value atomically
  } while (x==0);
  std::cout << "foo: " << x << '\n';
}

int main ()
{
  std::thread first (print_foo);
  std::thread second (set_foo,10);
  first.join();
  second.join();
  return 0;
}

• 如果x是atomic类型的直接转换类型是不安全的

• 正确写法：

atomic中对变量进行原子操作的一些函数

CAS(Compare-And-Swap)无锁编程

atomic在内核其实是CAS无锁编程

++x分为3步

CAS减少了线程切换上下文的次数，提高了效率（相比old值，相同则执行，不相同则再走一轮循环）

• CAS原理（重要）

• C++官网有关的函数（了解即可）：

CAS实现无锁队列

在C++11中,new操作保证了内存分配(如果需要)和对象构造完成后, 才会将地址赋给instance,这保证了线程安全。

• 当两个线程都往同一个链表进行尾插时就会触发线程安全的问题（处理不好内存泄漏 ！）

有关无锁编程的博客陈皓前辈的文章写的非常好！

尝试使用CAS编程实现++x

• 注意C++11中要求atomic_compare_exchange_weak函数第一个参数是atomic模版类型

Mutex的种类

在多线程环境下，如果想要保证某个变量的安全性，只要将其设置成对应的原子类型即可，即高效又不容易出现死锁问题。但是有些情况下，我们可能需要保证一段代码的安全性，那么就只能通过锁的方式来进行控制。

mutex

• mutex类:
  

在C++11中，Mutex总共包了四个互斥量的种类:

1. std::mutex C++11提供的最基本的互斥量，该类的对象之间不能拷贝，也不能进行移动。mutex最常用的三个函数:

函数名	函数功能
lock()	上锁：锁住互斥量
unlock()	解锁：释放对互斥量的所有权
try_lock()	尝试锁住互斥量，如果互斥量被其他线程占有，则当前线程也不会被阻塞

注意，线程函数调用lock()时，可能会发生以下三种情况:

• 如果该互斥量当前没有被锁住，则调用线程将该互斥量锁住，直到调用 unlock之前，该线程一直 拥有该锁
• 如果当前互斥量被其他线程锁住，则当前的调用线程被阻塞住
• 如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)

线程函数调用try_lock()时，可能会发生以下三种情况:

• 如果当前互斥量没有被其他线程占有，则该线程锁住互斥量，直到该线程调用 unlock 释放互斥量
• 如果当前互斥量被其他线程锁住，则当前调用线程返回 false，而并不会被阻塞掉
• 如果当前互斥量被当前调用线程锁住，则会产生死锁(deadlock)

2. std::recursive_mutex

其允许同一个线程对互斥量多次上锁(即递归上锁)，来获得对互斥量对象的多层所有权，释放互斥量 时需要调用与该锁层次深度相同次数的 unlock()，除此之外，std::recursive_mutex 的特性和 std::mutex 大致相同。

3. std::timed_mutex

比std::mutex多了两个成员函数，try_lock_for(),try_lock_until()。

• try_lock_for()

接受一个时间范围，表示在这一段时间范围之内线程如果没有获得锁则被阻塞住(与 std::mutex 的 try_lock() 不同，try_lock 如果被调用时没有获得锁则直接返回 false)，如果在此期间其他线程 释放了锁，则该线程可以获得对互斥量的锁，如果超时(即在指定时间内还是没有获得锁)，则返 回 false。

• try_lock_until()

接受一个时间点作为参数，在指定时间点未到来之前线程如果没有获得锁则被阻塞住，如果在此期 间其他线程释放了锁，则该线程可以获得对互斥量的锁，如果超时(即在指定时间内还是没有获得 锁)，则返回 false。

4. std::recursive_timed_mutex

• 实验：

注意，锁是不支持传值的！！！

• lambda表达式可以直接捕获这个锁(规避完美转发问题)：

• 千万要注意以下这个坑：

【问题】：明明函数中锁的参数是一个引用且传递方式是正确的，但是还是发生了报错？

【解决且原因】：

原因：在C++中，std::ref() 是一个函数模板，它用于创建对给定对象的引用的引用包装器。std::ref() 函数通常与标准库中的多线程相关类一起使用，比如 std::thread。

在多线程编程中，当我们想要将一个对象传递给线程函数，并且希望该线程函数可以修改这个对象时，我们通常需要将对象作为引用传递给线程函数。然而，std::thread 的构造函数是通过值传递参数的，这意味着如果我们直接传递一个对象给 std::thread，它将会被复制到新线程的栈上，而不是原始对象本身。为了避免这种复制，可以使用 std::ref()。

【问题】：为什么std::thread 的构造函数是通过值传递参数的?

因为是将mtx传递给thread的构造函数，再将mtx传递给线程处理函数，如果是以mtx传递，thread实例化的时候会自动识别该类型，变为传值拷贝（因为传的就是mtx，属性被破坏了），要想保持mtx的引用属性则需要借助ref()函数，走一层完美转发（C++11）来保持属性。

完美转发：

本质由于模版的可变参数和引用折叠导致的问题

trylock函数：

• 演示：

recursive_mutex（递归互斥锁

递归互斥锁（Recursive Mutex）是一种互斥锁的变体，允许同一线程在持有锁的情况下多次获取该锁而不会发生死锁。在典型的互斥锁中，同一线程尝试再次获取已经持有的锁时会导致死锁，因为锁已经被该线程所占用。但是，递归互斥锁允许同一线程多次获取锁，每次获取都必须有相应的释放操作，这样可以保证线程在递归调用中能够正常工作而不会因为获取同一锁而阻塞自己。

• 在递归函数里面使用mutex会导致死锁（尝试申请已持有的锁会死锁）

递归互斥锁原理：

递归互斥锁通常会维护一个计数器来记录某个线程已经获取锁的次数。当线程第一次获取锁时，计数器会增加；每次成功获取锁后，计数器会增加；每次释放锁时，计数器会减少。只有当计数器减为零时，锁才会完全释放。

timed_mutex

chrono命名空间

lock_guard(RAII思想)

• 运行一段这样的代码

上述代码的缺陷:锁控制不好时，可能会造成死锁，最常见的比如在锁中间代码返回，或者在锁的范围内抛 异常。（因为抛出异常后程序就不会执行到unlock()函数）

怎么解决？

因此:C++11采用RAII的方式对锁进行了封装，即lock_guard和unique_lock。

采用lock_guard模版类来管理锁

std::lock_gurad 是 C++11 中定义的模板类。定义如下:

template<class \_Mutex>
class lock\_guard
{
public:
// 在构造lock\_gard时，\_Mtx还没有被上锁 
 explicit lock\_guard(_Mutex& _Mtx)
       : \_MyMutex(_Mtx)
   {
       _MyMutex.lock();
   }
// 在构造lock\_gard时，\_Mtx已经被上锁，此处不需要再上锁 
 lock\_guard(_Mutex& _Mtx, adopt_lock_t)
       : \_MyMutex(_Mtx)
   {}
   ~lock\_guard() _NOEXCEPT
   {
       _MyMutex.unlock();
   }
   lock\_guard(const lock_guard&) = delete;
   lock_guard& operator=(const lock_guard&) = delete;
private:
   _Mutex& _MyMutex;
};

通过上述代码可以看到，lock_guard类模板主要是通过RAII的方式，对其管理的互斥量进行了封装，在需要 加锁的地方，只需要用上述介绍的任意互斥体实例化一个lock_guard，调用构造函数成功上锁，出作用域 前，lock_guard对象要被销毁，调用析构函数自动解锁，可以有效避免死锁问题。

lock_guard的缺陷:太单一，用户没有办法对该锁进行控制，因此C++11又提供了unique_lock。

• 写一个示例：

这样写是错的！！！正确写法：

这样就不会发生死锁了，锁会随着局部变量的生命周期而释放

• 完整的测试代码:

// Created Time: 2024-03-24 22:43:31
// Modified Time: 2024-03-26 13:01:33
#include <iostream>
#include <thread>
#include <vector>
#include <string>
#include <mutex>
using namespace std;

void func()
{
    if(rand()%5==0)
    {
        throw runtime\_error("异常");
    }
    else
    {
        cout<<"func"<< endl;
    }
}

template <class Lock>
class LockGuard
{
public:
    LockGuard(Lock& lk)
        :\_lk(lk)//锁不支持拷贝！！！
    {
        _lk.lock();
    }
    ~LockGuard()     
    {
        _lk.unlock();
    }
private:
    Lock& _lk;
};
int main(int argc, char \*argv[]) {
    mutex mtx;
    size_t n1=10000;
    size_t n2=10000;
    size_t x=0;
    srand(time(0));

    thread t1([n1,&x,&mtx](){
        try{  
            for(int i=0;i<n1;++i)
            {
                LockGuard<mutex> lg(mtx);
                //mtx.lock();
                ++x;
                cout<<"thread-------1"<<endl;
                func();
                //mtx.unlock();

            }
        }
        catch(const exception&e)
        {
            cout<<e.what()<<endl;
        }
    });
     thread t2([n2,&x,&mtx](){
        for(int i=0;i<n2;++i)
        {
            mtx.lock();
            ++x;
            cout<<"thread-------2"<<endl;
            mtx.unlock();
        }
    });
    t1.join();
    t2.join();
    cout<<x<<endl;
    return 0;
}

• 当然<mutex>库里面也提供了现成的lock_guard函数

unique_lock

一定要注意lock_guard和unique_lock的区别：

• unique_lock支持手动解锁，再加锁
• unique_lock可以和time_mutex配合使用
• unique_lock可以和<condition_variable>条件变量进行配合

<condition_variable>头文件的介绍

与lock_guard类似，unique_lock类模板也是采用RAII的方式对锁进行了封装，并且也是以独占所有权的方式管理mutex对象的上锁和解锁操作，即其对象之间不能发生拷贝。在构造(或移动(move)赋值)时，unique_lock对象需要传递一个 Mutex 对象作为它的参数，新创建的 unique_lock 对象负责传入的 Mutex 对象的上锁和解锁操作。使用以上类型互斥量实例化unique_lock的对象时，自动调用构造函数上锁，unique_lock对象销毁时自动调用析构函数解锁，可以很方便的防止死锁问题。与lock_guard不同的是，unique_lock更加的灵活，提供了更多的成员函数:

• 上锁/解锁操作: lock、try_lock、try_lock_for、try_lock_until和unlock
• 修改操作: 移动赋值、交换(swap:与另一个unique_lock对象互换所管理的互斥量所有权)、释放 (release:返回它所管理的互斥量对象的指针，并释放所有权)
• 获取属性: owns_lock(返回当前对象是否上了锁)、operator bool()(与owns_lock()的功能相同)、 mutex(返回当前unique_lock所管理的互斥量的指针)

成员函数wait

我们发现wait函数用的是unique_lock，因为unique_lock函数能调用unlock()而lock_guard里面没有lock()成员函数。

同时注意，调用wait函数阻塞线程前会将锁unlock()，不然会死锁：

wait对应的成员函数notify_one

• 还有一个相似的成员函数notify_all，这个函数不要随便用，使用不当可能会发生惊群现象(本质就是导致了无谓的资源竞争)

C++中的"惊群现象"通常指的是在多线程编程中的一种性能问题，特别是在使用互斥锁时出现的情况。当多个线程被阻塞等待同一个资源时，一旦该资源可用，所有线程都会被唤醒，即使只有一个线程真正需要该资源。这种情况下，会导致不必要的竞争和上下文切换，降低了程序的性能。

举个例子，假设有多个线程等待某个共享资源的释放，一旦资源可用，所有这些线程都会被唤醒。然后它们开始竞争获取资源的访问权限，但实际上只有一个线程可以获得资源并继续执行，其他线程会再次被阻塞。这种情况下，除了获得资源的线程之外，其他线程被唤醒是没有必要的，这就是"惊群现象"。

想要减少惊群现象的发生，可以采用更加精细的同步机制，例如使用条件变量（condition variables）来唤醒等待的线程，只有当条件满足时才唤醒需要的线程。另外，也可以考虑使用更轻量级的同步原语，如自旋锁（spinlock），以减少上下文切换的开销。

例题：控制两个线程交替打印奇数和偶数

• 错误示例（一个线程加锁并等待，另一个线程用于唤醒）:
• 因为是多线程，t2调用notify_one唤醒的时候可能t1还没有wait等待

【优解】：

注释中有些注意的地方：

#include <iostream>
#include <thread>
#include <mutex>
#include <condition\_variable>
using namespace std;
int main()
{
    mutex mtx;
    int x=1;
    condition_variable cv;
    bool flag=false;
    //如何保证t2线程先运行?
    thread t1([&](){
        for(size_t i=0;i<10;++i)
        {
            unique_lock<mutex> lock(mtx);
            while(flag)//这里if和while都可以，用while是为了防止notify\_one()失败，但是理论上不会失败。
            {
                cv.wait(lock);
            }
            cout<<this_thread::get\_id()<<":"<<x<<endl;
            ++x;
            flag = true;
            cv.notify\_one();
        }
    });
    thread t2([&](){
        for(size_t i=0;i<10;++i)
        {
            unique_lock<mutex> lock(mtx);
            while(!flag)
            {
                cv.wait(lock);
            }
            cout<<this_thread::get\_id()<<":"<<x<<endl;
            ++x;
            flag = false;
            cv.notify\_one();
        }
    });
    
    t1.join();
    t2.join();
    return 0;
}

【讨论】：

• 场景1:

假设t1先运行，t1先抢到lock，flag是false，t1先打印，flag改成true

t2两种情况：

a、没启动起来，或者没有分到时间片->t2总会开始运行，lock,flag是true，他不会wait t2打印值，flag改成false，notify唤醒t1.后续就是类似交替运行

b、运行起来，lock阻塞

notify没有线程等待，出作用域解锁

a、如果t2是在a状况，t1又抢到锁，但是flag为true，wait阻塞（unlock）

b、如果t2是在b状况，t1解锁，唤醒t2，t2获取到锁，flag是true，t2不会阻塞打印

• 场景2：

t2先启动，t2会lock，wait（unlock）

t1两种状况：

a、没启动，或者没分到时间片。->t1总会分到时间片运行，lock，打印，flag改成true，notify t2

b、t1慢一步，但是也分到时间片开始执行了，t1 lock阻塞，t2wait时，unlock会唤醒t1获取锁，保证了t1先运行

有关share_ptr智能指针中线程安全的问题

• share_ptr源码

template <class T>
class shared\_ptr
{
public:
    // RAII
    // 像指针一样
    shared\_ptr(T \*ptr = nullptr)
        : \_ptr(ptr), \_pcount(new int(1))
    {
    }

    // function<void(T\*)> \_del;


![img](https://img-blog.csdnimg.cn/img_convert/d5451d416d3673a965f60abdeab2fcda.png)
![img](https://img-blog.csdnimg.cn/img_convert/85b1d34a3379008e5f172ee41e98f1ca.png)

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化的资料的朋友，可以添加戳这里获取](https://bbs.csdn.net/topics/618668825)**


**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

33a4eda.png)


【讨论】：


* 场景1:


假设t1先运行，t1先抢到lock，flag是false，t1先打印，flag改成true


t2两种情况：


a、没启动起来，或者没有分到时间片->t2总会开始运行，lock,flag是true，他不会wait t2打印值，flag改成false，notify唤醒t1.后续就是类似交替运行


b、运行起来，lock阻塞


notify没有线程等待，出作用域解锁


a、如果t2是在a状况，t1又抢到锁，但是flag为true，wait阻塞（unlock）


b、如果t2是在b状况，t1解锁，唤醒t2，t2获取到锁，flag是true，t2不会阻塞打印


* 场景2：


t2先启动，t2会lock，wait（unlock）


t1两种状况：


a、没启动，或者没分到时间片。->t1总会分到时间片运行，lock，打印，flag改成true，notify t2


b、t1慢一步，但是也分到时间片开始执行了，t1 lock阻塞，t2wait时，unlock会唤醒t1获取锁，保证了t1先运行


### 有关share\_ptr智能指针中线程安全的问题


* share\_ptr源码

template
class shared_ptr
{
public:
// RAII
// 像指针一样
shared_ptr(T *ptr = nullptr)
: _ptr(ptr), _pcount(new int(1))
{
}

// function<void(T\*)> \_del;

[外链图片转存中…(img-9jEeXmhQ-1715699398855)]
[外链图片转存中…(img-Grexk1R9-1715699398856)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！