不，
concurrent.futures与GIL几乎没有任何关系。
对于GIL，使用进程而不是线程是良药。（当然，与所有药物一样，它也有副作用。但是它可以起作用。）
futures与使用
threading或
multiprocessing直接使用模块相比，该模块仅提供了一种更简单的计划和等待任务的方式。而且它还具有一个额外的优点，即您可以在线程池和进程池（甚至可能是greenlet循环，或者您发明并构建的疯狂的东西）之间进行交换而无需更改
future代码。因此，如果您不知道代码是否会遇到GIL问题，则可以将其构建为使用线程，然后将其切换为使用经过单行更改的进程，这非常好。
但是，如果使用
ThreadPoolExecutor，它将与使用
threading和手动创建线程池，任务队列等完全相同的GIL问题
queue。如果使用
ProcessPoolExecutor，它将以与
multiprocessing手动使用相同的方式（并具有相同的权衡）避免GIL问题。
PyPI软件包只是该
concurrent.futures模块从3.2到2.x（以及3.0-3.1）的简单反向移植。（它并没有神奇地为您提供经过改进的新的3.2
GIL，或者经过改进的3.3 GIL，更不用说删除GIL了。）
我什至不应该提到GIL的更改，因为这似乎增加了混乱……但是现在，让我尝试通过过度简化来理顺它。
如果除了IO绑定工作之外什么都没有，那么线程是获取并发性的一个好方法，可以达到合理的限制。3.3确实使它们更好地工作-
但是在大多数情况下，2.7已经足够好了，而在大多数情况下，2.7仍然不够好。如果你要处理10000个并发客户端，你将要使用的事件循环（例如
twisted，
tornado，
gevent，
tulip，等），而不是线程。
如果您有任何CPU限制的工作，线程将根本无法并行化该工作。实际上，它们使情况变得更糟。3.3使该惩罚不那么糟糕，但这仍然是一种惩罚，您仍然不应该这样做。如果要并行化CPU工作，则必须使用进程，而不是线程。3.3的唯一优点是
futures比容易使用
multiprocessing，并且是内置的，而不需要安装它。
我不想阻止您升级到3.3，因为它比2.7更好地实现了更好的语言。但是更好的并发并不是迁移的理由。
