Rust 專業開發：自定義設定器 - Custom Allocators

在某些特殊場景下，我們可能需要自定義記憶體設定行為。以下是一些常見的使用情境：

嵌入式系統開發 - 這類別統通常記憶體極度受限或缺乏作業系統支援
效能關鍵型應用 - 需要最佳化憶體設定的應用，包括使用自定義堆積積理器如 jemalloc 或 TCMalloc
高安全需求應用 - 可能需要使用 mprotect() 和 mlock() 系統呼叫來保護記憶體頁面
跨語言整合 - 當與垃圾回收語言整合時，可能需要特殊設定器來避免記憶體洩漏
自定義記憶體追蹤 - 實作應用內的記憶體使用追蹤功能

預設情況下，Rust 使用標準系統實作進行記憶體設定，在大多數系統上就是系統 C 函式庫的 malloc() 和 free() 函式。這個行為由 Rust 的全域設定器 (global allocator) 實作。全域設定器可以使用 GlobalAlloc API 為整個 Rust 程式覆寫，而個別資料結構可以使用 Allocator API 的自定義設定器覆寫。

注意：撰寫本文時，Rust 的 Allocator API 仍是夜間版 (nightly-only) 特性。請參考 GitHub Issue #32838 瞭解此特性的最新狀態。不過 GlobalAlloc API 已可在穩定版 Rust 中使用。

即使你可能永遠不需要編寫自己的設定器（大多數人確實不需要），瞭解設定器介面仍有助於更好地理解 Rust 的記憶體管理。在實際應用中，除非在上述特殊情況下，否則你很少需要擔心設定器的問題。

編寫自定義設定器

讓我們探索如何編寫一個自定義的 Allocator，並將其用於 Vec。我們的設定器將簡單地呼叫 malloc() 和 free() 函式。首先，讓我們看 Rust 標準函式庫義的 Allocator 特徵：

pub unsafe trait Allocator {
    fn allocate(&self, layout: Layout)
        -> Result<NonNull<[u8]>, AllocError>;
    unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout);

    fn allocate_zeroed(
        &self,
        layout: Layout
    ) -> Result<NonNull<[u8]>, AllocError> { ... }
    unsafe fn grow(
        &self,
        ptr: NonNull<u8>,
        old_layout: Layout,
        new_layout: Layout
    ) -> Result<NonNull<[u8]>, AllocError> { ... }
    unsafe fn grow_zeroed(
        &self,
        ptr: NonNull<u8>,
        old_layout: Layout,
        new_layout: Layout
    ) -> Result<NonNull<[u8]>, AllocError> { ... }
    unsafe fn shrink(
        &self,
        ptr: NonNull<u8>,
        old_layout: Layout,
        new_layout: Layout
    ) -> Result<NonNull<[u8]>, AllocError> { ... }
    fn by_ref(&self) -> &Self { ... }
}

要實作設定器，我們只需提供兩個必須的方法：allocate() 和 deallocate()。這些方法與 C 語言中的 malloc() 和 free() 相對應。其他方法是選擇性的，用於進一步最佳化定行為：

必須方法：
- allocate() - 分配記憶體
- deallocate() - 釋放記憶體
選擇性方法（已提供預設實作）：
- allocate_zeroed() - 相當於 C 的 calloc()，分配並初始化為零的記憶體
- grow() 和 shrink() - 相當於 C 的 realloc()，調整已分配記憶體的大小
- grow_zeroed() - 擴大記憶體並將新部分初始化為零
- by_ref() - 回傳設定器的參照

你可能注意到一些方法標記為 unsafe。這是因為在 Rust 中，分配和釋放記憶體幾乎總是涉及不安全操作，所以這些方法被標記為 unsafe。

Allocator 特徵為選擇性方法提供了預設實作。例如，對於 grow 和 shrink 操作，預設實作會簡單地分配新記憶體、複製所有資料，然後釋放舊記憶體。對於 allocate_zeroed，預設實作會呼叫 allocate() 然後將所有記憶體位置寫入零。

讓我們開始編寫一個簡單的傳遞設定器，它將所有操作轉發給全域設定器：

#![feature(allocator_api)]

use std::alloc::{AllocError, Allocator, Global, Layout};
use std::ptr::NonNull;

