rust使用Atomic创建全局变量和使用操作方法
<div id="navCategory"><h5 class="catalogue">目录</h5><ul class="first_class_ul"><li>内存顺序</li><li>Atomic 能替代锁吗</li><li>Atomic 的应用场景</li></ul></div><p><code>Mutex</code>用起来简单，但是无法并发读，<code>RwLock</code>可以并发读，但是使用场景较为受限且性能不够，那么有没有一种全能性选手呢？ 欢迎我们的<code>Atomic</code>闪亮登场。</p><p>从 Rust1.34 版本后，就正式支持原子类型。原子指的是一系列不可被 CPU 上下文交换的机器指令，这些指令组合在一起就形成了原子操作。在多核 CPU 下，当某个 CPU 核心开始运行原子操作时，会先暂停其它 CPU 内核对内存的操作，以保证原子操作不会被其它 CPU 内核所干扰。</p>
<p>由于原子操作是通过指令提供的支持，因此它的性能相比锁和消息传递会好很多。相比较于锁而言，原子类型不需要开发者处理加锁和释放锁的问题，同时支持修改，读取等操作，还具备较高的并发性能，几乎所有的语言都支持原子类型。</p>
<p>可以看出原子类型是无锁类型，但是无锁不代表无需等待，因为原子类型内部使用了<code>CAS</code>循环，当大量的冲突发生时，该等待还是得等待！但是总归比锁要好。</p>
<blockquote><p>CAS 全称是 Compare and swap, 它通过一条指令读取指定的内存地址，然后判断其中的值是否等于给定的前置值，如果相等，则将其修改为新的值</p></blockquote>
<p>原子类型的一个常用场景，就是作为全局变量来使用:</p>
<div class="jb51code"><pre class="brush:plain;">use std::sync::atomic::{AtomicI32, Ordering};
use std::thread::{self, JoinHandle};
static R: AtomicI32 = AtomicI32::new(0);
fn thread_add() {
// 多个线程修改全局变量
for i in 0..1000 {
R.fetch_add(1, Ordering::Relaxed);
}
}
fn main() {
// This will POST a body of `foo=bar&baz=quux`
let mut init_data = vec!;
let mut hand_list = Vec::with_capacity(init_data.len());
for i in init_data {
hand_list.push(thread::spawn(thread_add));
}
for h in hand_list {
h.join().unwrap();
}
let r_value = R.load(Ordering::Relaxed);
println!("全局变量最后的值是: {r_value:?}");
}</pre></div>
<p>并且能够保证数据读写不出错：</p>
<p style="text-align:center"><img alt="" src="https://img.jbzj.com/file_images/article/202405/2024050511195243.png" /></p>
<p>以上代码启动了数个线程，每个线程都在疯狂对全局变量进行加 1 操作, 最后将它与<code>线程数 * 加1次数</code>进行比较，如果发生了因为多个线程同时修改导致了脏数据，那么这两个必将不相等。好在，它没有让我们失望，不仅快速的完成了任务，而且保证了 100%的并发安全性。</p>
<p>当然以上代码的功能其实也可以通过<code>Mutex</code>来实现，但是后者的强大功能是建立在额外的性能损耗基础上的，因此性能会逊色不少:</p>
<p><code>Atomic实现：673ms Mutex实现: 1136ms </code></p>
<p>可以看到<code>Atomic</code>实现会比<code>Mutex</code>快<strong>41%</strong>，实际上在复杂场景下还能更快(甚至达到 4 倍的性能差距)！</p>
<p>还有一点值得注意: 和<code>Mutex</code>一样，<code>Atomic</code>的值具有内部可变性，你无需将其声明为<code>mut</code>：</p>
<div class="jb51code"><pre class="brush:plain;">use std::sync::Mutex;
use std::sync::atomic::{Ordering, AtomicU64};
struct Counter {
count: u64
}
fn main() {
let n = Mutex::new(Counter {
count: 0
});
n.lock().unwrap().count += 1;
let n = AtomicU64::new(0);
n.fetch_add(0, Ordering::Relaxed);
}</pre></div>
<p>这里有一个奇怪的枚举成员<code>Ordering::Relaxed</code>, 看上去很像是排序作用，但是我们并没有做排序操作啊？实际上它用于控制原子操作使用的<strong>内存顺序</strong>。</p>
<p class="maodian"></p><h2>内存顺序</h2>
<p>内存顺序是指 CPU 在访问内存时的顺序，该顺序可能受以下因素的影响：</p>
<p>代码中的先后顺序</p>
<p>编译器优化导致在编译阶段发生改变(内存重排序 reordering)<br />运行阶段因 CPU 的缓存机制导致顺序被打乱</p>
<p>限定内存顺序的 5 个规则：</p>
<p>在理解了内存顺序可能存在的改变后，你就可以明白为什么 Rust 提供了Ordering::Relaxed用于限定内存顺序了，事实上，该枚举有 5 个成员:</p>
<p>Relaxed， 这是最宽松的规则，它对编译器和 CPU 不做任何限制，可以乱序。<br />Release 释放，设定内存屏障(Memory barrier)，保证它之前的操作永远在它之前，但是它后面的操作可能被重排到它前面。<br />Acquire 获取, 设定内存屏障，保证在它之后的访问永远在它之后，但是它之前的操作却有可能被重排到它后面，往往和Release在不同线程中联合使用。<br />AcqRel, 是 Acquire 和 Release 的结合，同时拥有它们俩提供的保证。比如你要对一个 atomic 自增 1，同时希望该操作之前和之后的读取或写入操作不会被重新排序。<br />SeqCst 顺序一致性， SeqCst就像是AcqRel的加强版，它不管原子操作是属于读取还是写入的操作，只要某个线程有用到SeqCst的原子操作，线程中该SeqCst操作前的数据操作绝对不会被重新排在该SeqCst操作之后，且该SeqCst操作后的数据操作也绝对不会被重新排在SeqCst操作前。<br />这些规则由于是系统提供的，因此其它语言提供的相应规则也大同小异，大家如果不明白可以看看其它语言的相关解释。</p>
<p class="maodian"></p><h2>Atomic 能替代锁吗</h2>
<p>那么原子类型既然这么全能，它可以替代锁吗？答案是不行：</p>
<p>对于复杂的场景下，锁的使用简单粗暴，不容易有坑<br />std::sync::atomic包中仅提供了数值类型的原子操作：AtomicBool, AtomicIsize, AtomicUsize, AtomicI8, AtomicU16等，而锁可以应用于各种类型<br />在有些情况下，必须使用锁来配合，例如上一章节中使用Mutex配合Condvar</p>
<p class="maodian"></p><h2>Atomic 的应用场景</h2>
<p>事实上，Atomic虽然对于用户不太常用，但是对于高性能库的开发者、标准库开发者都非常常用，它是并发原语的基石，除此之外，还有一些场景适用：</p>
<p>无锁(lock free)数据结构<br />全局变量，例如全局自增 ID, 在后续章节会介绍<br />跨线程计数器，例如可以用于统计指标<br />以上列出的只是Atomic适用的部分场景，具体场景需要大家未来根据自己的需求进行权衡选择。</p>
<p>到此这篇关于rust使用Atomic创建全局变量和使用的文章就介绍到这了,更多相关rust创建全局变量内容请搜索琼殿技术社区以前的文章或继续浏览下面的相关文章希望大家以后多多支持琼殿技术社区！</p>
<div class="art_xg">
<b>您可能感兴趣的文章:</b><ul><li>rust的nutyp验证和validator验证数据的方法示例详解</li><li>Rust 累计时间长度的操作方法</li><li>Rust捕获全局panic并记录进程退出日志的方法</li><li>RUST语言函数的定义与调用方法</li><li>rust 一个日志缓存记录的通用实现方法</li><li>Rust中的方法与关联函数使用解读</li></ul>
</div>
</div>
<!--endmain-->
頁:
[1]