Modern C++ on kenji.blog

C++ 多執行緒程式設計入門與非同步處理（std::async）

Sat, 12 Sep 2026 08:00:00 +0900

現代的軟體開發中，為了最大限度地發揮多核心 CPU 的效能，多執行緒程式設計是不可或缺的。C++ 從 C++11 開始，將多執行緒及非同步處理的 API（<thread>, <mutex>, <condition_variable>, <future>）作為標準函式庫匯入，使得開發者不需要撰寫依賴平台的程式碼（如 POSIX 執行緒或 Windows API），就能實作可攜且安全的並行處理。此外，隨著 C++14、C++17、C++20 的持續版本更新，更加入了 std::scoped_lock 與 std::jthread 等更安全且進階的功能。

本文將從 C++ 多執行緒程式設計的基礎開始，深入解說防止資料競爭（Data Race）的同步機制，以及現代的非同步處理（std::async）與執行緒池（Thread Pool）的概念，並搭配詳細的程式碼範例進行徹底講解。

1. 並行處理的基礎與阿姆達爾定律 (Amdahl’s Law)

進行多執行緒化的最大目的是「提升效能」，但並非整個程式都能夠被平行化。這裡非常重要的是阿姆達爾定律 (Amdahl’s Law)。

阿姆達爾定律是一個預測模型，用來預測當程式的一部分被平行化、最佳化後，整體系統的效能能夠提升多少。

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

$S(N)$ : 理論上的最大加速比
$P$ : 整個程式中，可平行化部分的比例 (0 ≤ $P$ ≤ 1)
$N$ : 處理器（執行緒）的數量

這個公式揭示了一個重要的事實：「不論增加多少處理器數量 $N$，無法平行化的循序處理部分 $(1 - P)$ 將會成為瓶頸，因此加速是有上限的」。例如，即使程式有 $90\%$ 可以平行化（$P = 0.9$），只要剩下的 $10\%$ 是循序處理，那麼就算使用無限多的處理器，最多也只能加速 $10$ 倍（$S(\infty) = 1 / 0.1$）。

因此，在使用 C++ 進行多執行緒程式設計時，不能只是單純地增加執行緒，更需要盡可能減少循序處理部分（如鎖的競爭或同步的負擔等）的設計。

2. 執行緒的基礎：`std::thread` 與 `std::jthread` (C++20)

傳統的 `std::thread` (C++11)

C++11 匯入的 std::thread 是用來在新的執行緒中執行函式或 Lambda 運算式的最基礎類別。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <thread>

void workerFunction(int id) {
 std::cout << "Worker " << id << " is running on thread "
 << std::this_thread::get_id() << std::endl;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // 建立並開始執行執行緒
 std::thread t1(workerFunction, 1);

 // 使用 Lambda 運算式建立執行緒
 std::thread t2([](int id) {
 std::cout << "Lambda Worker " << id << " is running." << std::endl;
 }, 2);

 // 等待執行緒結束（join）
 t1.join();
 t2.join();

 std::cout << "All threads completed." << std::endl;
 return 0;
}

std::thread 需要注意的是，在被銷毀之前，必須呼叫 join() 或 detach()。如果兩者都未被呼叫，而 std::thread 的解構函式被執行，就會觸發 std::terminate()，導致程式崩潰。為了確保例外安全性（Exception Safety），過去我們需要自己實作使用 RAII 模式的包裝類別（Wrapper Class）。

現代的 `std::jthread` (C++20)

在 C++20 中，匯入了消除這些缺點的 std::jthread (joining thread)。std::jthread 會在解構函式中自動呼叫 join()，因此即使發生例外，也能夠安全地等待執行緒結束。此外，它還具備了透過 std::stop_token 協作取消執行緒的功能。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <iostream>
#include <thread>
#include <chrono>

