Rust跨平台DLL全局可变哈希表静态字符串键被释放问题

问题核心原因 #

你遇到的现象本质是错误地将外部管理的字符串标注为&'static str，导致悬垂引用：

• 在跨语言调用场景（比如Python调用Rust DLL）中，传入的字符串内存由调用者（Python解释器）掌控，而非Rust的静态内存区域。即便你在Rust代码里把它声明为&'static str，这只是类型标注，无法改变内存的实际所有者和生命周期——Python会在自身内存管理逻辑触发时回收或复用这块内存，就会出现键被重置为\0、被其他内容覆盖的情况。
• 独立可执行程序中，字符串通常来自Rust自身的静态内存（如字面量）或程序可控的内存区域，不会被外部 runtime 随意回收，因此无此问题。
• 全局可变哈希表本身不是问题，但存储指向外部管理内存的引用，必然会引发悬垂引用风险。

正确解决方法 #

要确保哈希表中字符串的内存由Rust自主管理，有两种可靠方案：

1. 复制字符串到Rust堆内存 #

将传入的C风格字符串转换为String存储，让Rust负责内存生命周期：

use std::collections::HashMap;
use std::sync::Mutex;
use std::ffi::CStr;

// 全局哈希表，用String存储键值（Rust管理内存）
static GLOBAL_MAP: Mutex<HashMap<String, String>> = Mutex::new(HashMap::new());

#[no_mangle]
pub extern "C" fn add_key_value(key: *const u8, value: *const u8) {
    // 安全转换C字符串为Rust String
    let key_str = unsafe {
        assert!(!key.is_null());
        CStr::from_ptr(key as *const i8).to_str().unwrap().to_string()
    };
    let value_str = unsafe {
        assert!(!value.is_null());
        CStr::from_ptr(value as *const i8).to_str().unwrap().to_string()
    };

    GLOBAL_MAP.lock().unwrap().insert(key_str, value_str);
}

2. 使用Rust静态字符串（仅适用于固定已知键） #

如果键是编译期确定的固定字符串，直接用Rust字符串字面量（真正的'static生命周期）：

use std::collections::HashMap;
use std::sync::Mutex;

static GLOBAL_MAP: Mutex<HashMap<&'static str, &'static str>> = Mutex::new(HashMap::new());

// 初始化时插入静态键值对
#[ctor::ctor]
fn init() {
    GLOBAL_MAP.lock().unwrap().insert("INIT_KEY", "INIT_VALUE");
}

这类字符串会被编译到DLL的静态内存区域，直到进程结束才会释放，不会被外部覆盖。

额外注意事项 #

• 跨语言调用必须严格遵循谁分配谁释放的内存规则，避免悬垂引用。
• 全局可变状态必须用同步原语（如Mutex）保护，防止多线程竞争引发的未定义行为。
• 转换C风格字符串时，要确保输入是合法UTF-8且以\0结尾，避免触发未定义行为。

内容的提问来源于stack exchange，提问作者MauriceLambert