pub struct PassThruAllocator;

unsafe impl Allocator for PassThruAllocator {
    fn allocate(&self, layout: Layout) -> Result<NonNull<[u8]>, AllocError> {
        Global.allocate(layout)
    }

    unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) {
        Global.deallocate(ptr, layout)
    }
}

在這個範例中，我們建立了一個名為 PassThruAllocator 的結構體，並為其實作 Allocator 特徵。這個設定器非常簡單，它只是將所有操作傳遞給 Rust 的全域設定器 Global：

allocate 方法直接呼叫 Global.allocate()
deallocate

掌控記憶體：Rust自訂設定器的實作與應用

記憶體管理一直是系統程式設計的核心挑戰之一。Rust憑藉其所有權模型和借用檢查機制，已經解決了許多常見的記憶體問題，但有時我們需要更精細地控制記憶體的分配方式。這就是Rust的自訂設定器（Custom Allocator）API發揮作用的地方。

在開發高效能或安全關鍵型應用程式時，自訂記憶體設定策略可能至關重要。本文將帶領讀者從基礎到進階，探索Rust中自訂設定器的實作與應用。

自訂設定器的基本概念與實作

Rust的標準函式庫了Allocator特性，允許我們實作自己的記憶體分配邏輯。讓我們先看一個最簡單的通透（pass-through）設定器實作：

#![feature(allocator_api)]
use std::alloc::{AllocError, Allocator, Layout};
use std::ptr::NonNull;

pub struct BasicAllocator;

unsafe impl Allocator for BasicAllocator {
    fn allocate(
        &self,
        layout: Layout,
    ) -> Result<NonNull<[u8]>, AllocError> {
        std::alloc::Global.allocate(layout)
    }

    unsafe fn deallocate(&self, ptr: NonNull<u8>, layout: Layout) {
        std::alloc::Global.deallocate(ptr, layout)
    }
}

這個簡單的設定器僅是呼叫Rust的全域設定器（Global Allocator）進行實際的記憶體分配和釋放。雖然功能上沒有增加任何新東西，但它展示了實作自訂設定器的最基本結構：

定義一個設定器結構體
為該結構體實作Allocator特性，這需要標記為unsafe
實作allocate方法來分配記憶體
實作deallocate方法來釋放記憶體

讓我們測試這個基本設定器：

fn main() {
    let mut custom_alloc_vec: Vec<i32, _> =
        Vec::with_capacity_in(10, BasicAllocator);
    for i in 0..10 {
        custom_alloc_vec.push(i as i32 + 1);
    }
    println!("custom_alloc_vec={:?}", custom_alloc_vec);
}

這段程式碼建立了一個使用我們自訂設定器的向量（Vec），初始容量為10個元素。然後，它填充了1到10的整數，最後列印出向量內容。執行結果應該是：