int main() {
 // C++20: std::jthread
 // 透過第一個參數接收 std::stop_token 以偵測取消請求
 std::jthread jt([](std::stop_token stoken) {
 while (!stoken.stop_requested()) {
 std::cout << "Working..." << std::endl;
 std::this_thread::sleep_for(std::chrono::milliseconds(500));
 }
 std::cout << "Stop requested. Exiting thread." << std::endl;
 });

 std::this_thread::sleep_for(std::chrono::seconds(2));

 // 明確地請求取消
 jt.request_stop();

 // 由於 jthread 的解構函式會自動 join，因此不需要手動呼叫 join()
 return 0;
}

3. 避免資料競爭與同步：互斥鎖 (Mutex) 與鎖 (Lock)

當多個執行緒同時存取相同的記憶體區域（如變數），且至少有一個執行緒進行寫入時，就會發生資料競爭 (Data Race)。在 C++ 標準中，資料競爭會導致未定義行為 (Undefined Behavior)。為了防止這種情況，需要使用 std::mutex 進行互斥控制。

`std::mutex` 與 `std::lock_guard`

不建議手動呼叫原生的 std::mutex::lock() 與 unlock()，因為如果在發生例外時沒有呼叫到 unlock()，就會有導致死鎖 (Deadlock) 的風險。在 C++ 中，通常會使用基於 RAII 模式的 std::lock_guard (C++11) 或 std::scoped_lock (C++17)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


#include <iostream>
#include <vector>
#include <thread>
#include <mutex>

std::mutex g_mutex;
int g_counter = 0;

void incrementCounter(int iterations) {
 for (int i = 0; i < iterations; ++i) {
 // 離開作用域時會自動 unlock
 std::lock_guard<std::mutex> lock(g_mutex);
 ++g_counter;
 }
}

int main() {
 std::vector<std::thread> threads;
 for (int i = 0; i < 10; ++i) {
 threads.emplace_back(incrementCounter, 10000);
 }

 for (auto& t : threads) {
 t.join();
 }

 std::cout << "Final counter value: " << g_counter << std::endl;
 // 如預期會是 100000
 return 0;
}

`std::unique_lock`

std::lock_guard 是一種基於作用域的簡單鎖，但如果需要更靈活的控制（如延遲鎖定、帶有時間限制的鎖定、中途解鎖等），則可以使用 std::unique_lock。在接下來要講解的 std::condition_variable 中，必須使用 std::unique_lock。

4. 執行緒間的通訊：`std::condition_variable`

如果需要實作「生產者-消費者模式 (Producer-Consumer Pattern)」，也就是某個執行緒等待特定條件滿足，而另一個執行緒在滿足該條件時發送通知，可以使用 std::condition_variable。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>

std::mutex g_mtx;
std::condition_variable g_cv;
std::queue<int> g_dataQueue;
bool g_isFinished = false;

void producer() {
 for (int i = 1; i <= 5; ++i) {
 std::this_thread::sleep_for(std::chrono::milliseconds(200));
 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_dataQueue.push(i);
 std::cout << "Produced: " << i << std::endl;
 }
 g_cv.notify_one(); // 通知消費者
 }

 {
 std::lock_guard<std::mutex> lock(g_mtx);
 g_isFinished = true;
 }
 g_cv.notify_one(); // 通知結束
}

void consumer() {
 while (true) {
 std::unique_lock<std::mutex> lock(g_mtx);
 // 等待直到條件滿足（佇列不為空，或者已設定結束旗標）
 // 為了防止虛假喚醒 (Spurious Wakeup)，使用 Lambda 運算式指定條件
 g_cv.wait(lock, []{ return !g_dataQueue.empty() || g_isFinished; });

 while (!g_dataQueue.empty()) {
 int val = g_dataQueue.front();
 g_dataQueue.pop();
 // 解鎖並執行繁重的處理（這裡只有輸出）
 lock.unlock();
 std::cout << "Consumed: " << val << std::endl;
 lock.lock(); // 再次取得鎖
 }

 if (g_isFinished && g_dataQueue.empty()) {
 break;
 }
 }
}

