Rust自訂分配器與條件編譯實務

– 10 分鐘閱讀

在系統程式設計中，精細的記憶體控制至關重要。Rust 提供了自訂分配器，允許開發者掌控記憶體分配與釋放策略。搭配條件編譯，更能針對不同平台撰寫最佳化程式碼。本文將以 mprotect 系統呼叫為例，示範如何實作跨平台的自訂分配器，並探討 Rust 的條件編譯機制、單元測試框架與 Proptest 屬性測試函式庫的應用，以及如何有效地處理泛型函式和平行測試。藉由理解這些技術，開發者能更有效率地撰寫高效能且穩定的 Rust 程式碼。 透過結合單元測試和屬性測試，更能確保程式碼品質，並提升軟體的可靠性。

自訂分配器（Custom Allocators）與條件編譯（Conditional Compilation）

在 Rust 程式語言中，記憶體管理是十分重要的議題。自訂分配器允許開發者控制記憶體的分配與釋放，而條件編譯則使程式碼能夠根據不同的編譯目標進行調整。

自訂分配器的實作

以下是一個自訂分配器的範例，展示瞭如何使用 mprotect 系統呼叫來控制記憶體存取許可權。

組態記憶體

let pagesize = *PAGESIZE;
let layout = Layout::from_size_align(layout.size() + pagesize * 3, pagesize).unwrap();
let out = unsafe {
    #[cfg(unix)]
    {
        libc::malloc(layout.size()) as *mut u8
    }
    #[cfg(windows)]
    {
        winapi::um::memoryapi::VirtualAlloc(
            std::ptr::null_mut(),
            layout.size(),
            winapi::um::winnt::MEM_COMMIT | winapi::um::winnt::MEM_RESERVE,
            winapi::um::winnt::PAGE_READWRITE,
        ) as *mut u8
    }
};
// ...
let slice = unsafe {
    std::slice::from_raw_parts_mut(
        out.add(pagesize) as *mut u8,
        layout.size(),
    )
};
mprotect_readwrite(slice).ok();
unsafe { Ok(ptr::NonNull::new_unchecked(slice.as_mut_ptr())) }

釋放記憶體

unsafe fn deallocate(&self, ptr: ptr::NonNull<u8>, layout: Layout) {
    let pagesize = *PAGESIZE;
    let ptr = ptr.as_ptr().offset(-(pagesize as isize));
    // 解鎖前後保護區域
    let fore_protected_region = std::slice::from_raw_parts_mut(ptr as *mut u8, pagesize);
    mprotect_readwrite(fore_protected_region).ok();
    // ...
    #[cfg(unix)]
    {
        libc::free(ptr as *mut libc::c_void);
    }
    #[cfg(windows)]
    {
        VirtualFree(ptr as LPVOID, 0, MEM_RELEASE);
    }
}

內容解密：

  1. mprotect 系統呼叫的使用：在組態記憶體時，使用 mprotect 將記憶體區域標記為唯讀或可讀寫，以控制存取許可權。
  2. 條件編譯的應用：使用 #[cfg(unix)] 和 #[cfg(windows)] 來區分不同作業系統下的記憶體管理實作。
  3. 記憶體保護區域的設定：在分配的記憶體前後設定保護區域，以防止無效的記憶體存取。

條件編譯

Rust 提供了多種方式來進行條件編譯，包括 cfg 屬性、cfg_attr 屬性和 cfg! 巨集。

使用範例

#[cfg(target_family = "unix")]
fn get_platform() -> String {
    "UNIX".into()
}

#[cfg(target_family = "windows")]
fn get_platform() -> String {
    "Windows".into()
}

fn main() {
    println!("This code is running on a {} family OS", get_platform());
    if cfg!(target_feature = "avx2") {
        println!("avx2 is enabled");
    } else {
        println!("avx2 is not enabled");
    }
}

內容解密：

  1. cfg 屬性的使用：根據目標平台的不同，編譯不同的函式實作。
  2. cfg! 巨集的使用：在執行時期檢查特定的編譯組態，例如目標平台是否支援某個 CPU 特性。