custom_alloc_vec=[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

這個例子表明我們的自訂設定器能夠正確工作。雖然它僅是呼叫了全域設定器，但這為我們進一步自訂分配邏輯奠定了基礎。

直接使用C函式庫的設定器

接下來，讓我們嘗試一個更實際的例子 - 直接使用C標準函式庫malloc()和free()`函式進行記憶體管理：

#![feature(allocator_api)]
use std::alloc::{AllocError, Allocator, Layout};
use std::ptr::NonNull;
use libc::{free, malloc};

pub struct BasicAllocator;

unsafe impl Allocator for BasicAllocator {
    fn allocate(
        &self,
        layout: Layout,
    ) -> Result<NonNull<[u8]>, AllocError> {
        unsafe {
            let ptr = malloc(layout.size() as libc::size_t);
            let slice = std::slice::from_raw_parts_mut(
                ptr as *mut u8,
                layout.size(),
            );
            Ok(NonNull::new_unchecked(slice))
        }
    }

    unsafe fn deallocate(&self, ptr: NonNull<u8>, _layout: Layout) {
        free(ptr.as_ptr() as *mut libc::c_void);
    }
}

這個版本的設定器直接使用C標準函式庫malloc()和free()`函式進行記憶體分配和釋放：

在allocate方法中：
- 呼叫malloc()分配指定大小的記憶體
- 使用from_raw_parts_mut()將C指標轉換為Rust切片
- 將切片包裝為NonNull類別並回傳
在deallocate方法中：
- 將Rust指標轉換為C指標
- 呼叫free()釋放記憶體

注意Layout結構體提供了兩個重要屬性：

size：指定要分配的最小位元組數
align：指定記憶體塊的最小位元組對齊要求（2的冪次方）

在這個例子中，我們只使用了size屬性，但在完整的生產環境設定器中，應該同時考慮size和align以確保可移植性。

理解`unsafe`的使用

在上面的例子中，你可能注意到unsafe關鍵字的使用方式有所不同：

deallocate()方法的簽名中包含unsafe
allocate()方法內部使用unsafe塊

這反映了不同級別的安全考慮：

deallocate()被標記為unsafe，因為如果使用無效資料（如錯誤的指標或佈局）呼叫它，會導致未定義行為
allocate()方法本身不是unsafe的，但其中涉及到指標操作，所以需要在方法內部使用unsafe塊

當我們處理原始指標和記憶體時，unsafe是不可避免的。Rust的設計哲學是將不安全程式碼離在明確標記的區域內，而不是完全禁止它。

進階應用：保護敏感記憶體

理解了基礎後，讓我們探索一個更進階的使用案例：為敏感資料（如密碼、加密金鑰）建立保護記憶體。

現代作業系統提供了多種記憶體保護功能，開發者可以利用這些功能提高系統安全性。在UNIX系統上，可以使用mprotect()和mlock()系統呼叫；在Windows上，則使用VirtualProtect()和VirtualLock()。

頁面對齊的保護記憶體設定器設計

讓我們來看一個為保護敏感資料而設計的記憶體設定器。這個設定器的特點是：

在目標記憶體區域前後各設定一個記憶體頁，作為"保險槓"
將這些保險槓區域標記為不可存取，防止意外或惡意的記憶體掃描
使用頁面對齊的記憶體分配，確保與作業系統的記憶體保護機制相容

當使用這個設定器時，記憶體佈局如下：

前端保護頁（不可存取）
目標記憶體區域（可讀寫）
後端保護頁（不可存取）

這種設計能有效防止某些類別的記憶體攻擊，特別是緩衝區溢位攻擊。

實作保護記憶體設定器

以下是這個進階設定器的allocate方法部分實作：

fn allocate(&self, layout: Layout,
) -> Result<ptr::NonNull<[u8]>, AllocError> {
    let pagesize = *PAGESIZE;
    let size = _page_round(layout.size(), pagesize) + 2 * pagesize;
    
    #[cfg(unix)]
    let out = {
        let mut out = ptr::null_mut();
        let ret = unsafe {
            libc::posix_memalign(&mut out, pagesize as usize, size)
        };
        if ret != 0 {
            return Err(AllocError);
        }
        out
    };
    
    #[cfg(windows)]
    let out = {
        use winapi::um::winnt::{MEM_COMMIT, MEM_RESERVE, PAGE_READWRITE};
        unsafe {
            winapi::um::memoryapi::VirtualAlloc(
                ptr::null_mut(), size, MEM_COMMIT | MEM_RESERVE,
                PAGE_READWRITE,
            )
        }
    };
    
    // 設定前端保護頁
    let fore_protected_region = unsafe {
        std::slice::from_raw_parts_mut(out as *mut u8, pagesize)
    };
    mprotect_noaccess(fore_protected_region)
        .map_err(|err| {
            eprintln!("mprotect error = {:?}, in allocator", err)
        })
        .ok();
    
    // 設定後端保護頁
    let aft_protected_region_offset =
        pagesize + _page_round(layout.size(), pagesize);
    let aft_protected_region = unsafe {
        std::slice::from_raw_parts_mut(
            out.add(aft_protected_region_offset) as *mut u8,
            pagesize,
        )
    };
    mprotect_noaccess(aft_protected_region)
        .map_err(|err| {
            eprintln!("mprotect error = {:?}, in allocator", err)
        })
        .ok();
    
    // 設定目標記憶體區域
    let slice = unsafe {
        std::slice::from_raw_parts_mut(
            out.add(pagesize) as *mut u8,
            layout.size(),
        )
    };
    mprotect_readwrite(slice)
        .map_err(|err| {
            eprintln!("mprotect error = {:?}, in allocator", err)
        })
        .ok();
    
    unsafe { Ok(ptr::NonNull::new_unchecked(slice)) }
}

這個allocate方法實作了頁面對齊的保護記憶體分配：

計算所需記憶體大小：
- 將請求的大小四捨五入到頁面大小
- 額外增加兩個頁面作為前後保護區
根據平台分配頁面對齊的記憶體：
- UNIX系統使用posix_memalign()
- Windows系統使用VirtualAlloc()
設定前端保護頁：
- 將第一個頁面標記為不可存取(no-access)
- 這防止了向下的記憶體掃描或溢位攻擊
設定後端保護頁：
- 將最後一個頁面標記為不可存取
- 這防止了向上的記憶體掃描或溢位攻擊
設定目標記憶體區域：
- 將中間區域標記為可讀寫
- 回傳這個區域的指標

這種機制提供了多層保護，使敏感資料不容易被未授權的程式碼存取或修改。

相應的deallocate方法也需要特殊處理：

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)
        .map_err(|err| eprintln!("mprotect error = {:?}", err))
        .ok();
    
    // 解鎖後端保護區
    let aft_protected_region_offset =
        pagesize + _page_round(layout.size(), pagesize);
    let aft_protected_region = std::slice::from_raw_parts_mut(
        ptr.add(aft_protected_region_offset) as *mut u8,
        pagesize,
    );
    mprotect_readwrite(aft_protected_region)
        .map_err(|err| eprintln!("mprotect error = {:?}", err))
        .ok();
    
    #[cfg(unix)]
    {
        libc::free(ptr as *mut libc::c_void);
    }
    
    #[cfg(windows)]
    {
        use winapi::shared::minwindef::LPVOID;
        use winapi::um::memoryapi::VirtualFree;
        use winapi::um::winnt::MEM_RELEASE;
        VirtualFree(ptr as LPVOID, 0, MEM_RELEASE);
    }
}

