线程基础与概念：进程与线程的区别、Python中的GIL全局解释器锁、多线程适用场景分析
1.1 进程与线程：到底差在哪？
很多初学者问我：「进程和线程，到底有啥区别？」
我一般会打个比方：进程就像一家独立的餐厅，线程就是餐厅里的厨师。
每家餐厅（进程）有自己的厨房、食材、收银台——这些是独立的资源。而厨师（线程）们共享这个厨房，用同一口锅、同一把刀。厨师之间可以随时交流：「老王，帮我递个盐！」
但问题也来了——如果两个厨师同时抢一把刀，那就得打架了。所以需要锁、需要协调。
核心区别一句话总结：
- 进程：资源分配的最小单位，每个进程有独立的内存空间。
- 线程：CPU调度的最小单位，同一进程内的线程共享内存。
我在项目中遇到过这样一个坑：用多进程处理大量数据，结果内存直接爆了。为什么？因为每个进程都复制了一份完整的数据。换成多线程后，共享内存，内存占用瞬间降下来。但代价是——你得小心处理线程安全问题。
| 对比维度 | 进程 | 线程 |
|---|---|---|
| 内存空间 | 独立 | 共享 |
| 创建开销 | 大 | 小 |
| 通信方式 | IPC（管道、队列等） | 直接读写共享变量 |
| 稳定性 | 一个进程挂了不影响其他 | 一个线程挂了可能拖垮整个进程 |
| 适用场景 | CPU密集型、隔离性要求高 | I/O密集型、需要频繁共享数据 |
我的个人习惯：如果任务之间几乎不共享数据，或者需要高隔离性，我选多进程。如果任务需要频繁交换数据，或者主要是等待网络/磁盘，我选多线程。
1.2 Python的GIL：绕不开的「紧箍咒」
聊Python多线程，就绕不开GIL。GIL全称是全局解释器锁（Global Interpreter Lock）。
说白了，GIL就是一个大锁，保证同一时刻只有一个线程在执行Python字节码。
你可能会问：「那多线程还有什么用？不还是串行吗？」
嗯，这个问题我当年也困惑过。后来在做一个爬虫项目时，我才真正理解了——GIL只锁CPU计算，不锁I/O等待。
GIL的影响：
- CPU密集型任务：多线程反而可能更慢（因为锁竞争和上下文切换）。
- I/O密集型任务：多线程效果显著（因为线程在等待I/O时会释放GIL）。
我曾经踩过一个坑：用8个线程做图像处理（纯计算），结果比单线程还慢。查了半天，发现是GIL在作祟。后来换成多进程，速度直接翻了6倍。
注意：GIL是CPython解释器的实现细节。其他Python解释器（如Jython、IronPython）没有GIL。但绝大多数人用的都是CPython，所以这个知识点你必须吃透。
1.3 多线程适用场景分析
搞清楚GIL之后，我们就能判断：什么时候该用多线程？
适合多线程的场景：
- 网络爬虫：大量时间花在等待服务器响应上。
- Web服务：处理用户请求时，大部分时间在等待数据库或外部API。
- 文件读写：多个文件同时读写，I/O等待时间远大于处理时间。
- GUI应用：主线程负责界面响应，后台线程处理耗时操作。
不适合多线程的场景：
- 大规模数值计算：矩阵运算、图像处理、机器学习训练。
- 视频编码/解码：纯CPU密集型。
- 加密/解密：计算量大，GIL会成为瓶颈。
我建议：如果你不确定某个场景是否适合多线程，先写个简单的性能测试。用单线程跑一遍，再用多线程跑一遍，对比时间。数据不会骗人。
1.4 本章知识体系
下面这张图，是我梳理的本章核心逻辑。你看完应该能对「进程 vs 线程」和「GIL的影响」有个整体把握。
1.5 一个简单的代码示例
光说不练假把式。我写个最简单的例子，让你感受一下GIL的影响。
import threading
import time
# CPU密集型任务：计算
def cpu_task(n):
result = 0
for i in range(n):
result += i ** 2
return result
# I/O密集型任务：模拟等待
def io_task():
time.sleep(2) # 模拟网络请求或文件读写
# 测试CPU密集型
start = time.time()
threads = []
for _ in range(4):
t = threading.Thread(target=cpu_task, args=(10_000_000,))
threads.append(t)
t.start()
for t in threads:
t.join()
print(f"CPU密集型多线程耗时: {time.time() - start:.2f}秒")
# 测试I/O密集型
start = time.time()
threads = []
for _ in range(4):
t = threading.Thread(target=io_task)
threads.append(t)
t.start()
for t in threads:
t.join()
print(f"I/O密集型多线程耗时: {time.time() - start:.2f}秒")
运行结果你猜猜看：CPU密集型那一段，4个线程跑完可能比单线程还慢（因为GIL竞争）。而I/O密集型那一段，4个线程只用了约2秒——几乎是单线程的1/4时间。
1.6 避坑指南
最后，分享几个我踩过的坑：
- 不要以为多线程一定快。我曾经在CPU密集型任务上用了多线程，结果被领导批评「优化了个寂寞」。
- 注意线程安全问题。多个线程同时修改同一个变量，结果可能出乎意料。后面我们会讲锁机制。
- GIL不是万恶之源。它保证了Python内存管理的简单性。没有GIL，Python的垃圾回收会复杂得多。
我曾经犯过的错：在一个Web服务中，用多线程处理每个请求。结果高并发时，GIL成了瓶颈，QPS上不去。后来改用异步I/O（asyncio），问题才解决。所以，多线程不是银弹，选对工具很重要。
好了，这一章的内容就到这里。记住：理解GIL，你就理解了Python多线程的一半。