我通常不需要在我的 Django 应用程序级编程（即视图）中显式使用线程。但我注意到一个看起来很有趣的库，它通过线程处理服务器端分析。
在 Django 视图期间，您将使用他们的 Python 客户端在一个单独的（非守护程序）线程中将 HTTP POST 批量发送到他们的 Web 服务。通常，我会使用 RabbitMQ 来代替线程，但他们希望降低库的启动成本。
我的问题是，这种方法有什么缺点吗？线程有一些额外的内存占用，但我不太担心。这显然取决于启动的请求/线程数。
线程不是守护进程并且可能长时间运行的问题是否存在？我假设 Gunicorn 进程是执行的主线程，并且它在无限循环中运行，因此它是否必须等待非守护线程退出通常并不重要。那是对的吗？
有点悬而未决的问题，但重点是了解非守护线程在 Django/Gunicorn 应用程序中的影响。
Gunicorn 使用 pre-fork worker 模型。Master 进程产生并管理 Worker 进程。对于非 Tornado 用途，有两种 Workers：Sync（默认）和Async。
在正常操作中，这些 Worker 循环运行，直到 Master 告诉它们正常关闭或杀死它们。Worker 会定期向 Master 发出心跳，表明他们还活着并且还在工作。如果发生心跳超时，则 Master 将杀死 Worker 并重新启动它。
因此，不干扰 Worker 主循环的守护线程和非守护线程应该没有影响。如果线程确实干扰了 Worker 的主循环，例如线程正在执行工作并将结果提供给 HTTP 响应的场景，则考虑使用 Async Worker。Async Worker 允许 TCP 连接长时间保持活动状态，同时仍允许 Worker 向 Master 发出心跳。