rust使用Atomic創(chuàng)建全局變量和使用操作方法

更新時間：2024年05月05日 11:24:09 作者：1024小神

從 Rust1.34 版本后,就正式支持原子類型,原子指的是一系列不可被 CPU 上下文交換的機器指令,這些指令組合在一起就形成了原子操作,這篇文章主要介紹了rust使用Atomic創(chuàng)建全局變量和使用,需要的朋友可以參考下

從 Rust1.34 版本后，就正式支持原子類型。原子指的是一系列不可被 CPU 上下文交換的機器指令，這些指令組合在一起就形成了原子操作。在多核 CPU 下，當某個 CPU 核心開始運行原子操作時，會先暫停其它 CPU 內核對內存的操作，以保證原子操作不會被其它 CPU 內核所干擾。

由于原子操作是通過指令提供的支持，因此它的性能相比鎖和消息傳遞會好很多。相比較于鎖而言，原子類型不需要開發(fā)者處理加鎖和釋放鎖的問題，同時支持修改，讀取等操作，還具備較高的并發(fā)性能，幾乎所有的語言都支持原子類型。

可以看出原子類型是無鎖類型，但是無鎖不代表無需等待，因為原子類型內部使用了CAS循環(huán)，當大量的沖突發(fā)生時，該等待還是得等待！但是總歸比鎖要好。

CAS 全稱是 Compare and swap, 它通過一條指令讀取指定的內存地址，然后判斷其中的值是否等于給定的前置值，如果相等，則將其修改為新的值

原子類型的一個常用場景，就是作為全局變量來使用:

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![1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
    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:?}");
}

并且能夠保證數(shù)據(jù)讀寫不出錯：

以上代碼啟動了數(shù)個線程，每個線程都在瘋狂對全局變量進行加 1 操作, 最后將它與線程數(shù) * 加1次數(shù)進行比較，如果發(fā)生了因為多個線程同時修改導致了臟數(shù)據(jù)，那么這兩個必將不相等。好在，它沒有讓我們失望，不僅快速的完成了任務，而且保證了 100%的并發(fā)安全性。

當然以上代碼的功能其實也可以通過Mutex來實現(xiàn)，但是后者的強大功能是建立在額外的性能損耗基礎上的，因此性能會遜色不少:

Atomic實現(xiàn)：673ms Mutex實現(xiàn): 1136ms

可以看到Atomic實現(xiàn)會比Mutex快41%，實際上在復雜場景下還能更快(甚至達到 4 倍的性能差距)！

還有一點值得注意: 和Mutex一樣，Atomic的值具有內部可變性，你無需將其聲明為mut：

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);
}

這里有一個奇怪的枚舉成員Ordering::Relaxed, 看上去很像是排序作用，但是我們并沒有做排序操作?。繉嶋H上它用于控制原子操作使用的內存順序。

內存順序

內存順序是指 CPU 在訪問內存時的順序，該順序可能受以下因素的影響：

代碼中的先后順序

編譯器優(yōu)化導致在編譯階段發(fā)生改變(內存重排序 reordering)
運行階段因 CPU 的緩存機制導致順序被打亂

限定內存順序的 5 個規(guī)則：

在理解了內存順序可能存在的改變后，你就可以明白為什么 Rust 提供了Ordering::Relaxed用于限定內存順序了，事實上，該枚舉有 5 個成員:

Relaxed，這是最寬松的規(guī)則，它對編譯器和 CPU 不做任何限制，可以亂序。
Release 釋放，設定內存屏障(Memory barrier)，保證它之前的操作永遠在它之前，但是它后面的操作可能被重排到它前面。
Acquire 獲取, 設定內存屏障，保證在它之后的訪問永遠在它之后，但是它之前的操作卻有可能被重排到它后面，往往和Release在不同線程中聯(lián)合使用。
AcqRel, 是 Acquire 和 Release 的結合，同時擁有它們倆提供的保證。比如你要對一個 atomic 自增 1，同時希望該操作之前和之后的讀取或寫入操作不會被重新排序。
SeqCst 順序一致性， SeqCst就像是AcqRel的加強版，它不管原子操作是屬于讀取還是寫入的操作，只要某個線程有用到SeqCst的原子操作，線程中該SeqCst操作前的數(shù)據(jù)操作絕對不會被重新排在該SeqCst操作之后，且該SeqCst操作后的數(shù)據(jù)操作也絕對不會被重新排在SeqCst操作前。
這些規(guī)則由于是系統(tǒng)提供的，因此其它語言提供的相應規(guī)則也大同小異，大家如果不明白可以看看其它語言的相關解釋。

Atomic 能替代鎖嗎

那么原子類型既然這么全能，它可以替代鎖嗎？答案是不行：

對于復雜的場景下，鎖的使用簡單粗暴，不容易有坑
std::sync::atomic包中僅提供了數(shù)值類型的原子操作：AtomicBool, AtomicIsize, AtomicUsize, AtomicI8, AtomicU16等，而鎖可以應用于各種類型
在有些情況下，必須使用鎖來配合，例如上一章節(jié)中使用Mutex配合Condvar