在用Python（解释语言）构建包含多线程的算法时，我惊讶地发现，与我之前构建的顺序算法相比，执行时间并没有任何改善。为了理解导致这种结果的原因，我做了一些阅读，并相信我所学到的内容提供了一个有趣的背景，可以更好地理解多线程和多进程之间的差异。

多核系统可能会执行多个线程，因此Python应该支持多线程。但Python不是一种编译语言，而是一种解释语言1。这意味着必须对程序进行解释才能运行，并且在程序开始执行之前，解释器不知道程序。然而，它所知道的是Python的规则，然后动态地应用这些规则。Python中的优化必须主要是解释器本身的优化，而不是要运行的代码。这与C++等编译语言形成对比，并对Python中的多线程产生影响。具体来说，Python使用全局解释器锁来管理多线程。

另一方面，编译语言是编译的。程序被“完全”处理，首先根据其语法定义进行解释，然后映射到语言不可知的中间表示，最后链接到可执行代码中。这个过程允许代码得到高度优化，因为在编译时所有代码都可用。在创建可执行文件时定义了各种程序交互和关系，可以做出关于优化的稳健决策。

在现代环境中，Python的解释器必须允许多线程，这必须既安全又高效。这就是解释语言与编译语言的区别所在。解释器必须不干扰来自不同线程的内部共享数据，同时优化处理器的计算使用。

如前几篇文章所述，进程和线程都是独立的顺序执行，主要区别在于内存在进程的多个线程之间共享，而进程隔离了它们的内存空间。

在Python中，全局解释器锁防止不同线程同时访问数据。它要求在任何Python程序中，任何时候只能执行一个线程。另一方面，可以运行多个进程，因为每个进程的内存都与任何其他进程隔离，并且进程可以在多个内核上运行。

唐纳德·克努思在《计算机编程的艺术：基本算法》中对解释例程有很好的解释。

进程和线程之间的差异如下：

进程是程序的执行实例，而线程是进程的最小单元。进程可以划分为多个线程，而线程不能划分。进程可以被认为是一个任务，而线程可以被看作是一个轻量级的任务。进程分配单独的内存空间，而线程分配共享内存空间。进程由操作系统维护，而线程由程序员维护。

进程和线程都是独立的执行序列。典型的区别是（同一进程的）线程在共享内存空间中运行，而进程在单独的内存空间中。

我不确定你可能指的是什么“硬件”线程和“软件”线程。线程是一种操作环境特性，而不是CPU特性（尽管CPU通常具有使线程高效的操作）。

Erlang使用术语“进程”，因为它不公开共享内存多道程序模型。称它们为“线程”意味着它们共享内存。

到目前为止，我找到的最好答案是Michael Kerrisk的《Linux编程界面》：

在现代UNIX实现中，每个进程可以有多个线程执行。设想线程的一种方式是作为一组进程共享同一虚拟内存以及一系列其他属性。每个线程执行相同的程序代码并共享相同的数据区域和堆。但是，每个线程都有自己的堆栈包含局部变量和函数调用链接信息。[LPI 2.12]

这本书非常清晰；JuliaEvans在本文中提到了它在澄清Linux组真正工作方式方面的帮助。

我已经仔细阅读了几乎所有的答案，唉，作为一名正在修OS课程的本科生，我目前还不能完全理解这两个概念。我的意思是，大多数人都从一些操作系统书籍中读到了不同之处，即线程能够访问事务单元中的全局变量，因为它们利用了进程的地址空间。然而，新的问题出现了，为什么会有进程，我们已经知道线程相对于进程更轻。让我们通过使用从先前答案之一中摘录的图像来浏览以下示例，

我们有3个线程同时处理一个word文档，例如Libre Office。第一种方法通过下划线检查单词是否拼写错误。第二个从键盘上取下并打印字母。最后一个确实会在短时间内保存文档，以免在出现问题时丢失正在处理的文档。在这种情况下，3个线程不能是3个进程，因为它们共享一个公共内存，该内存是它们进程的地址空间，因此所有线程都可以访问正在编辑的文档。因此，道路是文字文档，还有两台推土机，它们是线索，尽管其中一台在图像中缺失。