int main() {
 std::thread t1(producer);
 std::thread t2(consumer);
 t1.join();
 t2.join();
 return 0;
}

在這個範例中，std::condition_variable::wait 會讓執行緒進入休眠狀態直到滿足條件，從而防止浪費 CPU 資源（忙碌迴圈, Busy Loop）。

5. 高度抽象的非同步處理：`std::future`, `std::promise`, `std::async`

到目前為止提到的 std::thread 與 std::mutex 雖然強大，但它們只是直接將作業系統底層的執行緒機制帶入 C++ 中，在處理取得結果或傳遞例外時，程式碼往往會變得繁雜。如果需要執行有回傳值的並行處理，或是更高階的非同步處理，可以使用 <future> 標頭檔的功能。

`std::promise` 與 `std::future`

std::promise 代表「設定」結果的一方，而 std::future 則代表「接收」結果的一方。它們作為執行緒之間安全傳遞結果或例外的通道來運作。

使用 `std::async` 的基於任務的並行處理

在 C++ 中，最推薦執行非同步任務的方法是使用 std::async。std::async 會非同步地執行任務，並回傳一個用來取得其結果的 std::future。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


#include <iostream>
#include <future>
#include <chrono>

int complexCalculation(int x) {
 std::cout << "Calculation started on thread: "
 << std::this_thread::get_id() << std::endl;
 std::this_thread::sleep_for(std::chrono::seconds(2));
 if (x < 0) {
 throw std::invalid_argument("x must be positive");
 }
 return x * 42;
}

int main() {
 std::cout << "Main thread id: " << std::this_thread::get_id() << std::endl;

 // 指定 std::launch::async 強制在另一個執行緒中執行
 std::future<int> resultFuture = std::async(std::launch::async, complexCalculation, 10);

 std::cout << "Main thread is doing other work..." << std::endl;

 try {
 // 呼叫 get() 時，將會阻塞目前的執行緒並等待，直到計算結束
 int result = resultFuture.get();
 std::cout << "Result: " << result << std::endl;
 } catch (const std::exception& e) {
 std::cerr << "Exception caught: " << e.what() << std::endl;
 }

 return 0;
}

std::async 的行為如下方循序圖所示。

sequenceDiagram participant Main as "主執行緒" participant Async as "std::async 工作執行緒" Main->>Async: "std::async(std::launch::async, ...)" activate Async Note over Main: "執行其他工作..." Main->>Async: "future.get() (阻塞直到準備就緒)" Note right of Async: "計算中..." Async-->>Main: "回傳結果或拋出例外" deactivate Async

std::async 的第一個參數為啟動原則 (Launch Policy)，主要有以下兩種：

std::launch::async: 一定會建立新的執行緒（或從執行緒池分配），並非同步地執行。
std::launch::deferred: 延遲評估 (Lazy Evaluation)。只有在呼叫 future.get() 或 future.wait() 時，才會在呼叫者的執行緒中同步執行。

如果使用預設值（未指定），則取決於實作，系統會根據負載狀況選擇其中一種。若想確保非同步執行，應明確指定 std::launch::async。

6. 執行緒池 (Thread Pool) 的概念

如果每次都呼叫 std::async，或是在迴圈中頻繁建立與銷毀 std::thread，執行緒的上下文切換 (Context Switch) 以及作業系統配置資源的負擔將變得不容忽視。特別是在處理大量細粒度任務 (Fine-grained tasks) 時，使用執行緒池 (Thread Pool) 是必不可少的。

執行緒池是一種架構：在應用程式啟動時預先建立一定數量的各個工作 (Worker) 執行緒，將任務累積在佇列 (Queue) 中，然後由閒置的工作執行緒依序取出並處理任務。

