线程锁-互斥、自旋、读写、原子操作、线程池

最新推荐文章于 2025-08-15 22:56:20 发布
原创 最新推荐文章于 2025-08-15 22:56:20 发布 · 1k 阅读 · 12 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java #开发语言

1.自旋锁

2.互斥锁

原子操作

线程池

多线程同步编程详解

多线程同步是并发编程中的核心概念，下面我将详细介绍互斥锁、自旋锁、读写锁、原子操作和线程池，并提供代码示例、使用条件和常见易错点。

1. 互斥锁 (Mutex)

基本概念

互斥锁是最常用的线程同步机制，用于保护共享资源，确保同一时间只有一个线程可以访问临界区。

代码示例 (C++11)

#include <iostream>
#include <thread>
#include <mutex>

std::mutex mtx;
int shared_data = 0;

void increment() {
    for (int i = 0; i < 100000; ++i) {
        mtx.lock();
        ++shared_data;
        mtx.unlock();
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);
    
    t1.join();
    t2.join();
    
    std::cout << "Final value: " << shared_data << std::endl;
    return 0;
}

使用条件

  • 当多个线程需要访问同一共享资源时
  • 临界区代码执行时间较长（如文件I/O、复杂计算）

注意事项

  1. ​避免死锁​：确保锁总是被释放，可以使用std::lock_guard或std::unique_lock自动管理
  2. ​锁粒度​：锁的范围不宜过大，否则会降低并发性能
  3. ​异常安全​：临界区内可能抛出异常，导致锁无法释放

易错点

  • 忘记解锁（推荐使用RAII风格的锁管理）
  • 锁的嵌套使用不当导致死锁
  • 在不同函数中加锁/解锁，导致逻辑混乱

2. 自旋锁 (Spinlock)

基本概念

自旋锁是一种忙等待锁，线程在获取锁失败时会循环检查锁状态，而不是被挂起。

代码示例 (C++11)

#include <atomic>
#include <thread>

class Spinlock {
    std::atomic_flag flag = ATOMIC_FLAG_INIT;
public:
    void lock() {
        while (flag.test_and_set(std::memory_order_acquire));
    }
    void unlock() {
        flag.clear(std::memory_order_release);
    }
};

Spinlock spin;
int shared_data = 0;

void increment() {
    for (int i = 0; i < 100000; ++i) {
        spin.lock();
        ++shared_data;
        spin.unlock();
    }
}

int main() {
    std::thread t1(increment);
    std::thread t2(increment);
    
    t1.join();
    t2.join();
    
    std::cout << "Final value: " << shared_data << std::endl;
    return 0;
}

使用条件

  • 临界区代码执行时间非常短
  • 不希望线程被挂起（避免上下文切换开销）
  • 多核处理器环境

注意事项

  1. ​CPU占用​：自旋锁会持续占用CPU
  2. ​单核慎用​：单核CPU上可能导致性能问题
  3. ​优先级反转​：高优先级线程可能被低优先级线程阻塞

易错点

  • 在长时间临界区使用自旋锁（应改用互斥锁）
  • 忘记释放自旋锁
  • 在单核系统上使用导致性能下降

3. 读写锁 (Read-Write Lock)

基本概念

读写锁允许多个读操作同时进行，但写操作需要独占访问，适用于读多写少的场景。

代码示例 (C++17)

#include <shared_mutex>
#include <thread>
#include <vector>

std::shared_mutex rw_mutex;
int shared_data = 0;