http://lkml.iu.edu/hypermail/linux/kernel/9608/0191.html

莱纳斯·托瓦尔兹(torvalds@cs.helsinki.fi)1996年8月6日星期二12:47:31+0300（欧洲东部夏令时）邮件排序依据：[date][thread][subject][author]下一条消息：Bernd P.Ziller：“回复：get_hash_table中的错误”上一条消息：Linus Torvalds：“Re:I/O请求排序”1996年8月5日星期一，Peter P.Eiserloh写道：我们需要明确线程的概念。太多人了似乎混淆了线程和进程。以下讨论不反映linux的当前状态，而是试图保持高级别的讨论。不！没有理由认为“线程”和“进程”是独立实体。这是传统的做法，但我我个人认为这样想是一个重大错误。唯一的有理由认为这种方式是历史包袱。线程和进程实际上只是一件事：试图人为地区分不同的案例只是自我限制。一个“执行环境”，这里称为COE，只是一个企业集团该状态包括CPU等状态（寄存器等）、MMU状态（页面映射）、权限状态（uid、gid）和各种“通信状态”（打开文件、信号处理器等）。传统上，“线程”和“进程”主要是指线程具有CPU状态（+可能一些其他最小状态），而所有其他上下文都来自过程然而，这只是一种划分COE总状态的方法，没有任何东西表明这是正确的方法。限制自己对那种形象来说简直是愚蠢至极。Linux对此的思考方式（以及我希望的工作方式）是没有所谓的“进程”或“线程”。有只有整个COE（Linux称为“任务”）。不同的COE可以彼此共享部分上下文共享是传统的“线程”/“进程”设置，但应该真正被视为仅仅是一个子集（它是一个重要的子集，但是这种重要性不是来自设计，而是来自标准：我们显然希望在Linux上运行符合标准的线程程序也是）。简而言之：不要围绕线程/进程的思维方式进行设计。这个内核应该围绕COE的思维方式进行设计，然后pthread库可以将有限的pthread接口导出给用户他们想用这种方式来看待COE。作为一个例子，当你认为COE是与线程/进程相反：您可以执行外部“cd”程序，这在UNIX和/或进程/线程中传统上是不可能的（愚蠢的例子，但想法你可以拥有这些类型的“模块”传统的UNIX/threads设置）。执行以下操作：克隆（clone_VM|clone_FS）；child:execve（“外部cd”）；/*“execve（）”将解除VM的关联，因此使用CLONE_VM是为了更快地进行克隆*/您可以自然地执行“vfork（）”（它需要最少的内核支持，但这种支持完全符合CUA的思维方式）：克隆（clone_VM）；child:继续运行，最终执行（）妈妈：等高管您可以执行外部“IO deamons”：克隆（clone_FILES）；child:打开文件描述符等妈妈：用孩子打开的fd和vv。以上所有的工作都是因为您没有绑定到线程/进程思维方式。以web服务器为例，其中CGI脚本作为“执行线程”完成。你不能用传统线程，因为传统线程总是必须共享整个地址空间，所以你必须链接所有你曾经希望在web服务器本身（一个“线程”不能运行另一个可执行）。将此视为“执行上下文”问题任务现在可以选择执行外部程序（=将来自父级的地址空间）等，或者他们可以示例与父级共享除文件之外的所有内容描述符（这样子“线程”可以打开大量文件家长需要担心它们：当子“线程”退出，并且不会使用父级中的fd）。例如，设想一个线程化的“inetd”。你想要低开销fork+exec，所以用Linux的方式可以代替使用“fork（）”您编写了一个多线程inetd，其中每个线程都是用仅CLONE_VM（共享地址空间，但不共享文件描述符等等）。然后，如果它是外部服务（rlogind，例如），或者可能是内部inetd服务之一（echo，timeofday）在这种情况下，它只是做它自己的事情，然后退出。你不能用“线程”/“进程”这样做。莱纳斯牌手表