创建线程时触发Segmentation fault，基于std::thread的线程池代码求助

Hey there! Let's break down why you're hitting a segmentation fault when creating threads for your 5-thread pool. Segfaults in thread setups almost always boil down to invalid memory access—let's go through the most likely culprits and how to fix them.

Common Causes of Segfaults in Thread Pool Creation #

1. Invalid Reference Capture in Thread Lambdas/Callbacks #

This is the #1 issue I see with beginner thread pool code. If your worker threads capture local variables (like your task queue, mutex, or done flag) by reference, and those variables go out of scope before the threads finish running, you'll end up with dangling references.

For example, if you create all your shared resources (queue, mutex, cv) inside main() and capture them by reference in your thread lambdas, once main() exits (or even just the block where those variables are declared), the memory is freed. Your threads will still try to access that invalid memory, triggering a segfault.

2. Uninitialized Shared Resources #

If your task queue, mutex, condition variable, or done flag isn't fully initialized before threads start accessing them, you'll get undefined behavior (which often manifests as a segfault). For instance, if you declare a pointer to a mutex but forget to allocate it with new, or if you try to use a condition variable that hasn't been constructed yet.

3. Non-Atomic done Flag #

If your done flag is a plain bool instead of std::atomic<bool>, you have a data race on your hands. The main thread might write to done while worker threads are reading it, leading to undefined behavior—including segfaults.

How to Diagnose Your Specific Issue #

First, look closely at your stack trace:

• Which function is at the top of the stack? If it's inside your worker thread's code when accessing the queue, mutex, or done flag, that's a huge clue.
• Check if the variable being accessed is a reference or pointer—if so, verify that the original object is still alive when the thread runs.

Fix Example: Properly Encapsulated Thread Pool #

Here's a corrected implementation that avoids these pitfalls by encapsulating all shared resources in a class, ensuring their lifecycle matches the thread pool's, and using safe thread setup:

#include <iostream>
#include <queue>
#include <mutex>
#include <condition_variable>
#include <thread>
#include <vector>
#include <atomic>
#include <stdexcept>
#include <string>

class ThreadPool {
private:
    std::queue<int> task_queue;
    std::mutex queue_mutex;
    std::condition_variable cv;
    std::atomic<bool> stop_flag{false};
    std::vector<std::thread> workers;

    // Worker thread function
    void worker_loop() {
        while (!stop_flag) {
            std::unique_lock<std::mutex> lock(queue_mutex);
            // Wait until there's a task or we're told to stop
            cv.wait(lock, [this]() { return !task_queue.empty() || stop_flag; });

            // Exit if we're stopping and queue is empty
            if (stop_flag && task_queue.empty()) {
                break;
            }

            // Grab the task and unlock early to let other threads access the queue
            int task = task_queue.front();
            task_queue.pop();
            lock.unlock();

            // Process the task (replace with your logic)
            std::cout << "Worker thread processed task: " << task << "\n";
        }
    }

public:
    // Constructor: spawn worker threads
    ThreadPool() {
        for (size_t i = 0; i < 5; ++i) {
            // Use member function pointer + this to ensure safe access to class members
            workers.emplace_back(&ThreadPool::worker_loop, this);
        }
    }

    // Destructor: clean up threads properly
    ~ThreadPool() {
        stop_flag = true;
        cv.notify_all(); // Wake all workers so they can exit

        // Join all threads to avoid detached threads
        for (auto& thread : workers) {
            if (thread.joinable()) {
                thread.join();
            }
        }
    }

    // Add a task to the queue
    void enqueue_task(int task) {
        std::lock_guard<std::mutex> lock(queue_mutex);
        task_queue.push(task);
        cv.notify_one(); // Wake one worker to process the new task
    }
};

int main() {
    ThreadPool pool;
    std::string input;

    std::cout << "Enter numbers to add to the task queue, or 'done' to exit:\n";
    while (std::cin >> input) {
        if (input == "done") {
            break;
        }
        try {
            int task = std::stoi(input);
            pool.enqueue_task(task);
        } catch (const std::invalid_argument&) {
            std::cout << "Invalid input! Enter a number or 'done'.\n";
        }
    }

    return 0;
}

Key Fixes in This Code: #

• All shared resources are class members, so their lifecycle is tied to the ThreadPool instance (which lives for the entire duration of main()).
• Uses a std::atomic<bool> for stop_flag to avoid data races.
• Worker threads use the class's this pointer to access members safely, no dangling references.
• Properly joins all threads in the destructor to ensure clean shutdown.

Final Checks for Your Code: #

1. Verify that any variables your threads access (queue, mutex, cv, done flag) are not local to a function that exits before threads finish.
2. Replace any plain bool flags with std::atomic<bool> to eliminate data races.
3. Ensure all threads are joined properly before their accessed resources are destroyed.

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