在使用 python c api 创建多个子解释器时，若未正确获取并持有各子解释器的 gil，调用 `pyimport_execcodemodule` 等导入操作可能引发内存损坏——尤其当被导入模块依赖 `urllib.request` 或 `yaml` 等非线程安全的内置扩展时。根本原因在于子解释器 gil 未被显式确保。
Python 的子解释器（subinterpreter）机制旨在提供轻量级隔离执行环境，但其 GIL（全局解释器锁）行为与主线程解释器不同。当使用 PyInterpreterConfig{.gil = PyInterpreterConfig_OWN_GIL} 创建子解释器时，每个子解释器拥有独立的 GIL 实例，但该 GIL 不会自动被当前线程持有——即使程序是单线程的。这意味着：任何涉及 Python 对象操作（包括模块导入、字节码执行、属性访问等）前，必须显式调用 PyGILState_Ensure()（或 PyEval_AcquireThread()，推荐前者），以将当前线程与目标子解释器的 GIL 关联并获取锁。
否则，PyImport_ExecCodeModule 在未持锁状态下访问共享的导入缓存（如 sys.modules）、初始化全局状态（如 urllib.request 的 _opener 单例或 yaml 的解析器注册表）时，会因竞态导致内存越界、引用计数错乱或堆损坏——这正是 urllib.request 和 yaml 等模块触发崩溃而 os 或 base64 不触发的原因：后者初始化更简单、无跨解释器共享副作用，而前者内部存在隐式全局状态或 C 扩展级静态变量，对 GIL 保护高度敏感。
✅ 正确做法是在每次切换到子解释器上下文后、执行任何 Python C API 调用前，插入 PyGILState_Ensure()；并在离开前调用 PyGILState_Release()。注意：PyGILState_Ensure() 是线程本地的，可安全嵌套调用，且与 Py_NewInterpreterFromConfig 创建的 OWN_GIL 子解释器完全兼容。
以下是修复后的关键代码片段（仅展示 Sub1 部分，Sub2 同理）：
立即学习“Python免费学习笔记（深入）”；
// 创建子解释器 Sub1
tstate_s1 = NULL;
PyStatus status_s1 = Py_NewInterpreterFromConfig(&tstate_s1, &config_s1);
if (PyStatus_Exception(status_s1)) {
std::cerr << "Failed to create subinterpreter 1" << std::endl;
return -1;
}
// ✅ 切换到 Sub1 并确保其 GIL
PyThreadState_Swap(tstate_s1);
PyGILState_STATE gstate_s1 = PyGILState_Ensure(); // 必须！否则导入可能崩溃
// 设置 sys.path 并导入模块
std::string sysPathCmd1 = "import sys\nsys.path.append('" + cwd + "')";
PyRun_SimpleString(sysPathCmd1.c_str());
PyObject* bytecode1 = Py_CompileString(module_code1, "test_module1", Py_file_input);
PyObject* pModule1 = PyImport_ExecCodeModule("test_module1", bytecode1); // 安全：GIL 已持
if (!pModule1) {
PyErr_Print();
PyGILState_Release(gstate_s1); // 释放前先恢复主线程状态
PyThreadState_Swap(tstate_main);
return -1;
}
// ... 执行函数调用等操作
// ✅ 清理：释放 GIL 并切换回主线程
PyGILState_Release(gstate_s1);
PyThreadState_Swap(tstate_main);⚠️ 注意事项：
- 不要混用 PyGILState_Ensure() 和 PyEval_* 系列锁函数（如 PyEval_AcquireThread），二者管理不同层级的 GIL 状态；
- 每次 PyGILState_Ensure() 必须配对 PyGILState_Release()，避免资源泄漏；
- PyThreadState_Swap() 仅切换当前线程关联的 PyThreadState，不自动处理 GIL —— GIL 获取是独立步骤；
- 若模块需跨子解释器复用，建议改为预编译字节码 + 在各子解释器中独立执行（而非共享模块对象），以规避状态污染。
总结：多子解释器场景下，“创建即安全”是误区；GIL 必须按需显式确保。这一原则不仅适用于模块导入，也适用于所有 Python C API 调用。遵循此规范，即可稳定支持 urllib.request、yaml 等复杂模块在多子解释器环境中的并发加载。