內容解密：
  1. 智慧指標的選擇：根據具體需求選擇適當的智慧指標或容器型別。
  2. 記憶體管理的靈活性：Rust 的智慧指標和容器提供了靈活的記憶體管理方式。

第 5 章：使用記憶體的智慧指標與容器

第三部分：正確性

寫出好的軟體很困難，而且困難在很多方面。我們經常聽到關於簡單性的重要性，但我們很少聽到簡單性的兄弟：正確性。寫出簡單的程式碼是一個值得讚賞的目標，但如果沒有正確性，即使是世界上最美麗和簡單的程式碼仍然可能是錯誤的。我們傾向於將複雜性隱藏在抽象背後，但複雜性無處不在，即使被隱藏，所以我們必須確保保持正確性。

正確性的重要性

正確性既是質性的，也是量化的。程式碼是否正確取決於 API 的規範程度以及 API 的定義和實作是否比對。例如，我可以寫一個接受兩個引數並傳回它們的和的加法函式，但它也應該正確處理邊緣情況，如溢位、有符號性、錯誤輸入等。為了使我們的加法函式正確處理這些情況，它們需要被明確規定。未指定的行為是正確性的敵人。

在接下來的章節中，我們將討論保證程式碼正確性的測試策略。透過為程式碼編寫測試，你也可以透過發現歧義來揭示規範中的弱點，除了驗證實作的正確性。

第 6 章：單元測試

單元測試是提高程式碼品質的一種方法，因為它可以在發布前捕捉迴歸並確保程式碼符合需求。Rust 包含了一個內建的單元測試框架，使你的工作更輕鬆。在本章中，我們將回顧 Rust 提供的一些功能，並討論 Rust 的單元測試框架的一些缺陷——以及如何克服它們。

Rust 中的測試有何不同

在探討 Rust 的單元測試功能之前，我們應該討論 Rust 和其他語言之間的差異，以及它們與單元測試的關係。對於來自 Haskell 或 Scala 等語言的人來說，你可能會發現 Rust 在測試方面的特性與它們相似。然而，與大多數語言相比，Rust 有很大的不同，因為你在其他語言中看到的單元測試型別在 Rust 中並不必要。

具體來說，在 Rust 中，有很多情況下，只要程式碼能夠編譯，程式碼就必須是正確的。換句話說，Rust 編譯器可以被視為一個始終應用於程式碼的自動測試套件。這只對某些型別的測試成立，並且有多種方法可以在 Rust 中破壞這個契約。

破壞 Rust 安全保證的兩種最常見方式

  1. 使用 unsafe 關鍵字
  2. 將編譯時錯誤轉換為執行時錯誤

後者可以透過多種方式發生，但最常見的是透過使用 Option 或 Result 而不正確處理兩種結果情況。特別是，這種錯誤可以透過在這些型別上呼叫 unwrap() 而不處理失敗情況來實作。在某些情況下，這是期望的行為，但這也是人們經常犯的錯誤，僅僅因為他們不想花時間處理錯誤。為了避免這些問題，簡單的解決方案是處理所有情況並避免呼叫在執行時會 panic 的函式（如 unwrap()）。Rust 不提供驗證程式碼是否無 panic 的方法。

在 Rust 的標準函式庫中，在失敗時會 panic 的函式和方法通常在檔案中被註明。一般來說，對於任何型別的程式設計，任何執行 I/O 或非確定性操作的函式都可能在任何時候失敗（或 panic），並且應該適當地處理這些失敗情況（除非當然，正確處理失敗的方法是 panic）。

如何寫出既容易測試又不太可能出錯的軟體

作為一個規則，寫出既容易測試又不太可能出錯的軟體的最佳方法是將程式碼分解為小的計算單元（函式），這些單元通常滿足以下屬性：

  1. 函式應該盡可能無狀態。
  2. 在函式必須有狀態的情況下，函式應該是冪等的。
// 示例：一個簡單的加法函式
fn add(a: i32, b: i32) -> i32 {
    a + b
}