雖然在 C++ 標準函式庫中（截至 C++23）尚無標準的執行緒池類別，但只需組合 std::thread, std::mutex, std::condition_variable, std::function, std::packaged_task，就能在幾十行程式碼內實作一個高效率的執行緒池。在實際應用中，使用 Boost.Asio 的非同步 I/O 或第三方函式庫也是非常普遍的作法。

7. 關於效能與擴展性的考量

為了在多執行緒程式設計中發揮最佳效能，不僅要注意程式碼的平行化，還需要關注硬體的架構。

偽共享 (False Sharing): 即使多個執行緒更新的是不同的變數，但只要這些變數被配置在 CPU 的同一個快取行 (Cache Line, 通常為 64 bytes) 中，為了維持快取一致性 (Cache Coherency)，就會發生無謂的記憶體同步，導致效能大幅下降。為了防止這種情況，需要使用 alignas 標示符將變數對齊到快取行的邊界。
無鎖 (Lock-Free) 與 std::atomic: 為了避免互斥鎖的鎖定/解鎖負擔，可以考慮導入使用 <atomic> 的不可分割操作（如 Compare-And-Swap）或無鎖資料結構。不過，這需要對記憶體順序 (std::memory_order) 有正確的理解，且實作難度極高，因此通常只在經過謹慎的效能測量後，判斷為必要時才會引入。

8. 總結

本文從基礎到最新的 C++20 功能，解說了 C++ 中的多執行緒與非同步程式設計。重點如下：

基本上使用 std::async: 對於單次執行的非同步任務或是需要回傳值的並行處理，相較於手動管理執行緒，利用安全且方便的 std::async 與 std::future 是更好的選擇。
使用 std::jthread 進行執行緒管理: 對於長期在背景運作的執行緒，應使用 C++20 的 std::jthread 以保證安全的結束處理。
利用 RAII 進行同步: 為了防止資料競爭，互斥鎖的鎖定必定要透過 std::lock_guard 或 std::unique_lock 來進行。
注意額外負擔 (Overhead): 避免過度建立執行緒，必要時應引入執行緒池架構。

並行處理中的錯誤（死鎖、資料競爭）重現率低，屬於最難除錯的類型之一。隨時保持對執行緒安全性 (Thread Safety) 的意識，並選擇合適的標準函式庫工具，藉此實現由現代 C++ 打造的穩健且高速的系統開發吧。

防止記憶體外洩的智慧指標（std::unique_ptr / shared_ptr）活用術

Sat, 12 Sep 2026 07:00:00 +0900

在 C++ 中的記憶體管理，長年以來都是開發者面臨的最大挑戰之一。依賴手動使用 new 與 delete 的傳統記憶體管理風格，成為了引發記憶體外洩 (Memory Leak)、懸空指標 (Dangling Pointer)、雙重釋放 (Double Free) 等嚴重 Bug 的溫床。然而，隨著 Modern C++ (C++11 起) 的問世，情況發生了戲劇性的變化。其核心正是「智慧指標 (Smart Pointers)」。

本文將針對 std::unique_ptr、std::shared_ptr 以及 std::weak_ptr 這些能夠根除記憶體外洩並實現安全且高效率資源管理的強大工具，介紹其運作機制與進階活用術，並結合內部實作（控制區塊與原子操作）、對效能的影響、以及透過數學模型進行參照計數的公式化，進行極為詳細的解說。

1. 簡介：C++ 記憶體管理的黑暗時代與 Modern C++ 的黎明

在過去的 C++ 開發中，開發者必須親自負責釋放配置在堆積 (Heap) 上的記憶體。

1
2
3
4
5
6
7
8


void legacy_function() {
 int* ptr = new int(10);
 // ... 某些處理 ...
 if (some_condition) {
 return; // 發生記憶體外洩！delete 未被呼叫
 }
 delete ptr;
}

在上述的程式碼中，如果發生例外或是進行了提早回傳 (Early Return)，delete 將會被跳過，進而引發記憶體外洩。為了防止這種情況，便出現了「RAII (Resource Acquisition Is Initialization)」這個典範。RAII 是一種將資源的獲取綁定於物件的初始化 (建構子)，並將資源的釋放綁定於物件的銷毀 (解構子) 的手法。智慧指標就是將這種 RAII 慣用語應用於記憶體管理的標準函式庫類別。

