C++14集成Boost.Python 1.58调用Py_Initialize引发线程挂起异常

• GIL 持有未释放
  Py_Initialize()执行完成后，调用初始化逻辑的线程会默认独占持有GIL，且Boost.Python 1.58不会自动释放该锁。此时所有尝试调用Python API的线程都会直接进入阻塞状态，直到当前线程显式调用PyEval_SaveThread()释放GIL。即便你暂时没有运行Python业务代码，只要有其他线程访问Python相关接口就会触发挂起。
• 动态链接全局锁阻塞
  Python初始化阶段会批量加载标准库模块、解析全局符号，此时操作系统动态链接器会持有全局的重定位锁，所有需要访问动态符号表、执行系统调用的线程都会被短暂阻塞，该锁的优先级高于CPU亲缘性绑定策略，会直接导致绑核线程出现毛刺。可通过设置环境变量LD_BIND_NOW=1预加载所有进程符号验证，若挂起消失即可确认是该原因。
• 全局信号处理注册开销
  Py_Initialize()默认会注册十多个进程全局的信号处理函数（包括SIGINT、SIGSEGV、SIGALRM等），信号注册过程以及后续的信号触发都会中断当前正在运行的绑核线程，产生微秒到毫秒级的挂起。可替换为Py_InitializeEx(0)初始化（参数0表示不注册Python默认信号处理逻辑）验证问题是否消失。
• Boost.Python 1.58 已知初始化缺陷
  该版本的Boost.Python存在类型注册表全局锁问题：初始化阶段会遍历所有已注册的C++/Python类型转换规则，全程持有全局锁，此时所有跨线程的类型转换操作都会被阻塞。该问题在Boost 1.65及之后版本已修复，可通过升级Boost版本验证。
• 内存分配器全局锁竞争
  Python初始化阶段会申请大量连续内存页，若使用默认glibc malloc，内存申请会持有arena全局锁，其他正在执行内存申请的线程会被阻塞。可替换为tcmalloc或jemalloc验证是否为内存分配锁导致的毛刺。

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