deallocate方法負責釋放之前分配的保護記憶體：

首先計算原始指標位置：
- 將指標向後偏移一個頁面大小，找到實際分配的記憶體起始位置
解鎖前端保護區：
- 將前端保護頁還原為可讀寫狀態
- 這是必要的，因為某些記憶體管理器可能需

Rust 條件編譯：針對不同平台客製化你的程式

在開發跨平台應用程式時，我們常需要針對不同作業系統或硬體架構提供不同的實作。Rust 提供了強大的條件編譯功能，使這一切變得簡單而優雅。與 C/C++ 中的 #ifdef 預處理指令相似，但 Rust 的條件編譯更加整合於語言本身，提供更好的語法和安全保證。

cfg 屬性：條件式包含程式碼

Rust 提供三種主要工具來實作條件編譯：

cfg 屬性：條件性包含後續程式碼
cfg_attr 屬性：根據現有條件設定新的編譯器屬性
cfg! 巨集：在編譯時回傳 true 或 false

讓我們透過一個實際例子來理解這些功能：

#[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");
    }
    
    if cfg!(not(any(target_arch = "x86", target_arch = "x86_64"))) {
        println!("This code is running on a non-Intel CPU");
    }
}

這段程式碼展示了 Rust 條件編譯的多種用法。首先，我們定義了兩個版本的 get_platform() 函式，分別針對 Unix 和 Windows 系統。編譯器會根據目標平台只保留其中一個實作。

在 main() 函式中，我們使用 cfg! 巨集進行編譯時條件檢查。這與 #[cfg()] 屬性不同，cfg! 巨集會在編譯時被求值為布林值，而非條件性包含程式碼。這讓我們可以在程式執行時根據編譯條件採取不同行動。

值得注意的是，Rust 提供了多種條件組合方式，如 not()、any() 和 all()。例如 not(any(target_arch = "x86", target_arch = "x86_64")) 檢查目標架構是否不是 x86 或 x86_64。

簡化的條件判斷

Rust 編譯器定義了一些簡便的條件判斷，例如 unix 和 windows。這意味著我們可以使用 #[cfg(unix)] 而非 #[cfg(target_family = "unix")]，讓程式碼更加簡潔。

要獲得你的目標 CPU 的所有設定值，可以執行：

rustc --print=cfg -C target-cpu=native

