python 中有 GIL 所以不支持多个线程同时运行，那协程又是什么和线程的区别是什么

en.wikipedia.org/wiki/Coroutine

superfastpython.com/python-concurrency-choose-api/

1. python 中有 GIL 所以不支持多个线程同时运行

2. 协程又是什么和线程的区别是什么

我怎么没看懂前后关系？

正经回答：「协程」是一个过度滥用的概念（以及营销术语），你不说清楚具体语境，就有一百种不同的解释。

掰扯这个词本身没什么意思，先说明白你想问的对象是什么。

协程的切出点是可以确认的，所以考虑 data race 这类问题时会简单很多，协程的栈(当然我是指把闭包变量当做等价的栈)通常比线程小而且更加灵活

线程是一个操作系统概念，是拥有 pid 的
协程是一种语法结构

python 在 GIL 的实现下，其多线程的并发可以理解为一个单核设备上不同的线程切换着运行，并不会像多核设备下多个线程并行执行。且 python 会每 5ms 就对占据 GIL 后正在运行的线程进行调度。即停止其运行，释放 GIL ，并重新调度其他线程抢占 GIL 后运行，这种行为是根据操作系统的线程机制来实现的。
而协程，其实是应用层的一个机制，和操作系统无关，就是通过 yield 关键字，将程序逻辑切分，但是无论怎么编写，协程始终是在同一个线程里运行的。

写爬虫或者 web ，协程真的快很多

协程跟线程的区别是一个由编程语言负责调度，一个由操作系统进行调度

本质上协程是线程的包装，协程底层还是走的线程的。

cpu 线程：如果你有一块 8 核 cpu 并开启了超线程，那就有 16 个 cpu 线程可用
操作系统线程：每个应用至少有一个进程，每个进程至少有一个线程，操作系统把应用创建的线程动态绑定到任意一个 cpu 线程上
协程：在同一个线程内，应用（编程语言）负责切换上下文，操作系统和 cpu 看不到你在搞事情，最适合 IO 并发任务

多线程：

1. 同一时间可以有两个指令在被 CPU 执行。
2. 线程是系统/硬件级的概念。
3. 例子：咖啡店有两个（机器人）店员在同时做咖啡。（你也没法写软件多出一个店员）

协程

1. 同一时间只有一个指令在被执行，但是可以是完全不同地方的指令。
2. 协程是应用级的概念。
3. 一个店员在做两杯咖啡，在等加热的时候去“同时”做另一杯。（因此协程通常只有在 IO bound 的时候才比较有作用）

当然也可以既有多线程也有协程。

我觉得你的问题是，既然 GIL 导致没有办法同时真的执行两个 python 语句，那多线程不就和协程一样了。我的理解是 python 的多线程仍然是多个系统线程，而 GIL 只在 python 代码里会被 lock ，如果是在做 IO bound/syscalls 或者甚至 numpy,pandas 在做计算的时候都会 release GIL 。

这玩意你用过 Windows3.1 就知道了。在 3.1 中，多任务的实现方式是程序主动放弃执行，这也导致了一旦有一个应用陷入死循环，整个系统就死了。

协程的好处就是你的代码不会被莫名其妙的打断，不太容易出现多线程中的竞态条件，也不需要锁等东西。坏处是对于那些运行缓慢的代码块，无论是计算密集，还是 IO 密集但你忘了用异步写，都会让程序卡死。

线程的好处是即使跑一个长过程也不会完全 block 住其他 IO 密集型的代码，但要处理多线程的那些问题。

首先更正一点，只有在 CPython 解释器中才有 GIL 锁，其他解释器例如 JPython 中就没有 GIL 的问题，GIL 本质上是为了保证底层的 C 的存储安全。

我最近写过一篇博客： blog.timerring.com/posts/cpu-can-only-see-the-threads

看过能解决你关于 python 中 多线程 多进程 并发 并行 协程 GIL 上下文切换 锁 同步异步 的疑问

核心中的核心就一句话 “CPU 只能看到线程” 如果你能真正理解这句话，你就能理解一切，不信可以读一读，也欢迎进一步斧正或者交流套讨论。

另外我之前也写过在 go 中的实现方式，看过你就能理解 go 的设计到底比 python 好在哪里。具体可以找一找我的博客。

＃8 不对啊喂
协程不是线程的封装，底层也不是线程

＃5 线程有自己的 pid ？操作系统哪一章讲的，我复习一下？

是有 pid 的，具体哪一章要看你用哪个版本的教材