2. `std::unique_ptr`：零開銷的獨佔所有權

std::unique_ptr 是一種對於動態配置物件擁有「獨佔所有權 (Exclusive Ownership)」的智慧指標。能夠擁有某項資源的 unique_ptr 永遠只有一個。

2.1 零開銷原則

std::unique_ptr 最大的魅力在於其效能。在未自訂刪除器 (Custom Deleter) 的預設狀態下，std::unique_ptr 的大小與原生指標 (Raw Pointer) 完全相同。它不具有任何不必要的成員變數，也沒有使用虛擬函式。透過編譯器最佳化，經由 std::unique_ptr 進行的存取將被展開成與原生指標同等的組合語言程式碼。

2.2 所有權的轉移與 `std::move`

由於擁有獨佔所有權，std::unique_ptr 無法被複製 (其複製建構子與複製指派運算子已被標記為 delete)。若要將所有權轉移給另一個 unique_ptr，必須使用 std::move 來利用移動語意 (Move Semantics)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


#include <iostream>
#include <memory>

class Resource {
public:
 Resource() { std::cout << "Resource acquired\n"; }
 ~Resource() { std::cout << "Resource destroyed\n"; }
 void do_something() { std::cout << "Doing something\n"; }
};

void process_resource(std::unique_ptr<Resource> ptr) {
 ptr->do_something();
 // 離開作用域時 ptr 會被銷毀，Resource 也會被釋放
}

int main() {
 std::unique_ptr<Resource> my_ptr = std::make_unique<Resource>();

 // process_resource(my_ptr); // 錯誤：無法複製
 process_resource(std::move(my_ptr)); // 轉移所有權

 if (!my_ptr) {
 std::cout << "my_ptr is now empty.\n";
 }
 return 0;
}

以下的 Mermaid 圖表展示了透過 std::move 轉移所有權的概念。

2.3 自訂刪除器的實作

當包裝 C 語言的舊式 API (例如 FILE* 或 Socket 等) 時，釋放記憶體時需要呼叫 delete 以外的函式 (如 fclose 等)。std::unique_ptr 可以在第二個樣板引數 (Template Argument) 中指定自訂刪除器 (Custom Deleter)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


#include <cstdio>
#include <memory>

// 用於自訂刪除器的仿函式 (Functor)
struct FileDeleter {
 void operator()(FILE* fp) const {
 if (fp) {
 std::cout << "Closing file.\n";
 std::fclose(fp);
 }
 }
};

using UniqueFile = std::unique_ptr<FILE, FileDeleter>;

int main() {
 UniqueFile file(std::fopen("test.txt", "w"));
 if (file) {
 std::fputs("Hello, Smart Pointers!", file.get());
 }
 // 離開作用域時會呼叫 FileDeleter 進行 fclose
 return 0;
}

若將函式指標或 Lambda 運算式作為自訂刪除器使用，可能會增加 unique_ptr 的大小；但如果像上述一樣使用無狀態的函式物件 (Functor)，受惠於 C++ 的 EBCO (Empty Base Class Optimization) 或 C++20 的 [[no_unique_address]]，其大小不會比原生指標增加 (保持零開銷)。

3. `std::shared_ptr`：共享所有權與控制區塊

std::shared_ptr 是一種讓多個指標共享並擁有同一個物件的智慧指標。當最後一個 shared_ptr 被銷毀時，其管理的物件就會被釋放。

3.1 內部架構：控制區塊

std::shared_ptr 除了指向被管理物件的指標外，還會在堆積上配置並共享一種被稱為 控制區塊 (Control Block) 的詮釋資料 (Metadata)。控制區塊包含以下資訊：

