uWSGI运行Django调用Go编译.so库异常：进程冻结无日志

这种场景我之前踩过好几次坑，直接用Python跑没问题，但一放到uWSGI里就卡死无日志，核心问题大多和uWSGI的进程模型、Go Runtime与Python GIL的交互，以及共享库的初始化逻辑有关。下面是一步步的排查和解决思路：

1. 先解决uWSGI进程fork导致的Go Runtime冲突 #

uWSGI默认的启动方式是先加载Django应用（包括加载Go的.so库），再fork子进程处理请求。但Go的Runtime是和进程绑定的，fork后的子进程会继承主进程的Runtime状态，但无法正确复用（比如goroutine调度器、线程池等），这会直接导致调用Go库时卡住。

解决方案：在uWSGI配置文件中添加：

lazy-apps = true

这个选项会让每个子进程独立加载Django应用和Go共享库，确保每个进程都有自己的Go Runtime实例，避免跨进程的状态冲突。

2. 检查Python调用Go库的方式是否正确 #

如果你的Python代码用了ctypes.PyDLL来加载Go的.so库，那大概率会出问题——因为PyDLL会强制持有Python的GIL（全局解释器锁），而Go的Runtime需要自己的线程来调度goroutines，GIL被持有时Go的线程无法运行，直接导致冻结。

正确做法：改用ctypes.CDLL加载库，它会在调用C函数时自动释放GIL，让Go Runtime正常工作：

import ctypes
# 用CDLL代替PyDLL
go_lib = ctypes.CDLL("./output.so")
# 后续调用导出的函数
go_lib.your_exported_function()

3. 重构Go代码的初始化逻辑 #

如果你的Go代码在init()函数里做了全局初始化（比如启动goroutine、初始化全局连接池、创建线程本地存储等），这些操作会在库加载时（主进程中）执行，fork后的子进程继承这些状态后会处于不一致的状态，导致调用时卡死。

解决方案：把初始化逻辑移到导出的C函数内部，采用延迟初始化的方式，确保每个进程第一次调用时独立初始化：

package main

import "C"
import (
    "sync"
)

var once sync.Once
var initialized bool

//export your_exported_function
func your_exported_function() {
    // 每个进程只初始化一次
    once.Do(func() {
        // 原来init()里的初始化逻辑移到这里
        // 比如初始化连接池、启动必要的goroutine等
        initialized = true
    })

    // 函数核心逻辑
}

func main() {} // 必须保留空main函数，否则无法编译为c-shared库

4. 调整uWSGI的进程/线程模型与Go Runtime参数 #

如果上述方法还不行，可以尝试调整uWSGI的运行模式：

• 优先使用多进程模式（设置processes = 4之类的参数），而非多线程模式，减少Python线程与Go线程的调度冲突。
• 设置Go的GOMAXPROCS环境变量，限制Go使用的CPU核心数，避免和uWSGI的进程抢占资源。可以在uWSGI配置中添加：

env = GOMAXPROCS=1

5. 添加Go侧的日志排查卡位点 #

因为冻结时Python和uWSGI都没有日志输出，建议在Go的导出函数中添加文件日志，直接写入本地文件，排查具体是在哪个步骤卡住的：

//export your_exported_function
func your_exported_function() {
    f, err := os.OpenFile("/tmp/go_lib.log", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
    if err == nil {
        defer f.Close()
        log.SetOutput(f)
    }

    log.Println("进入Go函数")
    // 关键步骤都添加日志
    // ...

    // 核心逻辑
    log.Println("执行核心逻辑完成")
}

这样即使进程冻结，也能通过日志看到最后执行到哪一步，缩小排查范围。

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