【Linux系统】线程安全

熙曦Sakura

于 2025-05-06 15:55:12 发布

阅读量893

点赞数 17

分类专栏： Linux系统文章标签：安全数据结构 c++ linux

本文链接：https://blog.csdn.net/Sakura_ding/article/details/147739972

版权

Linux系统专栏收录该内容

25 篇文章

订阅专栏

线程安全和重入问题

概念

线程安全：多个线程在访问共享资源时，能够正确地执行，不会相互干扰或破坏彼此的执行结果。一般而言，多个线程并发同一段只有局部变量的代码时，不会出现不同的结果。但是对全局变量或者静态变量进行操作，并且没有锁保护的情况下，容易出现该问题。
重入：同一个函数被不同的执行流调用，当前一个流程还没有执行完，就有其他的执行流再次进入，我们称之为重入。一个函数在重入的情况下，运行结果不会出现任何不同或者任何问题，则该函数被称为**可重入函数，**否则，是不可重入函数。

重入其实可以分为两种情况：

多线程重入函数
信号导致一个执行流重复进入函数

常见的线程不安全的情况

不保护共享变量的函数
函数状态随着被调用，状态发生变化的函数
返回指向静态变量指针的函数
调用线程不安全函数的函数

常见不可重入的情况

调用了malloc/free函数，因为malloc函数是用全局链表来管理堆的
调用了标准I/O库函数，标准I/O库的很多实现都以不可重入的方式使用全局数据结构
可重入函数体内使用了静态的数据结构

常见的线程安全的情况

每个线程对全局变量或者静态变量只有读取的权限，而没有写入的权限，一般来说这些线程是安全的
类或者接口对于线程来说都是原子操作
多个线程之间的切换不会导致该接口的执行结果存在二义性

常见可重入的情况

不使用全局变量或静态变量
不使用用malloc或者new开辟出的空间
不调用不可重入函数
不返回静态或全局数据，所有数据都有函数的调用者提供
使用本地数据，或者通过制作全局数据的本地拷贝来保护全局数据

结论
不要被上面绕口令式的话语唬住，你只要仔细观察，其实对应概念说的都是一回事。

可重入与线程安全联系

函数是可重入的，那就是线程安全的(其实知道这一句话就够了)
函数是不可重入的，那就不能由多个线程使用，有可能引发线程安全问题
如果一个函数中有全局变量，那么这个函数既不是线程安全也不是可重入的。

可重入与线程安全区别

可重入函数是线程安全函数的一种
线程安全不一定是可重入的，而可重入函数则一定是线程安全的。
如果将对临界资源的访问加上锁，则这个函数是线程安全的，但如果这个重入函数若锁还未释放则会产生死锁，因此是不可重入的。

注意:

如果不考虑信号导致一个执行流重复进入函数这种重入情况，线程安全和重入在安全角度不做区分
但是线程安全侧重说明线程访问公共资源的安全情况，表现的是并发线程的特点
可重入描述的是一个函数是否能被重复进入，表示的是函数的特点

常见锁概念

死锁

死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所占用不会释放的资源而处于的一种永久等待状态。
为了方便表述，假设现在线程A，线程B必须同时持有锁1和锁2，才能进行后续资源的访问

在这里插入图片描述
申请一把锁是原子的，但是申请两把锁就不一定了

造成的结果是

死锁四个必要条件

互斥条件：一个资源每次只能被一个执行流使用
好理解，不做解释
请求与保持条件：一个执行流因请求资源而阻塞时，对已获得的资源保持不放
不剥夺条件:一个行流已获得的资源，在末使用完之前，不能强行剥夺
循环等待条件:若干执行流之间形成一种头尾相接的循环等待资源的关系

避免死锁

破坏死锁的四个必要条件
- 破坏循环等待条件问题：资源一次性分配，使用超时机制、加锁顺序一致

// 下面的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

避免锁未释放的场景

STL,智能指针和线程安全

STL中的容器是否是线程安全的?

不是。
原因是，STL 的设计初衷是将性能挖掘到极致，而一旦涉及到加锁保证线程安全，会对性能造成巨大的影响。
而且对于不同的容器，加锁方式的不同，性能可能也不同(例如hash表的锁表和锁桶)。
因此 STL 默认不是线程安全。如果需要在多线程环境下使用，往往需要调用者自行保证线程安全。

智能指针是否是线程安全的?

对于 unique_ptr，由于只是在当前代码块范围内生效，因此不涉及线程安全问题。
对于 shared_ptr，多个对象需要共用一个引用计数变量，所以会存在线程安全问题。但是标准库实现的时候考虑到了这个问题，基于原子操作(CAS)的方式保证 shared_ptr 能够高效，原子的操作引用计数。