強參照計數 (Strong Count)：擁有該物件的 shared_ptr 數量。當此數量變為 0 時，物件就會被銷毀。
弱參照計數 (Weak Count)：正在監視該物件的 weak_ptr 數量。當強參照計數與弱參照計數雙雙變為 0 時，控制區塊本身就會被釋放。
自訂刪除器與配置器 (如果有被指定)。

因此，std::shared_ptr 物件本身的大小通常會是原生指標的 2 倍 (指向物件的指標，以及指向控制區塊的指標)。

3.2 效能與原子操作

控制區塊內的參照計數被實作為 原子操作 (Atomic Operations)，以確保在多執行緒環境下也能安全地增減。

在 x86/x64 架構中，參照計數的增減會使用如 lock xadd 之類的原子指令。與一般的整數加法相比，這會伴隨數十個週期 (Cycles) 的開銷。因此，如果以傳值 (By Value) 的方式將 shared_ptr 傳遞給函式，每次複製都會發生原子的遞增與遞減，進而降低效能。

最佳實務 (Best Practice)：將 shared_ptr 傳遞給函式時，除非需要共享所有權，否則應作為 const std::shared_ptr<T>& (常數參照) 來傳遞，或是傳遞原生指標/參照。

3.3 `std::make_shared` vs `new`

在建立 shared_ptr 時，應盡可能使用 std::make_shared。這有兩個重大的原因。

記憶體配置最佳化：若使用 new，會發生兩次堆積配置：一次用於物件本身，另一次用於控制區塊。若使用 std::make_shared，則能以一次堆積配置來保留包含兩者在內的一個大型記憶體區塊，並且也能提升快取效率。
例外安全性：在早於 C++17 的標準中，函式引數的評估順序是未規定的；如果在將 new 配置的指標傳給 shared_ptr 的建構子之前，其他引數的評估過程中發生了例外，就會有記憶體外洩的風險。make_shared 能夠完全避免這個問題。

1
2
3
4
5


// 應避免的寫法 (2 次記憶體配置)
std::shared_ptr<MyClass> ptr1(new MyClass());

// 推薦的寫法 (1 次記憶體配置)
std::shared_ptr<MyClass> ptr2 = std::make_shared<MyClass>();

4. `std::weak_ptr`：循環參照的解決與監視

共享所有權有著一個被稱為「循環參照 (Circular References)」的致命弱點。當物件 A 與物件 B 互相以 shared_ptr 指向對方時，各自的強參照計數最少都會維持在 1，直到程式結束為止都絕對不會變成 0，進而導致記憶體外洩。

graph TD subgraph "循環參照 (記憶體外洩)" A["物件 A"] -->|"shared_ptr (強參照=1)"| B["物件 B"] B -->|"shared_ptr (強參照=1)"| A end

4.1 透過 `std::weak_ptr` 打破循環

解決這個問題的就是 std::weak_ptr。weak_ptr 是由 shared_ptr 所建立並參照著該物件，但不會增加強參照計數。取而代之的是增加弱參照計數。藉由這種方式，可以在不擁有所有權的情況下「監視」物件。

graph TD subgraph "打破循環參照" C["物件 A"] -->|"shared_ptr (強參照=1)"| D["物件 B"] D -.->|"weak_ptr (弱參照=1)"| C end

4.2 透過 `lock()` 方法進行安全存取

weak_ptr 並不具備直接存取物件的運算子 (-> 或 *)。這是因為目標物件有可能已經被銷毀了。為了安全地進行存取，必須呼叫 lock() 方法來暫時取得一個 shared_ptr。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


#include <iostream>
#include <memory>

class Node {
public:
 std::string name;
 std::shared_ptr<Node> next;
 std::weak_ptr<Node> prev; // 使用 weak_ptr 以防止循環參照

 Node(const std::string& n) : name(n) { std::cout << "Created " << name << "\n"; }
 ~Node() { std::cout << "Destroyed " << name << "\n"; }
};