這個指令會輸出當前環境下所有可用的條件編譯選項，幫助你更精確地定義條件編譯規則。

條件編譯在開發自訂記憶體分配器時特別有用，因為不同作業系統處理記憶體分配的方式有所不同。在這種情況下，我們可以為每個平台提供專門的實作，並讓編譯器根據目標平台選擇正確的版本。

Rust 智慧指標全面解析

記憶體管理是任何程式語言中的核心挑戰，而 Rust 透過其獨特的所有權系統和智慧指標提供了優雅的解決方案。讓我們深入瞭解 Rust 中各種智慧指標和記憶體容器的特性與應用場景。

Box：單一物件的堆積積分配

Box 是 Rust 中最基本的智慧指標，它允許我們將單一物件分配在堆積積上：

fn main() {
    let boxed_value = Box::new(42);
    println!("Boxed value: {}", boxed_value);
}

這個簡單的例子建立了一個包含整數 42 的 Box。當我們需要將單一值儲存在堆積積上而不是使用容器（如 Vec）時，Box 是理想的選擇。Box 只能在單執行緒環境中使用，因為它不提供跨執行緒的分享功能。

Rc 與 Arc：分享所有權的智慧指標

當我們需要在多個地方分享資料的所有權時，可以使用 Rc（Reference Counted）或 Arc（Atomically Reference Counted）：

use std::rc::Rc;

fn main() {
    let shared_data = Rc::new(vec![1, 2, 3]);
    
    let reference1 = Rc::clone(&shared_data);
    let reference2 = Rc::clone(&shared_data);
    
    println!("Reference count: {}", Rc::strong_count(&shared_data));
    println!("First element via reference1: {}", reference1[0]);
    println!("Second element via reference2: {}", reference2[1]);
}

這段程式碼展示了 Rc 的基本用法。我們建立了一個包含向量的 Rc，然後複製了兩個參考。每次呼叫 Rc::clone() 都會增加參考計數，而不是複製底層資料。當所有參考超出範圍時，參考計數歸零，資料會被自動釋放。

Rc 適用於單執行緒環境，而 Arc 則是其多執行緒安全版本。Arc 使用原子操作來更新參考計數，使其可以安全地在執行緒間分享，但這也帶來了一些效能開銷。

Cell 與 RefCell：內部可變性的容器

Rust 的借用規則要求我們在擁有不可變參考時不能同時取得可變參考。但有時我們需要在外部不可變的結構內部修改資料，這就是「內部可變性」問題：

use std::cell::RefCell;

fn main() {
    let data = RefCell::new(vec![1, 2, 3]);
    
    // 借用可變參考並修改資料
    {
        let mut borrowed_data = data.borrow_mut();
        borrowed_data.push(4);
    }
    
    // 借用不可變參考並讀取資料
    {
        let borrowed_data = data.borrow();
        println!("Vector now contains: {:?}", *borrowed_data);
    }
}

這個例子使用 RefCell 提供內部可變性。RefCell 允許我們在執行時借用可變或不可變參考，如果違反了借用規則（例如同時擁有可變和不可變借用），會導致程式在執行時而非編譯時當機。

RefCell 提供兩個關鍵方法：borrow() 取得不可變參考，borrow_mut() 取得可變參考。注意我使用了作用域區塊來確保參考在需要時被釋放，避免借用規則衝突。

Cell 是另一種內部可變性容器，但它透過移動（而非參考）來實作內部可變性，適用於可複製的類別。

Mutex 與 RwLock：執行緒同步原語

在多執行緒環境中，我們需要確保資料的一致性和安全性：

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];
    
    for _ in 0..5 {
        let counter_clone = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter_clone.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }
    
    for handle in handles {
        handle.join().unwrap();
    }
    
    println!("Final count: {}", *counter.lock().unwrap());
}

這段程式碼展示瞭如何使用 Mutex 和 Arc 在多個執行緒間安全地分享和修改資料。我們建立了一個由 Arc 包裝的 Mutex，然後在五個執行緒中分享它。每個執行緒取得鎖，增加計數器，然後釋放鎖。

Mutex 確保在任何時刻只有一個執行緒可以存取資料，而 Arc 則確保 Mutex 本身可以安全地在執行緒間分享。lock() 方法回傳一個 MutexGuard，當它離開作用域時會自動釋放鎖。

