{"id":87,"title":"如何在Rust中实现全局变量模式？","abstraction":"在Java、C++中非常简单的全局变量，在Rust中就行不通了，那么为什么Rust没有简单的实现？又如何理解、设计一个全局变量模式呢？","content":"

在Java、C++中非常简单的全局变量，在Rust中就行不通了，那么为什么Rust没有简单的实现？又如何理解、设计一个全局变量模式呢？

为什么简单的需求在Rust中如此复杂

简单来讲，Rust更注重内存安全性，导致全局变量模式不易实现。具体来讲，Rust中有以下限制：

全局变量在初始化时，必须是线程安全、没有竞争的
Java、C++在使用全局变量时，会碰到多个线程初始化变量的问题，那到底是谁来初始化变量呢？如果一个全局变量又依赖另一个全局变量，如何解决依赖呢？Java、C++各自有自己的解决方法，但是方法不统一，没有明确的标准。Rust语言则直接不允许这么做。
所有const类型的变量必须在编译时就明确其内存大小
只有这样，编译器才能确保全局变量在运行时是内存安全的。

总结起来，就是在使用全局变量时不可以动态分配内存。什么算动态分配内存呢？这里指的是变量需要使用堆内存——Heap。Rust中的Vec、String、HashMap、Box、Rc/Arc等都会用到堆内存，都不可以用在全局变量，下面是一些例子：

// 合法，KILO在编译时明确类型和值\nconst KILO: i32 = 1024;\n\n// 不合法，vec!宏会调用动态分配内存的方法\n// 这种方式不允许用在const变量\nconst GLOBAL_VEC: Vec<i32> = vec![1,2,3,4];\n\n// 合法，&[i32]可以被存储在只读代码段，有明确的位置和大小\n// 不会在运行时分配内存\nconst GLOBAL_SLICE: &[i32] = &[1,2,3,4];\n\n\nstruct Point {\n    x: i32,\n    y: i32,\n}\n\n// 合法，Point类型预先明确内存大小，可以在编译时确定其内存大小\n// 实际上\nconst ORIGIN: Point = Point { x: 0, y: 0 };\n

另外需要注意const和static类型的细微差别：

const类型的变量跟C++中的#define相似，编译器在编译时会将调用const变量的地方直接替换为const具体的值，因此它是不可能被修改的。
static类型的变量实际上是内存中占据一个固定地址的变量，因为它位于内存中，实际上通过unsafe的方式也是可以修改其内存的。

// 这个变量会被编译器存储在代码的.rodata段，地址固定\nstatic MY_GLOBAL_STRING: &str = \"This is a global static string.\"; \n\n// 这个变量无法保证有固定的内存地址\nconst MY_GLOBAL_STRING: &str = \"This is a global static string.\";

Rust提供的工具

为了实现内存的安全，Rust标准库提供了很多工具来帮助我们管理特殊需求下的内存。

Cell<T>
Rust语言中有一个重要的概念叫做interior mutability，它是为了打破Rust语言中对引用、可变引用的规则，满足多线程场景、全局变量场景的需求而提出的。例如，Mutex<T>就是为了多个线程之间共享同一个变量的场景设计的。在interior mutability中最基础的结构就是这个Cell<T>。该结构支持保存一个变量，我们可以向里面写入内容、也可以把内容取出来。注意我们取出来的不是引用(borrowed)，而是直接取走了(moved)。可以将其想象为丰巢快递柜，我们可以往里面暂存包裹，也可以取走包裹，但是不能在未取走的状态下查看包裹的内容。（当然，这里面有个特殊情况，如果变量实现了Copy属性，Cell<T>可以复制一下内容再返回给我们，也就是可以多次提取。）

use std::cell::Cell;\n\n// 在Cell中存储内容\nlet c = Cell::new(42);\n\n// 修改Cell中的内容\nc.set(100);       // mutate through immutable reference\n\n// 提取Cell中的内容\nprintln!(\"{}\", c.get());

RefCell<T>
Cell<T>中不方便的地方在于我们无法获取内容的引用，为了满足这个需求，就可以使用RefCell<T>。RefCell<T>将Rust语言的引用、借用机制套用在内部变量中，保证同一时刻只能有一段代码可以修改内容。与普通的引用、借用规则在编译时就已经检查好，RefCell<T>的约束在运行时才能检查，也就是说这个种安全不是“零开销”的，效率会相对低一些。RefCell<T>除了take方法，还提供了borrow、borrow_mut方法，分别用于获取引用、可变引用。

use std::cell::RefCell;\n\nlet c = RefCell::new(5);\n\n// 获取引用\nlet borrowed_five = c.borrow();\nlet borrowed_five2 = c.borrow();\n\n// Rust语言中要么只能有一个mutable borrow，要么有多个immutable borrow\n// 因此下面的代码可以编译通过，但是运行时会panic\nlet borrowed_five3 = c.borrow_mut();

OnceCell<T>
在全局变量场景中，我们经常需要设置一次全局变量的内容，然后后续直接引用，使用RefCell<T>完全可以满足这种需求，但是为了方便起见，标准库提供了OnceCell<T>。这种Cell<T>只能写入一次，多次写入会造成panic，但是可以多次读取。而且在读取时获取的是变量的引用，而不是直接取走变量。到这里，我们就看到了实现全局变量模式的曙光。

use std::cell::OnceCell;\n\nlet cell = OnceCell::new();\nassert!(cell.get().is_none());\n\n// 获取变量的引用，如果没有设置变量就初始化一下\nlet value: &String = cell.get_or_init(|| {\n    \"Hello, World!\".to_string()\n});\nassert_eq!(value, \"Hello, World!\");\n\n// 获取变量的引用，也可以使用get_mut获取可变引用\nassert!(cell.get().is_some());

LazyCell<T>
LazyCell<T>是在OnceCell<T>基础上再做了一些修改，为其添加了impl Deref特性，添加Deref特性后，在函数调用、方法调用时就可以依靠编译器的Auto Deref规则，少写一些代码。

use std::cell::LazyCell;\n\nlet lazy: LazyCell<i32> = LazyCell::new(|| {\n    println!(\"initializing\");\n    92\n});\n\n// 在使用lazy时，它自动帮助我们调用了上面的初始化代码，即初始化为92\n// 这里调用*号就是显式地调用了Deref，然后又调用了i32的Copy方法\nprintln!(\"{}\", *lazy);\n\n// 第二次调用就不会再重新执行上面的初始化代码了\nprintln!(\"{}\", *lazy);

上面的四种结构都适用于单线程环境，它们不是线程安全的。如果需要线程安全类型的结构，需要使用Mutex<T>、RwLock<T>、OnceLock<T>。

怎样实现全局变量模式

场景1: 使用全局变量共享类似于环境变量的信息，在程序初始化时设置一次，后续只会读取。这种场景只需要使用OnceCell<T>就可以，但是如果涉及到多线程、异步执行环境，OnceCell<T>就不能共享String、Vec类型的变量，因此需要使用OnceLock<T>。

use std::sync::OnceLock;\n\npub struct EnvGlobal {\n    pub base_path: String,\n    pub database_uri: String,\n}\n\nstatic  ENV_GLOBAL: OnceLock<EnvGlobal> = OnceLock::new();\n\npub fn get_env_global() -> &'static EnvGlobal {\n    ENV_GLOBAL.get_or_init(|| {\n        EnvGlobal { \n            base_path: String::from(\"BASE_PATH\"), \n            database_uri: String::from(\"DB_URI\"),\n        }\n    })\n}

也可以使用LazyLock<T>：

use std::sync::LazyLock;\n\npub struct EnvGlobal {\n    pub base_path: String,\n    pub database_uri: String,\n}\n\n// 在其他地方可以直接使用ENV_GLOBAL\npub static ENV_GLOBAL: LazyLock<EnvGlobal> = LazyLock::new(|| {\n    EnvGlobal { \n        base_path: String::from(\"BASE_PATH\"), \n        database_uri: String::from(\"DB_URI\"),\n    }\n});

场景2: 使用全局变量共享信息，但是初始化以后还会修改。这就需要RwLock<T>登场。

use std::{collections::HashMap, sync::{LazyLock, RwLock}};\n\npub struct EnvGlobal {\n    pub base_path: String,\n    pub cache: HashMap<String, String>,\n}\n\nstatic ENV_GLOBAL: LazyLock<RwLock<EnvGlobal>> = LazyLock::new(|| {\n    let env = EnvGlobal { \n        base_path: String::from(\"SOME_PATH\"),\n        cache: HashMap::new(),\n    };\n    RwLock::new(env)    \n});\n\npub fn add_cache(key: String, value: String) {\n    let mut env = ENV_GLOBAL.write().unwrap();\n    env.cache.insert(key, value);\n}\n\npub fn read_cache(key: &str) -> Option<String> {\n    let env = ENV_GLOBAL.read().unwrap();\n    env.cache.get(key).map(|x| x.clone())\n}

场景3: 使用全局变量共享信息，初始化代码涉及到异步操作，且初始化以后还会修改。这是更复杂的需求，首先因为需要使用全局变量，我们想到要使用static声明全局生命周期的变量；其次，需要初始化，我们想到要使用OnceLock<T>；再次，因为初始化以后还要修改其内容，我们想到使用RwLock<T>；最后，还需要满足异步初始化的需求，这里有两个办法：一是使用tokio提供的OnceCell<T>，二是通过增加独立的初始化函数实现初始化。这里以第二种方法为例进行说明。

use polars::frame::DataFrame;\nuse std::sync::{OnceLock, RwLock};\nuse std::{env, sync::Arc};\nuse migration::sea_orm::{Database, DatabaseConnection};\n\n/// 全局环境变量声明\npub struct GlobalConfig {\n\n    /// 所有DataFrame的缓存，初始化为空，后续会修改\n    pub cache: Vec<DfCache>,\n\n    /// 数据库连接，初始化后就不会修改\n    pub mariadb: Arc<DatabaseConnection>,\n}\n\n/// 在内存中存储的一个DataFrame缓存\npub struct DfCache {\n    pub name: String,\n    pub updated_at: i32,\n    pub df: DataFrame,\n}\n\n/// 全局变量\n/// \n/// OnceLock表明变量只能被赋值一次\n/// Arc表明全局变量可以获得多个owned版本\n/// RwLock表明全局变量可以被修改、可被读取\nstatic GLOBAL_CONFIG: OnceLock<Arc<RwLock<GlobalConfig>>> = OnceLock::new();\n\nimpl GlobalConfig {\n    \n    /// 初始化全局变量\n    /// 在使用GlobalConfig前，务必调用GlobalConfig::init()方法，且该方法是async版本\n    pub async fn init() {\n        // 初始化时缺少必要的变量可以直接panic\n        let db = prepare().await.expect(\"Failed to prepare database connection\");\n        let config = GlobalConfig {\n            cache: Vec::new(),\n            mariadb: Arc::new(db),\n        };\n        let _ = GLOBAL_CONFIG.get_or_init(|| Arc::new(RwLock::new(config)));\n    }\n}

有了上面的基础，可以再添加一个辅助函数，用于获取数据库连接：

/// 全局变量辅助函数：获取数据库连接\npub fn get_mariadb() -> Arc<DatabaseConnection> {\n    GLOBAL_CONFIG\n        .get()\n        .expect(\"GLOBAL_CONFIG is not initialized\")\n        .read()\n        .expect(\"Cannot get read lock for GLOBAL_CONFIG\")\n        .mariadb\n        .clone()\n}

补充

为什么有些代码示例使用once_cell包？
Rust语言从1.70.0版本以后自带了std::cell::OnceOnceCell结构，在这之前因为标准库中没有OnceCell，所有一些代码示例中使用了once_cell第三方库。Rust标准库中关于Cell<T>以及相关结构的详细文档见这里。
为什么有些代码示例使用Arc<T>?
这要看代码的需求，使用Arc<T>可以解决两个问题：一是让函数签名中的生命周期修饰符更简单，二是在某些必须要own变量时，不得不使用Arc<T>封装。

// 这种方式没有使用Arc<T>\nstatic GLOBAL_CONFIG: OnceCell<GlobalConfig> = OnceCell::const_new();\n\n// 通过get()方法，我们能够获取到引用，且其生命周期为'static\nlet config: &'static GlobalConfig = GLOBAL_CONFIG.get().unwrap();\n\n// 这种方式使用了Arc<T>\nstatic GLOBAL_CONFIG: OnceCell<Arc<GlobalConfig>> = OnceCell::const_new();\n\n// 通过get()方法，我们能够获取到&Arc<GlobalConfig>，但是clone()方法就获得了Arc<GlobalConfig>\n// Arc<GlobalConfig>不需要生命周期修饰符，也可以方便地move到thread/task\nlet config: Arc<GlobalConfig> = GLOBAL_CONFIG.get().unwrap().clone();

什么时候需要组合使用Arc<T>和Mutex<T>、RwLock<T>？
使用Arc<T>，只能获取到T的引用，即&T，无法获取到&mut T，所以这是符合Rust语言规则的。但是，如果需要修改T的内容，就需要组合使用：Arc<Mutex<T>>或Arc<RwLock<T>>，依靠Mutex<T>和RwLock<T>的interior mutability机制，就可以对T的内容进行修改。不用担心会有多个owner同时修改内容导致冲突的情况，因为这正是Mutex<T>、RwLock<T>原语的提供的功能。

","user_id":1,"published":true,"created_at":1758847105856,"updated_at":1759025329485,"visits":0}