我已经阅读了许多关于如何将threading与queue.Queue或multiprocessing.pool.ThreadPool或concurrent.futures.ThreadPoolExecutor结合使用的文章和文章，但没有一个对我有用。我的意思是根本没有并行性。我获得 100% CPU 使用率和真正并行性的唯一方法是使用multiprocessing.Pool.我还读过关于 GIL 和 CPython 的文章。
为什么我关心至少一种方法是否有效？好吧，multiprocessing.Pool只是防止嵌套并行性(守护进程(。我不能让外部函数在单独的进程中运行，并且该函数启动自己的进程池。
因此，我有两个问题，希望能阻止我永无止境地寻找有效的方法：
- 如果我使用默认的 Anaconda 发行版及其
python.exe，那么在 Python 中多线程真的是不可能的吗？(我看到一堆文章在谈论使用 GUI 和 I/O 操作进行多线程...... - 嵌套并行在 Python 中真的不可能吗？
问：">在 Python 中多线程真的不可能吗？
在字典上，有一个多线程代码执行(代码导入基于线程的工具(。
尽管如此，正如您已经阅读 GIL-details 和 Python 解释器设计的现状(这从一开始就有效，并且仍然由 Guido van Rossum 本人在 2020-Q2 中作为设计属性进行辩护(GIL-lock 单例的中央锁获取，实际的代码执行在基于线程的 python 工具下重新[SERIAL]- ised， 因此，实际产生的性能加速得到了<< 1(所有设置的所有附加成本都已支付，所有与 GIL-lock 相关的线程执行开销切换都得到了支付(每个大约250 ms- 所以加起来......(在整个代码执行过程中，然而，这里不会出现任何加速(除了碰巧屏蔽的用例(最好多次， 以证明所有其他附加成本的合理性(一些外部I/O延迟(网络传输，用户与UI的缓慢交互(>> 250 ms，上面也提到了(
问：">嵌套并行在Python中真的不可能吗？
好吧，最终的答案不是关于它是否以某种方式可能，
而是尝试
实现这一目标是否有意义？，
为此一个简单的答案(在 2020-Q2 仍然有效(
(性能方面(不，对不起，尝试这样做永远不会有意义，
除非所有附加费用的总和至少开始变得合理(在2020-Q2中似乎不会接近，而且几乎不会开始，除非Python生态系统进行彻底的重新设计，直接反对Guido的福音传播(。
以性能为动机的架构必须很好地平衡所有附加成本，以免落入阿姆达尔定律的陷阱 - 它永远不会支付超过接收回报的方式。
打字就这么简单。
实现起来如此复杂。