RwLock 是 Mutex 的一個變體，它區分了讀取者和寫入者，允許多個讀取者同時存取資料，但寫入者必須獨佔存取。

智慧指標與容器的選擇

根據不同的使用場景和需求，我們應該選擇不同的智慧指標和記憶體容器。以下是一個簡單的選擇：

單執行緒環境中的選擇

單一物件堆積積分配：使用 Box
分享所有權：使用 Rc
內部可變性（使用移動）：使用 Cell
內部可變性（使用參考）：使用 RefCell

多執行緒環境中的選擇

分享所有權：使用 Arc
執行緒同步與內部可變性：使用 Mutex 或 RwLock

例如，當我需要在多個執行緒間分享可變資料時，我會使用 Arc<Mutex<T>>：

let shared_data = Arc::new(Mutex::new(Vec::new()));

這個組合確保了 Vec 可以安全地在執行緒間分享（透過 Arc）並安全地修改（透過 Mutex）。

Rust 記憶體管理的最佳實踐

在使用 Rust 的智慧指標和記憶體容器時，我發現以下實踐非常有用：

優先使用最簡單的解決方案：如果只需要堆積積上的單一物件，使用 Box 而非 Vec。
限制作用域：當使用 RefCell 或 Mutex 時，將借用或鎖的作用域限制得盡可能小，避免不必要的鎖定或借用衝突。
避免過度使用內部可變性：內部可變性是一種逃避 Rust 借用檢查器的方法，應該謹慎使用。通常，重構程式碼結構能夠避免使用內部可變性。
考慮效能影響：Arc 和 Mutex 等結構會帶來一定的效能開銷。在效能關鍵的路徑上，考慮使用其他策略，如訊息傳遞或更精細的鎖策略。
使用 Clone 特性進行深度複製：當需要複製複雜資料結構時，實作 Clone 特性可以提供深度複製功能。

單元測試的重要性

在 Rust 專案中，單元測試是確保程式碼品質和正確性的重要工具。Rust 內建了單元測試框架，使編寫和執行測試變得簡單。

雖然 Rust 的編譯器能夠捕捉許多錯誤，但單元測試仍然是驗證業務邏輯和檢測迴歸的關鍵。在測試中，我們可以驗證程式碼是否滿足需求，並在發布前捕捉潛在問題。

在下一篇文章中，我將探討 Rust 的單元測試框架及其獨特性，以及如何編寫有效的測試來提高程式碼品質。

Rust 的條件編譯和智慧指標系統為開發者提供了強大而靈活的工具，使我們能夠編寫高效、安全與可維護的程式碼。透過正確選擇和使用這些工具，我們可以解決各種複雜的記憶體管理挑戰，同時保持 Rust 的安全保證。隨著對這些概念的深入理解，你將能夠更有效地利用 Rust 的強大功能，開發出更好的軟體。

Rust的安全機制與如何避免破壞它

Rust語言以其安全性機制著稱，但開發者仍有方法可以突破這些保護機制。在開發過程中，瞭解這些潛在的安全漏洞並加以避免，對於寫出高品質的Rust程式至關重要。

兩種常見的安全性破壞方式

使用unsafe關鍵字

Rust的unsafe關鍵字允許我們執行一些編譯器無法驗證安全性的操作，例如：

解參照原始指標
呼叫unsafe函式
存取或修改可變靜態變數
實作unsafe trait

當使用unsafe時，開發者需自行確保記憶體安全，這增加了出錯的風險。

將編譯時錯誤轉換為執行時錯誤

這種情況通常發生在處理Option或Result類別時：

// 不安全的處理方式
let value = some_option.unwrap(); // 如果some_option為None，程式會當機

// 較安全的處理方式
match some_option {
    Some(value) => { /* 處理值 */ },
    None => { /* 處理錯誤情況 */ }
}

使用unwrap()而不處理失敗情況是一種常見的錯誤，特別是當開發者想要快速測試而不想花時間處理錯誤時。在某些情況下，這可能是預期行為，但在生產程式碼應盡量避免。

上述程式碼展示了兩種處理Option型別的方式。第一種使用unwrap()直接取出值，如果Option為None則會導致程式當機。第二種使用match表示式分別處理Some和None情況，這是更安全、更全面的做法。match方式強制開發者考慮所有可能的情況，避免了執行時的意外當機。