void reader(int id) {
    for (int i = 0; i < 5; ++i) {
        {
            std::shared_lock lock(rw_mutex);
            std::cout << "Reader " << id << " sees: " << shared_data << std::endl;
        }
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}

void writer(int id) {
    for (int i = 0; i < 2; ++i) {
        {
            std::unique_lock lock(rw_mutex);
            ++shared_data;
            std::cout << "Writer " << id << " updated to: " << shared_data << std::endl;
        }
        std::this_thread::sleep_for(std::chrono::milliseconds(200));
    }
}

int main() {
    std::vector<std::thread> readers;
    for (int i = 0; i < 5; ++i) {
        readers.emplace_back(reader, i);
    }
    
    std::vector<std::thread> writers;
    for (int i = 0; i < 2; ++i) {
        writers.emplace_back(writer, i);
    }
    
    for (auto& t : readers) t.join();
    for (auto& t : writers) t.join();
    
    return 0;
}

使用条件

  • 读操作远多于写操作
  • 读操作不需要修改共享数据
  • 读操作持续时间较长

注意事项

  1. ​写者饥饿​：持续有读者可能导致写者无法获取锁
  2. ​升级问题​：从读锁升级到写锁通常不支持
  3. ​公平性​：某些实现可能不公平，导致某些线程长期得不到机会

易错点

  • 在持有读锁时修改数据（未定义行为）
  • 错误估计读写比例（写多读少时性能可能不如互斥锁）
  • 忽略锁的升级限制

4. 原子操作 (Atomic Operations)

基本概念

原子操作是不可分割的操作，由CPU直接保证其原子性，无需额外锁机制。

代码示例 (C++11)

#include <atomic>
#include <thread>
#include <vector>

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

void increment(int n) {
    for (int i = 0; i < n; ++i) {
        counter.fetch_add(1, std::memory_order_relaxed);
    }
}

int main() {
    const int num_threads = 10;
    const int increments_per_thread = 100000;
    
    std::vector<std::thread> threads;
    for (int i = 0; i < num_threads; ++i) {
        threads.emplace_back(increment, increments_per_thread);
    }
    
    for (auto& t : threads) t.join();
    
    std::cout << "Final counter value: " << counter << std::endl;
    return 0;
}

使用条件

  • 简单的共享变量操作（如计数器、标志位）
  • 需要最高性能的同步场景
  • 对单个变量的操作

注意事项

  1. ​内存顺序​：理解并正确使用memory_order
  2. ​复合操作​：多个原子操作组合不是原子的
  3. ​ABA问题​：某些场景下需要考虑

易错点

  • 错误使用memory_order导致可见性问题
  • 认为多个原子操作组合是原子的
  • 忽略缓存一致性问题

5. 线程池 (Thread Pool)

基本概念

线程池预先创建一组线程，避免频繁创建销毁线程的开销，提高任务执行效率。

代码示例 (C++11简单实现)

#include <vector>
#include <thread>
#include <queue>
#include <mutex>
#include <condition_variable>
#include <functional>
#include <future>

class ThreadPool {
public:
    ThreadPool(size_t threads) : stop(false) {
        for (size_t i = 0; i < threads; ++i) {
            workers.emplace_back([this] {
                while (true) {
                    std::function<void()> task;
                    {
                        std::unique_lock<std::mutex> lock(this->queue_mutex);
                        this->condition.wait(lock, [this] {
                            return this->stop || !this->tasks.empty();
                        });
                        if (this->stop && this->tasks.empty()) return;
                        task = std::move(this->tasks.front());
                        this->tasks.pop();
                    }
                    task();
                }
            });
        }
    }
    
    template<class F, class... Args>
    auto enqueue(F&& f, Args&&... args) 
        -> std::future<typename std::result_of<F(Args...)>::type> {
        using return_type = typename std::result_of<F(Args...)>::type;
        
        auto task = std::make_shared<std::packaged_task<return_type()>>(
            std::bind(std::forward<F>(f), std::forward<Args>(args)...)
        );
        
        std::future<return_type> res = task->get_future();
        {
            std::unique_lock<std::mutex> lock(queue_mutex);
            if(stop) throw std::runtime_error("enqueue on stopped ThreadPool");
            tasks.emplace([task](){ (*task)(); });
        }
        condition.notify_one();
        return res;
    }
    
    ~ThreadPool() {
        {
            std::unique_lock<std::mutex> lock(queue_mutex);
            stop = true;
        }
        condition.notify_all();
        for (std::thread &worker : workers)
            worker.join();
    }

private:
    std::vector<std::thread> workers;
    std::queue<std::function<void()>> tasks;
    
    std::mutex queue_mutex;
    std::condition_variable condition;
    bool stop;
};

// 使用示例
int main() {
    ThreadPool pool(4);
    std::vector<std::future<int>> results;
    
    for (int i = 0; i < 8; ++i) {
        results.emplace_back(
            pool.enqueue([i] {
                std::cout << "Task " << i << " started\n";
                std::this_thread::sleep_for(std::chrono::seconds(1));
                std::cout << "Task " << i << " finished\n";
                return i*i;
            })
        );
    }
    
    for (auto&& result : results)
        std::cout << "Result: " << result.get() << std::endl;
    
    return 0;
}

使用条件

  • 需要执行大量短期任务
  • 避免频繁创建销毁线程的开销
  • 需要限制并发线程数量

注意事项

  1. ​任务队列大小​：无界队列可能导致内存耗尽
  2. ​异常处理​：任务中的异常需要妥善处理
  3. ​线程数量​：根据CPU核心数和任务类型选择合适数量
  4. ​任务依赖​：注意任务间的依赖关系

易错点

  • 忘记正确处理线程池关闭
  • 任务抛异常导致线程退出
  • 任务之间有共享状态但未同步
  • 线程数量设置不合理（过多或过少）

综合对比

同步机制适用场景优点缺点
互斥锁一般共享资源访问简单可靠，线程挂起不占CPU上下文切换开销大
自旋锁极短临界区，多核无上下文切换，响应快忙等待消耗CPU
读写锁读多写少场景允许多个读者并发实现复杂，可能写者饥饿
原子操作简单变量操作最高性能，无锁只能用于简单操作
线程池大量短期任务避免线程创建开销，控制并发度实现复杂，需管理任务队列

最佳实践建议

  1. ​优先考虑更高层次的抽象​：如任务并行库(TBB)、OpenMP等
  2. ​避免过早优化​：先用简单互斥锁，有性能问题再考虑其他
  3. ​尽量减少共享数据​：通过设计减少同步需求
  4. ​使用工具检测问题​：如ThreadSanitizer检测数据竞争
  5. ​理解内存模型​：特别是使用原子操作时
  6. ​测试多线程代码​：多线程bug往往难以重现，需要专门测试

多线程编程复杂但功能强大，正确使用这些同步机制可以构建高效可靠的并发程序。

Linux：并发与同步（二）----排队自旋锁、互斥锁及源码分析
m0_50499434的博客
06-17 1037
然而，自旋锁（spinlock）和其他锁不同，虽然它们存在于进程中，但对一个 CPU 来说，自旋锁的数量是固定的。最终，通过自旋锁和等待机制确保锁的正确获取，同时处理各种错误和信号情况。​ 顾名思义，即认为锁的持有者正在临界区执行时，可以断定锁的持有者可以很快退出临界区并且释放该锁，比起进入睡眠队列，不如像自旋锁一样等待，由于睡眠和唤醒付出的代价可能更高。MUTEX_FLAG_HANDOFF:对互斥锁的等待队列中的第一个等待者会设置这个标志位，锁持有者在解锁的时候把锁直接传递给第一个等待者。
线程同步（互斥锁、条件变量、读写锁、自旋锁）
weixin_49199646的博客
12-22 655
线程同步 所谓线程同步，就是有多个线程共享相同的内存时，需要确保共享数据在每个线程中都是一致的。若同一个共享变量在两个及以上线程中所显示的结果是不一样的，就表明线程不同步。 什么情况下需要使用线程同步？ 当一个线程可以修改的变量，其它线程也可以读取或修改的时候，必须进行线程同步，否则可能导致错误。 假设有两个线程A和B，需要对整型全局变量i进行递增操作，过程如下所示： 递增操作不是原子操作，编译器完成递增操作实际上需要3条机器指令： （1）将变量从内存单元读入寄存器； （2）在寄存器中对变量进行增量操作；
C++ 互斥锁、自旋锁和原子操作
qq_50373827的博客
10-02 1631
目的：用于保护临界区，确保同一时刻只有一个线程可以访问共享资源。适合对复杂数据结构的保护。优点简单易用，符合 RAII 原则，确保资源的自动释放。能够处理复杂的线程同步场景。缺点可能导致上下文切换，增加开销。在高竞争情况下，线程可能会被阻塞，影响程序的响应性。使用场景：适合保护对复杂数据结构的操作，或者临界区较长的场景。
嵌入式Linux-线程同步-自旋锁和读写锁
weixin_52694360的博客
02-06 926
自旋锁与互斥锁很相似，从本质上说也是一把锁，在访问共享资源之前对自旋锁进行上锁，在访问完成后释放自旋锁（解锁）；事实上，从实现方式上来说，互斥锁是基于自旋锁来实现的，所以自旋锁相较于互斥锁更加底层。如果在获取自旋锁时，自旋锁处于未锁定状态，那么将立即获得锁（对自旋锁上锁）；如果在获取自旋锁时，自旋锁已经处于锁定状态了，那么获取锁操作将会在原地“自旋”，直到该自旋锁的持有者释放了锁。由此介绍可知，自旋锁与互斥锁相似，但是互斥锁在无法获取到锁时会让线程陷入阻塞等待状态；
线程互斥锁、读写锁、自旋锁、死锁
gointt的博客
09-01 171
1、当读写锁未被任何线程占用，发出读请求、写请求的线程都可以占用，如果同时请求，默认优先给读请求占用。2、当变成读锁(多个线程占用)时，读请求的线程可以占用不会阻塞，但是写请求的线程会阻塞等待读锁解锁。3、当发出读请求的线程正在执行时，发出写请求的线程必须等待前面所有读请求线程执行完后才能执行。4、当发出写请求的线程正在执行时，发出读请求的线程必须等待前面所有写请求线程执行完后才能执行。当读写锁被发出读请求的线程占用时，称为"读锁"，当读写锁被发出读请求的线程占用时，称为"写锁"
互斥锁、自旋锁、读写锁、悲观锁和乐观锁
qq_50993361的博客
05-21 2089
都有哪些锁？ 互斥锁、自旋锁、读写锁、乐观锁、悲观锁。
互斥锁-自旋锁-可重入锁-读写锁-悲观锁-乐观锁-分布式锁
General_zy的博客
12-03 540
Go语言的发明者认为，如果当你的代码需要重入锁时，那就说明你的代码有问题了，我们正常写代码时，从入口函数开始，执行的层次都是一层层往下的，如果有一个锁需要共享给几个函数，那么就在调用这几个函数的上面，直接加上互斥锁就好了，不需要在每一个函数里面都添加锁，再去释放锁。2、不具备可重入的特性，因为同一个线程在释放锁之前，行数据一直存在，无法再次成功插入数据，所以，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器和线程相同，若相同则直接获取锁；
【嵌入式Linux】并发与竞争 -----自旋锁、信号量、互斥体
欢迎私信、留言交流
08-26 865
> Linux内核的并发与竞争，自旋锁、信号量、互斥体的基本概念以及使用结构体接口 > 以下笔记参考自左中凯大佬的开发笔记，学习过程中精简出以下内容 > 适合Linux内核和驱动开发入门，用以记录
【面试八股总结】锁：互斥锁、自旋锁、读写锁、乐观锁、悲观锁
Chesnut.
06-05 1236
读优先锁期望的是，读锁能被更多的线程持有，以便提高读线程的并发性，它的工作方式是：当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 仍然可以成功获取读锁，最后直到读线程 A 和 C 释放读锁后，写线程 B 才可以成功获取写锁。，表示该数据的版本号，每当数据被修改，版本号+1。当「写锁」没有被线程持有时，多个线程能够并发地持有读锁，这大大提高了共享资源的访问效率，因为「读锁」是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据。
C++多线程：原子操作和自旋锁
2301_81290340的博客
07-14 739
原子操作简单来说就是对于一个数据不可再细分的操作，例如读，写等基本操作就是原子操作。
Linux系统--信号量、互斥锁、原子操作和自旋锁的区别
积木的笔记
09-23 1436
主要介绍了信号量、互斥锁、原子操作和自旋锁的区别。
用原子自旋读写锁代替互斥锁提高多线程访问公共资源效率
04-12
首先，原子自旋锁的核心在于原子操作，如CAS（Compare and Swap）指令，这是一个无锁编程中的基础操作，可以确保在多线程环境下对共享变量的修改是原子性的，不会被其他线程中断。 当线程试图获取自旋锁时，它会...
Delphi XE10.2.3多线程大量读和少量写公共资源时，用原子自旋读写锁代替互斥锁提高效率
04-12
对于一个高性能服务器在处理多数读取，少量写入的场景时，如果还是使用常规的互斥锁方式，显然就不明智了，这种读多写少的场景最适合使用读写锁方式，读取时不加锁，多线程并发读取，效率是最高的，要写入数据时堵塞...
技术文档 | Pulsar 中的消息保留、过期及积压机制解析（上）
Apache Pulsar
08-13 959
由于不同Subscription的消费进度可能不同，有的较快，有的较慢，因此 Pulsar 对数据的删除是以该 Topic 中消费最慢的 Subscription 为基准，被它消费过后的数据才是可删除的。同样因为 Expiry 的二分查找机制，如果消息的时间戳是乱序的(在使用 Shared 模式的 Producer 的情况下，这很可能发生)， 可能会导致 Expiry 机制无法正确的移动游标，从而导致某些过期消息会被继续消费。正确的 Retention 策略应该是周期性的清理旧数据，
Java——琐碎知识点2
2401_88065518的博客
08-15 390
Java基础知识点：Java官方帮助文档、Scanner扫描器、快捷键、“==”做比较、获取代码运行时间、打印对象名时不会出现内存地址的类型、Arrays类常用方法、循环标号的使用、Lambda表达式、异常处理、Java浮点数的精度问题（BigDecimal）、DecimalFormat格式化数字工具、printf格式化输出
JavaScript 核心基础：类型检测、DOM 操作与事件处理
最新发布
热爱音乐和二次元！
08-15 717
本文系统梳理 JavaScript 核心知识点，包括数据类型检测规则、遍历方式、DOM操作和事件处理。重点解析 typeof 运算符对不同数据类型的检测结果，数组与对象的遍历方法差异，以及使用 querySelector 获取元素的现代方案。同时详细讲解事件绑定的两种方式（onclick 覆盖 vs addEventListener 多播）和事件冒泡机制，帮助开发者构建扎实的 JS 基础，写出更健壮的代码。
MySQLinnodb引擎普通索引和唯一索引的区别
gdr12的专栏
08-15 635
特性唯一索引 (Unique Index)普通索引 (Non-Unique Index)唯一性约束✅ 强制，键值必须唯一❌ 不强制，允许多行相同键值Change Buffer 支持❌无法利用，变更必须同步写入索引页✅可以利用，提高写入性能 (减少磁盘 I/O)插入/更新检查必须立即检查唯一性 (可能读磁盘)无需立即检查唯一性锁范围 (插入时)可能略大 (Next-Key Lock 防幻读/唯一检查)通常更精确 (锁具体记录/间隙)NULL 值处理✅ 允许多个 NULL。
cat本地部署
Chaser______的博客
08-15 358
CAT监控系统部署指南 环境准备：JDK1.8、Tomcat、MySQL 获取CAT包：通过Git克隆源码或下载官网war包 部署步骤： 创建/data目录结构并设置权限 配置client.xml、datasources.xml和server.xml 导入SQL文件创建数据库 将cat.war部署到Tomcat的webapps目录 启动服务：启动Tomcat后访问http://ip:8080/cat 注意事项：将配置文件中的127.0.0.1替换为实际IP地址 （98字）
主流接口测试工具深度对比：从架构到实战的技术选型指南
srlsong的博客
08-15 807
主流API测试工具技术对比与选型指南 本文对Postman、Reqable、JMeter和RESTAssured四款主流接口测试工具进行了深度技术分析。从架构设计看，Postman基于Electron存在性能瓶颈，Reqable采用Flutter+C++实现高性能，JMeter依赖Java生态适合压测，RESTAssured则是纯代码框架。功能对比显示各工具在协议支持、并发能力和可视化调试等方面差异显著。性能测试表明RESTAssured和Reqable在单接口测试中表现最优，JMeter则在大规模并发场景
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值