std::map只修改不用加锁

最新推荐文章于 2024-09-04 16:39:28 发布
最新推荐文章于 2024-09-04 16:39:28 发布
阅读量4.4k 收藏 1
点赞数
分类专栏： c++基础
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jacke121/article/details/79774197
版权


std::map创建并初始化之后，不会再有任何的insert和delete键值对的操作。仅有的操作就是不同的线程会访问不同的key，对key对应的value进行修改，请问这种情况下，是否需要加锁？

不需要加锁

AI算法网奇
关注
专栏目录
面试官：为什么ConcurrentHashMap的读操作不需要加锁？
程序员界
09-10 794
目录 ConcurrentHashMap的简介 get操作源码 volatile登场 是加在数组上的volatile吗? 用volatile修饰的Node 总结 我们知道，ConcurrentHashmap(1.8)这个并发集合框架是线程安全的，当你看到源码的get操作时，会发现get操作全程是没有加任何锁的，这也是这篇博文讨论的问题——为什么它不需要加锁呢？ ConcurrentHashMap的简介 我想有基础的同学知道在jdk1.7中是采用Segment + HashEntry + Re
无锁map的实现
zzz_zou的专栏
11-24 5879
前一段时间看了关于无锁map实现的相关技术，主要用到了cas，faa等。        如果你还不了解cas和faa可以去baidu一下。cas和faa之所以效率比锁要高，是因为他们利用了cpu的特征，在切换时不需要考虑内存上下文。        这里就产生了一种无锁map的实现思路，可以继承自stl的map，自己进行一层封装，通过cas技术来实现锁的机制，对封装后的插入，删除等操作使用通过c
原子操作与锁
最新发布
oxygen3000的博客
09-04 630
今天我们讨论原子操作、锁操作。我们先来看一个案例：在并发编程时，我们使用十个线程对count进行++操作，每个线程加100000次，理论上这个结果是。但很可惜，经过几次实验，得出来的结果总是没有1000000：那么究竟是什么原因呢？？？？从代码逻辑来看，每个线程执行的函数操作都是对count加100000次，那么理论上会得到count的结果为1000000。可实际上，，而这个顺序是不可预测的。假设有两个线程 A 和 B，它们都试图增加一个全局变量count的值。
无锁HashMap的原理与实现
chivalry
06-03 1532
http://coolshell.cn/articles/9703.html java.util.HashMap并不能直接应用于多线程环境。对于多线程环境中应用HashMap，主要有以下几种选择： 使用线程安全的java.util.Hashtable作为替代。使用java.util.Collections.synchronizedMap方法，将已有的HashMap对象包装为线程安全
ConcurrentHashMap 怎么样去保证线程安全的, 读操作为什么不需要加锁
zxlp520的博客
07-01 2117
ConcurrentHashMap前言分析初识ConcurrentHashMap数据结构对比HashMap和ConcurrentHashMapConcurrentHashMapinitTable初始化put的线程安全transfer 扩容时的线程安全get总结 前言 最近在看公众号 看到一个问题：为什么 ConcurrentHashMap 的读操作不需要加锁？ 第一次看到这个问题的时候 我也确实比较懵逼 我虽然知道ConCurrentHashMap 是怎么在put的时候 去保证线程安全的，但是真的没关注
ConcurrentHashMap 无锁读
安冉
11-21 1817
ConcurrentHashMap 可以做到无锁读，而写使用分段锁机制，把整个哈希表切分成段segment(默认为16段)，每段有一个锁，最多可以同时有16个写线程。而读不受限制。 下文转自http://taozeyu.com   ConcurrentHashMap是一个线程安全的哈希实现类，它不但能使多线程同时操作该类时保证线程是安全的，同时为了保证对Map的读操作的高
百度自动驾驶apollo源码解读11:无锁哈希表AtomicHashMap
liujiayu2的专栏
03-10 653
直接上源代码吧，代码是阿波罗团队写的源代码，我这边给加了注释。简单写了个main.cpp对一些功能进行测试。
std string与线程安全_C++ STL容器如何解决线程安全的问题？
weixin_35714577的博客
01-30 1658
众所周知，STL容器不是线程安全的。对于vector，即使写方(生产者)是单线程写入，但是并发读的时候，由于潜在的内存重新申请和对象复制问题，会导致读方(消费者)的迭代器失效。实际表现也就是招致了core dump。另外一种情况，如果是多个写方，并发的push_back()，也会导致core dump。解法一：加锁是一种解决方案，但是加std::mutex互斥锁确实性能较差。对于多读少写的场景可以...
多线程操作stl::map引起的数据不一致问题的解决过程与方法
热门推荐
麦克船长的技术笔记
09-14 1万+
昨天晚上业务出现了一次core dump，今天早上来check生产环境的core文件的堆栈内容如下： gdb ./appname --core=core.1234 (gdb) bt 得到栈的内容如下： #0 0x00007f5634262734 in std::_Rb_tree_rotate_right ()
C++11多线程——lock详解
Fivestar_wang的专栏
04-17 1万+
C++11提供了两种管理锁的类 std::lock_guard：与mutex RAII相关，方便线程对互斥量上锁std::unique_lock:   与mutex RAII相关，方便线程对互斥量上锁，相比std::lock_guard提供了更好的上锁和解锁控制 一 lock_guard详解 lock_guard是一个模板类：templateclass lock_guar
【并发编程九】c++线程同步——互斥（mutex）
junxuezheng的博客
01-03 1677
简介：本篇文章，我们详细的介绍下c++标准库提供的线程同步方法中的第一个——互斥（mutex）。
java无锁hashmap原理与实现详解
09-04
本文主要介绍了java无锁hashmap原理与实现，大家参考使用吧
OS和Linux笔记
qq_33265796的博客
04-10 658
OS和Linux笔记操作系统基本概念进程管理进程和线程协程同步互斥死锁CAS技术IPC线程间通信内存管理Linux基础知识守护进程系统监测编译调试文件管理零拷贝技术 操作系统 基本概念 用户态和内核态 用户态和内核态的区别 用户态和内核态是操作系统的两种运行级别，两者最大的区别就是特权级不同 用户态拥有最低的特权级，内核态拥有较高的特权级 运行在用户态的程序不能直接访问操作系统内核数据结构和程序 操作系统的数据都是存放于系统空间的，用户进程的数据是存放于用户空间的。 分开来存放，就让系统的数据和用户的
C++ 关于无锁map的一些思考（线程安全）
qq_38781075的博客
06-28 2330
1、map 的 key 是可以穷举的2、允许修改已经删除的 value，我们认为是创建了新 value 再修改。
无锁HASHMAP的原理与实现
weixin_44782075的博客
05-31 502
在疫苗：Java HashMap的死循环疫苗：Java HashMap的死循环中，我们看到，java.util.HashMap并不能直接应用于多线程环境。对于多线程环境中应用HashMap，主要有以下几种选择： 使用线程安全的java.util.Hashtable作为替代。 使用java.util.Collections.synchronizedMap方法，将已有的HashMap对象包装为线程安...
无锁数据结构
luansxx的专栏
10-06 5295
Andrei AlexandrescuDecember 16, 2007译者：张桂权12/25/2007（初稿阶段，没有得到许可不得引用，否则后果自负）泛型编程（Generic）被删除之后（我知道，认为母校（毕业的学校）要求一切，不仅仅是100%的个人时间，是非常天真的），对于本篇文章来说，到目前为止，就没有丰富的题材了。一个备选主题是构造器的讨论，尤其是前沿的构造器，异常处理
c++程序unordered_map使用lock_guard给线程加独占锁mutex递归锁recursive_mutex的玩法探究
weixin_43911160的博客
03-01 1226
对于同一个资源同时进行多线程的更新和读取操作，如果把操作线性化/序列化后前述操作的组合有不同的效果，那么该资源最终状态以及被读取到的状态就是不可控的，这对于严谨性要求严格的程序来说是不可接受的。此时，我们就需要对这个资源加上锁，只有竞争到的才能对该资源进行操作。c++程序中使用了第三方提供的api，api推送过来的数据需要做过滤，因为可能是同账号其他客户端的操作产生的。通过api交互的数据有个统一的主键，我们同样把他作为unordered_map的key值。
std::map 多线程加锁问题
05-09
在多线程环境下使用 `std::map`，需要注意线程安全问题。由于 `std::map` 是 STL 中的容器，它并不是线程安全的，因此在多线程环境下使用时需要注意加锁。在对 `std::map` 进行读写操作时，必须保证同一时间只有一个线程在进行操作，否则会出现数据竞争问题，导致程序崩溃或数据错误。 一种解决方案是使用互斥锁来保证线程安全，即在对 `std::map` 进行操作前先锁定互斥锁，操作完成后再释放互斥锁。示例代码如下： ```c++ #include <map> #include <mutex> std::map<int, int> myMap; std::mutex myMutex; void writeData(int key, int value) { std::lock_guard<std::mutex> lock(myMutex); // 加锁 myMap[key] = value; // 写入数据 } int readData(int key) { std::lock_guard<std::mutex> lock(myMutex); // 加锁 return myMap[key]; // 读取数据 } ``` 在上述代码中，我们使用了 `std::mutex` 类型的互斥锁来保证线程安全，通过 `std::lock_guard` 类型的锁保证在执行操作时自动加锁和解锁。这种方法能够保证线程安全，但是由于每次读写操作都需要加锁和解锁，因此会带来一定的性能损失。 另一种解决方案是使用读写锁，即读锁和写锁。在读操作时加读锁，多个线程可以同时读取数据，但在写操作时加写锁，只允许一个线程进行写操作。这种方法能够提高程序的性能，但需要注意避免死锁问题。示例代码如下： ```c++ #include <map> #include <shared_mutex> std::map<int, int> myMap; std::shared_mutex myMutex; void writeData(int key, int value) { std::unique_lock<std::shared_mutex> lock(myMutex); // 加写锁 myMap[key] = value; // 写入数据 } int readData(int key) { std::shared_lock<std::shared_mutex> lock(myMutex); // 加读锁 return myMap[key]; // 读取数据 } ``` 在上述代码中，我们使用了 `std::shared_mutex` 类型的读写锁来保证线程安全，通过 `std::unique_lock` 类型的写锁和 `std::shared_lock` 类型的读锁保证在执行操作时自动加锁和解锁。这种方法能够提高程序的性能，但需要注意避免死锁问题。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

AI算法网奇

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值