目录
概述
入门
陷阱：时序性和一致性
陷阱：访问共享内存
陷阱：死锁
陷阱：异形方法和依赖关系
多线程日志记录
concurrent.futures
结论
概述
线程和锁是硬件底层的软件定义形式化，因此包含最简单的可能并发模型。它构成了其他构建在其顶层的并发抽象基础，因此理解这一点很重要。然而，直接在这些基础上构建可靠，可扩展的系统是很困难的或着说是不可能的。
虽然大多数语言都支持线程和锁，但CPython仍然使用全局解释器锁来防止线程同时访问共享内存，因为CPython的内存管理是非线程安全的。虽然阻塞操作发生在GIL之外并且可能提高性能，但是线程切换所需的系统调用开销可能会降低性能。这意味着Python中的线程主要用于I/O受限的场景，而不是CPU受限的场景。
说句题外话，我提到了CPython，因为Python规范的其他部分实现，例如Jython，没有全局解释器锁。然而，这些实现在实践中并没有被广泛使用，因为第一：没有人想要支持多Python实现，除非他们不得不这样；第二：它们还不够丰富；第三：由于需要原生支持C/C++扩展API，Python语言定义与C/C++紧密耦合，与其说是技术规范不如说是一个参考实现。
Python通过高级模块threading模块和低级模块_thread直接支持线程。想要获得更多有关这些模块如何工作的信息，可以在线获取源代码。
入门
Python中典型的单线程“Hello World”执行非常简单：
多线程模拟并没有太大的不同：
基于我有限数量的测试，上面的脚本运行结果如下所示：
我用了get_ident()打印“线程标识符”（一个魔法值，除了在运行时消除不同线程之间的歧义之外，没有任何意义）。你可以看到在某些情况下，线程标识符是如何不同的，而在其他一些情况下，线程标识符又是相同的。相同的线程标识符并不意味着仍工作在同一个线程上，但如果工作不重叠并且不需要不同的线程标识符，Python会重新使用该标识符。
陷阱：时序性和一致性
如果你用threading.current_thread().getName()将线程标识符与线程名交换，你可能会获得有序结果，很大的原因可能是因为每个线程使用相同的函数和源码路径，因此，每个线程之间的延迟差异是微不足道的，仅次于解释器的延迟。然而，这并不意味着有序执行能够得到保证;这是WikiBooks上“Python Programming”的一个例子，其中每个线程的创建和每个线程的执行具有明显不同的时序性：
以下结果是同一个样本运行的输出：
这日志表示线程创建/执行是交错的。由于增加功能的可变性增加，随着线程创建和执行之间的时序越来越不一致，这些结果将变得越来越不可预测。但原理仍然是相同的;使用多个线程时无法保证一致的行为。
陷阱：访问共享内存
当不同的线程访问共享内存时，这可能导致不正确的行为。你可以扩展此示例以在使用多个线程进行计数时查看竞争条件：
这会在一次示例运行时生成如下输出：
此结果因创建的线程数而异，但你可以看到结果28与预期值100有多大区别。Counter().count是非线程安全的，在这里进行了演示（如果你有与我不同的机器，你可能会得到与28不同的结果）。如果遇到竞争条件，没有足够的日志记录，可能很难找到相关的代码部分。
陷阱：死锁
当两个代理尝试获取共享内存的相同区域时，最终就会发生死锁。当在处理线程和锁的低级抽象时，唯一的解决方案是确保每个代理有一种方法能正确地管理其锁，或者具有锁协调的整体规范。例如，用餐哲学问题强调了流程同步的重要性。Rosetta Code的用餐哲学python解决方案解决了这个同步问题：如果你（代理）不能及时获取这两个分叉，你可以释放你已经拥有的任何叉子，以便另一个代理可以同时获得这两个叉子
此方法不排除其他锁定方法，像锁定顺序，或涉及流程同步的系统设计，像使用信号量的生产者-消费者模型，但在Python中可能不如在其他语言中普遍。
陷阱：异形方法和依赖关系
如果要在Python应用程序中应用多线程，那么你希望保证整个堆栈的正确性，你必须手动验证核实线程安全性和依赖项的线程模型。有些为企业级多服务环境使用而设计的依赖项，例如redis，可以在设计阶段首先考虑它们的并发模型（请参阅黑客新闻antirez关于多线程版本redis的评论）。有些依赖可能不会;使用boto2时，并行使用multiprocessing.pool.Pool从S3并行下载文件时，我可能遇到了死锁，这需要重写一个函数。因此，另一个依赖性的困难出现了;它们无法被同化，这意味着如果你在你的应用使用依赖模型之前没有验证所有将使用的依赖关系，那么在尝试为特定用途添加依赖项时，你可能陷入项目的死胡同。
多线程日志记录
如果你选择使用Python中的原生线程模型，你可能会惊喜地发现logging模块不仅是线程安全的，而且还支持从任何特定线程或进程进行日志记录（示例在logging手册）。然后，难点是在你的应用程序中哪里更可能触发异常，这如何影响你的线程模型以及确保在这些代码段周围进行可靠的日志记录。将日志添加到你的应用可能会产生不小的延迟，正如pylint通过警告模块logging-lazy-interpolation通知你那样，这也可能会给你的线程模型带来困难。
concurrent.futures
在撰写这篇文章时发现Python
multiprocessing.pool.ThreadPool实现从未被记录或测试过，因为它从未完成，这让我感觉非常不愉快。它在Python3.7中仍然还是这样，因为它出现在GitHub镜像的源代码中。
鉴于全局解释器锁的无所不在，以及未来并发程序主要是并行I/O相关的工作，使用Python3.x中提供的像concurrent.futures.Executor或类似的新异步模式可能更有意义，因为他们更全面。我没有使用过这个模块，但我想与multiprocessing相比，它不会产生显着的性能损耗。
结论
Python对线程和锁具有基本的支持，它可能不像其他语言（例如Java）中的线程和锁那样功能全面且有用。在使用像Python等更高级别的解释语言进行操作时，最好避免使用线程和锁。然而，Python确实提供了关于线程和锁定的足够友好的曝光度，以便对线程和锁的工作方式进行良好的学术练习，也给并发界提供了激动人心的介绍。
要了解有关生产中的线程和锁定的更多信息，请查看Paul Butcher撰写的“七周七种并发模型”。
英文原文：https://bytes.yingw787.com/posts/2019/01/12/concurrency_with_python_threads_and_locks/