#### 內容解密：
此範例展示了一個簡單的加法函式 `add`，它接受兩個 `i32` 引數並傳回它們的和。這個函式是無狀態且冪等的，因此它很容易被測試。

// 示例：一個具有內部可變性的結構
use std::cell::RefCell;

struct Counter {
    count: RefCell<i32>,
}

impl Counter {
    fn new() -> Self {
        Counter {
            count: RefCell::new(0),
        }
    }

    fn increment(&self) {
        *self.count.borrow_mut() += 1;
    }

    fn get_count(&self) -> i32 {
        *self.count.borrow()
    }
}

#### 內容解密：
此範例展示了一個具有內部可變性的 `Counter` 結構，它使用 `RefCell` 來實作內部可變性。`increment` 方法增加計數，而 `get_count` 方法傳回當前計數。這種設計允許在不可變的 `Counter` 例項上進行可變操作。

```plantuml
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Rust自訂分配器與條件編譯實務

package "Rust 記憶體管理" {
    package "所有權系統" {
        component [Owner] as owner
        component [Borrower &T] as borrow
        component [Mutable &mut T] as mutborrow
    }

    package "生命週期" {
        component [Lifetime 'a] as lifetime
        component [Static 'static] as static_lt
    }

    package "智慧指標" {
        component [Box<T>] as box
        component [Rc<T>] as rc
        component [Arc<T>] as arc
        component [RefCell<T>] as refcell
    }
}

package "記憶體區域" {
    component [Stack] as stack
    component [Heap] as heap
}

owner --> borrow : 不可變借用
owner --> mutborrow : 可變借用
owner --> lifetime : 生命週期標註
box --> heap : 堆積分配
rc --> heap : 引用計數
arc --> heap : 原子引用計數
stack --> owner : 棧上分配

note right of owner
  每個值只有一個所有者
  所有者離開作用域時值被釋放
end note

@enduml
```rust
pub fn add<T: std::ops::Add<Output = T>>(a: T, b: T) -> T {
    a + b
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_add() {
        assert_eq!(add(2, 2), 4);
    }
}

程式碼說明

上述範例中，add 函式是一個泛型函式，接受兩個相同型別的引數並傳回相同型別的結果。型別 T 需要實作 std::ops::Add 特性。

內容解密：

  1. add 函式的泛型實作：此函式使用泛型型別 T，並要求 T 實作 std::ops::Add 特性，以確保可以對 T 型別的值進行加法運算。
  2. #[cfg(test)] 屬性：此屬性告訴編譯器，只有在執行測試時才編譯 tests 模組中的程式碼。
  3. use super::*;：這行程式碼將父模組中的所有公開專案引入當前作用域，方便在測試中使用被測試的函式。
  4. #[test] 屬性：此屬性標記一個函式為測試函式，使其能夠被 cargo test 命令執行。
  5. assert_eq! 巨集：此巨集用於檢查兩個表示式是否相等，如果不相等，則測試失敗並輸出錯誤訊息。

測試框架的探討與應用

在Rust程式語言中，單元測試是確保程式碼品質的重要環節。雖然Rust內建的單元測試功能已經相當完善，但仍有一些進階功能需要藉助外部函式庫來實作。本章節將探討Rust中測試框架的使用，以及如何利用外部函式庫來增強測試功能。

屬性測試（Property Testing）與Proptest函式庫

屬性測試是一種透過自動生成隨機測試資料來驗證程式碼正確性的測試方法。Proptest是Rust中一個實作屬性測試的函式庫，它提供了類別似於Haskell中QuickCheck的功能。Proptest可以自動生成測試資料，並找出可能導致程式碼錯誤的最小測試案例。

使用Proptest進行屬性測試

以下是一個使用Proptest進行屬性測試的範例：

use proptest::prelude::*;

proptest! {
    #[test]
    fn test_add(a: i64, b: i64) {
        assert_eq!(add(a, b), a + b);
    }
}

在這個範例中，proptest!巨集會自動生成隨機的a和b值，並執行test_add函式。如果add函式的實作有誤，Proptest會報告錯誤並提供最小的失敗測試案例。

解決算術溢位問題