int main() {
 auto nodeA = std::make_shared<Node>("A");
 auto nodeB = std::make_shared<Node>("B");

 nodeA->next = nodeB;
 nodeB->prev = nodeA;

 // 從 weak_ptr 取得 shared_ptr 來進行存取
 if (auto locked_prev = nodeB->prev.lock()) {
 std::cout << "Node B's prev is " << locked_prev->name << "\n";
 } else {
 std::cout << "Node B's prev is already destroyed.\n";
 }

 return 0; // nodeA 與 nodeB 都會被適當地銷毀
}

5. 多執行緒環境下的共享所有權限制

關於 shared_ptr 的執行緒安全性 (Thread Safety) 很容易被誤解：「控制區塊內參照計數的更新是執行緒安全的」，但是「shared_ptr 物件本身的讀寫並非執行緒安全」。

安全的操作：多個執行緒讀寫 各自獨立的 shared_ptr 實例 (但共享同一個控制區塊)。
資料競爭 (危險)：多個執行緒同時讀寫 完全相同的 shared_ptr 實例。

如果必須在多個執行緒之間共享同一個實例，則需要使用 std::atomic<std::shared_ptr<T>> (C++20)，或是使用互斥鎖 (std::mutex) 進行保護。

6. 參照計數的數學公式化

將控制區塊中生命週期的狀態轉換以數學方式表示如下：假設時間 $t$ 時的強參照計數為 $S(t)$，弱參照計數為 $W(t)$。

初始狀態 (make_shared 剛執行完後)：

$$ S(0) = 1, \quad W(0) = 0 $$

當進行複製 (shared_ptr 的複製) 時：

$$ S(t_{next}) = S(t) + 1 $$

被管理的物件 (Managed Object) 被銷毀的條件：

$$ \lim_{t \to t_d} S(t) = 0 $$

控制區塊 (Control Block) 本身從記憶體中被釋放的條件：

$$ S(t) = 0 \quad \land \quad W(t) = 0 $$

也就是說，

$$ S(t) + W(t) = 0 $$

正如這個數學式所顯示的，只要 weak_ptr 繼續存在 ($W(t) > 0$)，即使被管理的物件已經被銷毀，用於控制區塊的微小記憶體空間仍會持續保留。這在某些情況下會成為 make_shared 唯一的缺點 (由於被管理物件的記憶體與控制區塊是一體化的，如果有弱參照殘留，那麼用於被管理物件的龐大記憶體空間也不會歸還給系統)，但通常 make_shared 在效能上的優勢會帶來壓倒性的好處。

7. 結論

在 Modern C++ 中的記憶體管理，已經不再是手動管理 new/delete 的時代了。

預設情況下應總是使用 std::unique_ptr，在享受零開銷恩惠的同時，將明確的所有權納入設計之中。
只有在真正需要於多個擁有者之間共享生命週期時，才使用 std::shared_ptr，並且使用 std::make_shared 來建立。
在可能會發生共享循環 (循環參照) 的資料結構，或是在實作觀察者模式 (Observer Pattern) 時，活用 std::weak_ptr 來防範記憶體外洩於未然。

深入理解智慧指標並在適當的地方活用它們，將能在完全不犧牲 C++ 效能的情況下，建構出安全且堅固的軟體架構。

Modern C++ on kenji.blog

C++ 多執行緒程式設計入門與非同步處理（std::async）

1. 並行處理的基礎與阿姆達爾定律 (Amdahl’s Law)

2. 執行緒的基礎：std::thread 與 std::jthread (C++20)

傳統的 std::thread (C++11)

現代的 std::jthread (C++20)

3. 避免資料競爭與同步：互斥鎖 (Mutex) 與鎖 (Lock)

std::mutex 與 std::lock_guard

std::unique_lock

4. 執行緒間的通訊：std::condition_variable

5. 高度抽象的非同步處理：std::future, std::promise, std::async

std::promise 與 std::future

使用 std::async 的基於任務的並行處理