＃3 隔了半天回来看，果然大部分回复都按自己的直觉先入为主了（没有说回复不对的意思）：

Python / Lua 的非抢占式协同调用（又称生成器），

C++20 / Go 的无栈（堆）抢占式微线程，

都能称为「协程」。

还有说「协程一定是单线程的」，等谈到 Java/Kotlin 有 Scheduler 参与的协程时，又要懵逼了。

另外，支持工作分发的 OpenMP 算不算协程？这也不好说。

---

至于「线程」和「协程」的区别，品一下它们的目的就知道了：

「线程」：操作系统调度 CPU 资源的最小单位。
「协程」：多程序流协作运作的机制。

「线程」是操作系统的约定，你给操作系统一个程序地址，系统就能为这个程序分配资源。
「协程」是设计上的考虑，是开发者自己设计的、让进行不同逻辑的程序之间协作的机制。

一言蔽之，这俩从概念上就八竿子打不着，根本不是一个 level 的东西。只不过现在很多协程的实现（例如无栈微线程）就是为了解决操作系统线程在协作方面存在的问题（太贵？要考虑并发？写起来麻烦？），所以往往需要涉及线程相关的知识。

看英文也能看出：为什么线程叫 thread 而不是 routine ，协程叫 coroutine 而不是 cothread ？有没有可能它俩根本不是同一种概念？

手抖发出去了，补充一下：

最后回答一下楼主的问题：仅在 Python 语境下，就是抢占式（操作系统轮转）和非抢占式（主动 yield ）协作运算的区别。

“线程有 pid”是 linux 的特色，因为历史遗留问题 Linux 内核里不区分线程进程都统称 task 统一管理。

在 Linux 里 pid 相当于别的系统里的线程 id ，tgid （线程组 id ，等于同一个进程中主线程的 pid ）相当于别的系统里的 pid 。

不是普适的特性，只有 Linux 才是线程有 pid 。像 Windows 这种线程从属于进程的系统就是区分 pid 和 tid 的。

说实话，能真正理解协程，代表对编程上了一个台阶。
自己真正拿 c 实现下，好处超出想象

早期的系统进程和线程分的比较开，但是现在的基本上 thread 也会有 pid, 包括 linux.

我觉得主要区别是
线程是系统调度器抢占 cpu, 可以把进程 线程强制踢出 cpu
协程大部分是阻塞时主动让出 cpu, coroutine 的 co 我觉得是 cooperative 。
假如一个协程一直不阻塞，调度器也没法踢他。

我的认知里 coroutine 比 thread 和 process 更轻量但是也能共享内存，不过一直没深入理解过。

之前好奇过 python 的 green thread/gevent/asyncio 这些概念有没有区别。以及跟 Erlang 的 process ，Go 的 goroutine ，Node 的 async ，和 Rust 的 tokio 之间有没区别。

简单说，底层是一样的，或者只有一层上面出来两套
一套是 blocking io ，另一套是 non-blocking io
大部分的 coroutine 都是解决网络 io （ asyncio 默认都不处理本地文件 io ），场景是大部分时间 cpu 都在等网络 io ， 比如 webapp 等 db 之类。
python 的话，除了 GIL 部分，gevent 使用的是隐式的方法，相当于所有进到底层 blocking io 的地方，都包（ patch ）了一遍，强行改成了异步的办法，库用的是 libuv/libev
asyncio 用的是显式的写法，你所有碰 io 的地方，都得 asyncio ，然后 asyncio 库再去实现一个 event loop ，然后如果你恰巧用的是 uvloop, 那就跟 gevent+libuv 底层一样了。

对于 go ，由于 goroutine 的 async 是语言级，不是一个库，他实际上可以理解为 gevent 的风格，直接底层把 io 部分包好了。

对于 nodejs ，单线程的部分跟 py 很像，甚至 libuv 本身就是 nodejs 出来的，不过语法上也是要显式的使用 async.

tokio 的话，对应的位置应该是 uvloop 。rust 本身 std 有个 async ，tokio 相当于从 0 造了个轮子，包含了 uvloop+libuv 。

语法上要是根据有无显式 async 的话，gevent+go 是一类，其他的都需要显式的写 async await. 底层上除了 tokio/go ，都可以偷懒直接套现有的 event 库，比如 libuv.
综合来看，go 的 async 实现最优雅(原生内置)，gevent 对于没有精神洁癖的人来说，性能也过得去，用起来也不难受。