安全程式設計佳實踐

要避免上述問題，有幾個簡單但有效的策略：

處理所有可能的情況 - 當使用Option或Result時，確保處理所有可能的結果
避免使用會引起panic的函式 - 盡量避免在生產程式碼使用unwrap()等可能造成程式當機的函式
注意檔案警告 - Rust標準函式庫會在檔案中標註哪些函式可能會在失敗時panic
謹慎處理I/O和非確定性操作 - 這類別作隨時可能失敗，應適當處理它們的錯誤情況

值得注意的是，在Rust中，“panic"指的是引發錯誤並終止程式。如果需要主動引發panic，可以使用panic!()巨集另外，compile_error!()巨集以在編譯時引發錯誤。

// 引發執行時panic
panic!("發生了無法還原的錯誤");

// 引發編譯時錯誤
// compile_error!("這段程式碼不應該被編譯");

上面的程式碼展示瞭如何使用panic!()巨集動觸發程式當機。當程式執行到這一行時，會立即停止並顯示指定的錯誤訊息。而compile_error!()則更為嚴格，它會在編譯階段就阻止程式繼續構建。這兩種機制分別用於不同的情境：執行時的無法還原錯誤和編譯時的程式碼檢查。

如何寫出易於測試與正確的Rust程式

Rust編譯器能夠在程式碼布前捕捉許多錯誤，但它無法發現邏輯錯誤。例如，編譯器可以檢測某些除零錯誤，但無法告訴你是否誤用了除法而不是乘法。

優良函式設計的原則

要編寫既易於測試又不易出錯的軟體，最好的方法是將程式碼分解為小型計算單元（函式），這些函式通常應滿足以下特性：

盡可能無狀態 - 函式不應依賴或修改外部狀態
必須有狀態時應保持冪等性 - 同樣的操作重複執行，結果應該相同
盡可能確定性 - 對於給定的輸入集，函式的結果應始終相同
可能失敗的函式應回傳Result - 明確表示函式可能失敗
可能不回傳值的函式應回傳Option - 明確表示函式可能沒有結果

遵循第4和第5點可以讓你充分利用Rust的?運算元（當結果不是Ok時提前回傳錯誤的簡寫），這能大簡化錯誤處理程式碼

fn divide(a: i32, b: i32) -> Result<i32, String> {
    if b == 0 {
        return Err("除數不能為零".to_string());
    }
    Ok(a / b)
}

fn calculate_average(numbers: &[i32]) -> Result<f64, String> {
    if numbers.is_empty() {
        return Err("陣列不能為空".to_string());
    }
    
    let sum: i32 = numbers.iter().sum();
    let count = numbers.len() as i32;
    
    // 使用 ? 運算元簡化錯誤處理
    let result = divide(sum, count)?;
    
    Ok(result as f64)
}

這個例子展示瞭如何使用Result型別和?運算元簡化錯誤處理。divide函式回傳Result<i32, String>，表示它可能成功回傳一個整數，或失敗並回傳一個錯誤訊息。在calculate_average函式中，我們使用?運算元呼叫divide函式，如果divide回傳Err，則?運算元會立即從calculate_average回傳該錯誤；如果回傳Ok，?運算元會提取其中的值。這種模式使錯誤處理程式碼加簡潔和易讀。

使用expect()代替unwrap()

如果你希望在意外結果時引發panic，應使用expect()函式而不是unwrap()。expect()接受一個訊息作為引數，解釋為什麼程式發生了panic。這是unwrap()的安全替代品，其行為類別於assert!()。

// 不推薦：不清楚為什麼會panic
let value = some_result.unwrap();

// 推薦：清楚說明panic的原因
let value = some_result.expect("設定檔應該存在與有效");

上述程式碼比較了unwrap()和expect()的使用。雖然兩者都會在處理None或Err值時引發panic，但expect()允許開發者提供一個解釋性訊息，使得錯誤更容易理解和診斷。當程式當機時，這個訊息會顯示在錯誤輸出中，幫助開發者或維護者快速理解問題所在。在開發過程中，使用expect()比unwrap()更有助於程式碼維護。

玄貓

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