1. 线程安全和重⼊问题
概念
线程安全：就是多个线程在访问共享资源时，能够正确地执⾏，不会相互⼲扰或破坏彼此的执⾏结果。⼀般⽽⾔，多个线程并发同⼀段只有局部变量的代码时，不会出现不同的结果。但是对全局变量或者静态变量进⾏操作，并且没有锁保护的情况下，容易出现该问题。
重⼊：同⼀个函数被不同的执⾏流调⽤，当前⼀个流程还没有执⾏完，就有其他的执⾏流再次进⼊，我们称之为重⼊。⼀个函数在重⼊的情况下，运⾏结果不会出现任何不同或者任何问题，则该函数被称为可重⼊函数，否则，是不可重⼊函数。
学到现在，其实我们已经能理解重⼊其实可以分为两种情况
• 多线程重⼊函数
• 信号导致⼀个执⾏流重复进⼊函数
常⻅的线程不安全的情况
• 不保护共享变量的函数
• 函数状态随着被调⽤，状态发⽣变化的函数
• 返回指向静态变量指针的函数
• 调⽤线程不安全函数的函数
常⻅不可重⼊的情况
• 调⽤了malloc/free函数，因为malloc函数是⽤全局链表来管理堆的
• 调⽤了标准I/O库函数，标准I/O库的很多实现都以不可重⼊的⽅式使⽤全局数据结构
• 可重⼊函数体内使⽤了静态的数据结构
常⻅的线程安全的情况
• 每个线程对全局变量或者静态变量只有读取的权限，⽽没有写⼊的权限，⼀般来说这些线程是安全的
• 类或者接⼝对于线程来说都是原⼦操作
• 多个线程之间的切换不会导致该接⼝的执⾏结果存在⼆义性
常⻅可重⼊的情况
• 不使⽤全局变量或静态变量
• 不使⽤ malloc或者new开辟出的空间
• 不调⽤不可重⼊函数
• 不返回静态或全局数据，所有数据都有函数的调⽤者提供
• 使⽤本地数据，或者通过制作全局数据的本地拷⻉来保护全局数据
结论
不要被上⾯绕⼝令式的话语唬住，你只要仔细观察，其实对应概念说的都是⼀回事。
📌 可重⼊与线程安全联系
• 函数是可重⼊的，那就是线程安全的(其实知道这⼀句话就够了)
• 函数是不可重⼊的，那就不能由多个线程使⽤，有可能引发线程安全问题
• 如果⼀个函数中有全局变量，那么这个函数既不是线程安全也不是可重⼊的。
📌 可重⼊与线程安全区别
可重⼊函数是线程安全函数的⼀种
线程安全不⼀定是可重⼊的，⽽可重⼊函数则⼀定是线程安全的。
如果将对临界资源的访问加上锁，则这个函数是线程安全的，但如果这个重⼊函数若锁还
未释放则会产⽣死锁，因此是不可重⼊的。
📌 注意：
• 如果不考虑 信号导致⼀个执⾏流重复进⼊函数 这种重⼊情况，线程安全和重⼊在安全⻆度不做区分
• 但是线程安全侧重说明线程访问公共资源的安全情况，表现的是并发线程的特点
• 可重⼊描述的是⼀个函数是否能被重复进⼊，表⽰的是函数的特点
2. 常⻅锁概念
2.1 死锁
• 死锁是指在⼀组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所占⽤不会释放的资源⽽处于的⼀种永久等待状态。
• 为了⽅便表述，假设现在线程A，线程B必须同时持有锁1和锁2，才能进⾏后续资源的访问
申请⼀把锁是原⼦的，但是申请两把锁就不⼀定了
造成的结果是
2.2 死锁四个必要条件
• 互斥条件：⼀个资源每次只能被⼀个执⾏流使⽤
◦ 好理解，不做解释
• 请求与保持条件：⼀个执⾏流因请求资源⽽阻塞时，对已获得的资源保持不放
• 不剥夺条件:⼀个执⾏流已获得的资源，在末使⽤完之前，不能强⾏剥夺
• 循环等待条件:若⼲执⾏流之间形成⼀种头尾相接的循环等待资源的关系
2.3 避免死锁
• 破坏死锁的四个必要条件
◦ 破坏循环等待条件问题：资源⼀次性分配， 使⽤超时机制、加锁顺序⼀致
// 下⾯的C++不写了，理解就可以
#include <iostream>
#include <mutex>
#include <thread>
#include <vector>
#include <unistd.h>
// 定义两个共享资源（整数变量）和两个互斥锁
int shared_resource1 = 0;
int shared_resource2 = 0;
std::mutex mtx1, mtx2;
// ⼀个函数，同时访问两个共享资源
void access_shared_resources()
{
// std::unique_lock<std::mutex> lock1(mtx1, std::defer_lock);
// std::unique_lock<std::mutex> lock2(mtx2, std::defer_lock);
// // 使⽤ std::lock 同时锁定两个互斥锁
// std::lock(lock1, lock2);
// 现在两个互斥锁都已锁定，可以安全地访问共享资源
int cnt = 10000;
while (cnt)
{
++shared_resource1;
++shared_resource2;
cnt–;
}
// 当离开 access_shared_resources 的作⽤域时，lock1 和 lock2 的析构函数会
被⾃动调⽤
// 这会导致它们各⾃的互斥量被⾃动解锁
}
// 模拟多线程同时访问共享资源的场景
void simulate_concurrent_access()
{
std::vector<std::thread> threads;
// 创建多个线程来模拟并发访问
for (int i = 0; i < 10; ++i)
{
threads.emplace_back(access_shared_resources);
}
// 等待所有线程完成
for (auto &thread : threads)
{
thread.join();
}
// 输出共享资源的最终状态
std::cout << "Shared Resource 1: " << shared_resource1 << std::endl;
std::cout << "Shared Resource 2: " << shared_resource2 << std::endl;
}
int main()
{
simulate_concurrent_access();
return 0;
}
$ ./a.out // 不⼀次申请
Shared Resource 1: 94416
Shared Resource 2: 94536
$ ./a.out // ⼀次申请
Shared Resource 1: 100000
Shared Resource 2: 100000
• 避免锁未释放的场景
2.4 避免死锁算法(不讲)
• 死锁检测算法(了解)
• 银⾏家算法（了解）
3. STL,智能指针和线程安全6-1 STL中的容器是否是线程安全的?
不是.
原因是, STL 的设计初衷是将性能挖掘到极致, ⽽⼀旦涉及到加锁保证线程安全, 会对性能造成巨⼤的影响.
⽽且对于不同的容器, 加锁⽅式的不同, 性能可能也不同(例如hash表的锁表和锁桶).
因此 STL 默认不是线程安全. 如果需要在多线程环境下使⽤, 往往需要调⽤者⾃⾏保证线程安全.
3.1 智能指针是否是线程安全的?
对于 unique_ptr, 由于只是在当前代码块范围内⽣效, 因此不涉及线程安全问题.
对于 shared_ptr, 多个对象需要共⽤⼀个引⽤计数变量, 所以会存在线程安全问题. 但是标准库实现的时
候考虑到了这个问题, 基于原⼦操作(CAS)的⽅式保证 shared_ptr 能够⾼效, 原⼦的操作引⽤计数.
4. 其他常⻅的各种锁(不做介绍，具体看加餐课)
• 悲观锁：在每次取数据时，总是担⼼数据会被其他线程修改，所以会在取数据前先加锁（读锁，写锁，⾏锁等），当其他线程想要访问数据时，被阻塞挂起。
• 乐观锁：每次取数据时候，总是乐观的认为数据不会被其他线程修改，因此不上锁。但是在更新数据前，会判断其他数据在更新前有没有对数据进⾏修改。主要采⽤两种⽅式：版本号机制和CAS操作。
• CAS操作：当需要更新数据时，判断当前内存值和之前取得的值是否相等。如果相等则⽤新值更新。若不等则失败，失败则重试，⼀般是⼀个⾃旋的过程，即不断重试。
• ⾃旋锁，读写锁，加餐课详细介绍
