由于在python中采用GIL(全局解释锁)来保证解释器的线程安全，因此python中的多线程实际上是伪多线程。在提供给算法团队通信框架时，考虑采用多进程的架构来保证运行时的效率。
通常情况下，gunicorn进程和Flask进程为1:n的关系。由于每个算法进程有状态这一特殊性，即通信过程中，对于同一个任务的交互需要打到同一个算法进程，因此Flask进程只能为1，和gunicorn进程1:1对应。
在实际生产环境中，发现运行一段时候后，系统会出现进程阻塞，然后整个进程池用不了的问题。即比如算法进程1执行完毕，然而并没有调用Flask进程中的回调方法，此时算法进程1没有被进程池回收再利用，之后算法进程2和算法进程3会再出现同样阻塞的问题。如果进程池数量为3的话，则之后的请求进程池无法响应，只能进入到阻塞队列中。
然而，阻塞进程池的问题只能在运行一段时间出现，并不能稳定复现，这给进一步排查带来了很大困扰，只能通过各种测试去排查可能出现的原因。
经过测试，发现如果算法进程中不开启算法子进程的话，则不会出现进程阻塞的问题。因此，初步判定启动算法子进程可能会导致阻塞它的父进程算法进程。
那么，为什么在算法进程中开启子进程会阻塞它的父进程呢？
python启动子进程和linux一致，都是通过fork的方式，那么fork具体是如何实现的，带着这个疑问，查到一篇文章《fork多线程进程时的坑》。里面有关键的一句话。"在多线程进程中，为了多线程的同步及互斥，会有锁，在fork时，这些锁会一同fork到子进程中"。
从上述来看，应该是算法进程和子进程间产生了死锁，而不是之前以为的阻塞导致的进程未能被进程池回收再利用。
这时候定位到是死锁导致的，那么又有问题来了。为什么会偶发的发生死锁？
业务代码逻辑中没有锁，那么只能从python的process进程类中的源码找答案。
在process.py中，进程结束时会走到finally，里面有flush_std_streams()的方法
finally:
util.info('process exiting with exitcode %d' % exitcode)
util._flush_std_streams()
从代码里可以看出，进程在结束前会刷新缓冲区数据到文件。此时父子进程都持有这个文件的锁，很容易就导致了死锁的问题。
因此解决方案有两个：
1. 注释掉源码里的flush的操作（不太优雅）；
2. 避免flush的操作，即不是本地测试的情况下，关掉日志输出到console。