在前面的範例中，我們遇到了算術溢位的問題。Rust在偵錯模式下預設使用檢查算術（checked arithmetic），而在發行模式下則使用未檢查算術（unchecked arithmetic）。這可能會導致在偵錯模式下正確執行的程式碼，在發行模式下出現錯誤。

使用WrappingAdd特性解決溢位問題

為瞭解決這個問題，我們可以使用num_traits函式庫提供的WrappingAdd特性。這個特性提供了包裝算術（wrapping arithmetic）的功能，可以避免算術溢位。

extern crate num_traits;
use num_traits::ops::wrapping::WrappingAdd;

pub fn add<T: WrappingAdd<Output = T>>(a: T, b: T) -> T {
    a.wrapping_add(b)
}

程式碼解密：

  1. extern crate num_traits;：引入num_traits外部函式庫。
  2. use num_traits::ops::wrapping::WrappingAdd;：引入WrappingAdd特性。
  3. pub fn add<T: WrappingAdd<Output = T>>(a: T, b: T) -> T：定義一個泛型函式add，它接受兩個引數a和b，並傳回它們的和。這個函式使用了WrappingAdd特性來避免算術溢位。
  4. a.wrapping_add(b)：使用wrapping_add方法來計算a和b的和，並傳回結果。

Rust 單元測試深入解析

在 Rust 開發中，單元測試是確保程式碼品質的關鍵步驟。本章節將探討 Rust 單元測試的實務應用，特別是在處理泛型函式和平行測試時的特殊考量。

使用 Proptest 進行屬性測試

屬性測試（Property-based testing）是一種進階測試技術，能夠自動生成多組輸入資料來驗證程式碼的正確性。以下是一個使用 proptest 進行屬性測試的範例：

use proptest::prelude::*;

proptest! {
    #[test]
    fn test_add(a: i64, b: i64) {
        assert_eq!(add(a, b), a.wrapping_add(b));
    }
}

內容解密：

  1. proptest!巨集用於定義屬性測試
  2. a: i64和b: i64會自動生成多組不同的輸入值
  3. assert_eq!用於驗證add函式的實作是否正確
  4. wrapping_add方法確保加法運算在溢位時能正確處理

這個測試會自動執行數百次，每次使用不同的輸入值，大大提高了測試的覆寫率。

為什麼編譯器比你更瞭解該測試什麼

Rust 是一門靜態型別語言，這帶來了許多測試上的優勢。編譯器會在編譯階段檢查型別正確性，因此我們不需要編寫測試來驗證這些內容。

主要優點包括：

  • 無需測試型別相關的錯誤
  • 無需擔心執行階段的型別混淆問題
  • 編譯器會檢查參照的有效性

在 Rust 中，我們主要需要測試的是業務邏輯而非型別相關的內容。正確使用型別系統可以減少許多潛在錯誤。

處理平行測試和全域狀態

當 Cargo 執行單元測試時，會預設使用平行方式執行以提高效率。這可能導致在處理全域狀態或測試固定裝置（fixtures）時出現問題。

Rust 提供了幾種解決方案：

  1. 使用lazy_static套件建立全域靜態變數
  2. 自定義main()函式（較不建議）

建議使用lazy_static來簡化全域狀態的管理：

use lazy_static::lazy_static;

lazy_static! {
    static ref GLOBAL_STATE: Mutex<i32> = Mutex::new(0);
}

內容解密：

  1. lazy_static!巨集用於定義延遲初始化的靜態變數
  2. Mutex用於確保執行緒安全
  3. 靜態變數在第一次存取時才會初始化

這種做法可以有效解決平行測試中的全域狀態管理問題。

最佳實踐建議

  1. 有效利用 Rust 的型別系統來減少錯誤
  2. 避免過度使用Option、unwrap()或unsafe程式碼
  3. 正確處理 I/O 操作的結果型別
  4. 使用屬性測試來提高測試覆寫率

遵循這些最佳實踐，可以讓你的 Rust 程式碼更健壯、更容易維護。透過結合單元測試和屬性測試，可以全面提升程式碼的品質。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。