pybind11多线程调用Python函数触发SIGSEGV崩溃问题咨询

架构老林

2026-8-30

问题根因

崩溃的核心原因是违反了CPython的线程规则：任何线程调用CPython C API（包括pybind11封装的Python对象操作）前，必须持有全局解释器锁（GIL）。
你创建的std::thread是操作系统原生线程，默认不持有GIL，直接在这些线程里调用Python函数func、访问序列iter、修改Python列表l，全属于未定义行为，直接触发段错误（SIGSEGV）。
你测试时k=1不崩只是巧合：此时只有一个子线程，主线程在join等待时没有执行任何Python操作，不会和子线程争抢GIL，没有触发竞态，但写法本身依然是违规的。
除此之外你的代码还有两个不规范/无效的问题：

使用了非标准C的变长数组std::thread threads[k]，k是运行时获取的值，标准C不支持栈上运行时长度数组，这是编译器私有扩展，存在栈溢出风险。
就算补上GIL逻辑，如果被调用的func是纯Python代码、没有主动释放GIL的逻辑，多线程不会带来任何性能提升——GIL同一时间只允许一个线程执行Python字节码，多线程只会额外增加线程切换、GIL争抢的开销，比单线程更慢。只有当func内部调用了会主动释放GIL的C/C++扩展（比如你示例里的gmpy2、numpy这类数值计算库），多线程才能真正利用多核并行。

修正后的实现

核心修正点：

主线程启动子线程前主动释放GIL，避免占着锁阻塞子线程
每个子线程操作Python对象前，显式获取GIL，操作完成后自动释放
用std::vector存储线程对象，符合C++标准

#include <vector>
#include <thread>
#include <pybind11/pybind11.h>

namespace py = pybind11;

m.def("test_func_iter", [](const py::object &func, const py::sequence &iter) {
    const size_t n = py::len(iter);
    py::list result(n);
    const unsigned int thread_num = std::thread::hardware_concurrency();
    std::vector<std::thread> threads;
    threads.reserve(thread_num);
    const size_t stride = n / thread_num;

    // 主线程释放GIL，子线程才能正常获取锁
    py::gil_scoped_release gil_release;

    for (unsigned int w = 0; w < thread_num; ++w) {
        size_t start = w * stride;
        size_t end = (w == thread_num - 1) ? n : (w + 1) * stride;
        threads.emplace_back([&result, &func, &iter](size_t s, size_t e) {
            // 子线程操作Python对象前必须获取GIL
            py::gil_scoped_acquire gil_acquire;
            for (size_t i = s; i < e; ++i) {
                result[i] = func(iter[i]);
            }
        }, start, end);
    }

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

    // gil_release析构时会自动重新持有GIL，可安全返回Python对象
    return py::type::of(iter)(result);
});

最佳实践提示

如果你的func是纯Python逻辑、没有调用释放GIL的C扩展，不要用C多线程，没有性能收益。这类场景要并行建议用Python多进程，或者把核心计算逻辑迁移到C中，在无GIL的状态下完成计算后再回传结果。
不要在持有GIL的状态下执行耗时的纯C++计算，否则会阻塞所有Python线程的执行。纯计算逻辑应该放在GIL释放的代码段中，只有需要读写Python对象时才临时获取GIL。
频繁创建销毁线程有额外开销，生产环境建议复用线程池实现并行遍历，核心的GIL管理逻辑和上述示例一致。

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