哗啦啦的小流弊近几年做后端和中间件相关的工作，被问得最多的一个基础问题就是：线程切换到底在干什么，为什么一说到并发性能，大家都先提“上下文切换开销”。这个问题看起来简单，但真要落到“计算机原理”层面，牵扯到操作系统调度器、CPU寄存器、内核栈、缓存亲和性，甚至能一路聊到线程池怎么配置、锁怎么设计。我觉得这是整个并发编程里最值得讲透的一个点。
这篇文章就围绕“线程”和“上下文”两个关键词展开。你可以把它当成一份从原理到实战的笔记，适合刚学完操作系统、想搞清楚线程到底怎么跑起来的同学，也适合写了好几年业务代码、但遇到线上性能问题只能靠猜的开发者。我会尽量把底层的原理讲明白，再给出能直接用的排查命令和配置思路。
1. 从一块CPU开始：为什么需要线程这个概念
1.1 进程和线程的本质区别
很多人背过“进程是资源分配的最小单位，线程是CPU调度的最小单位”，但这句话到底什么意思，能解释清楚的人不多。我换个角度说：进程像一条生产线，有自己的厂房、设备、原料仓库，而线程是这条生产线上的工人。厂房和设备是进程的资源，包括内存空间、文件句柄、打开的网络连接等，工人则是真正干活的角色，它拿着CPU去执行代码。
从计算机原理的视角看，CPU本身并不知道“线程”的存在，它只认识指令流。早期的操作系统，比如DOS，同一时刻只能跑一个程序，CPU从头到尾执行一条指令流，根本不需要线程和上下文切换的概念。后来大家发现一个程序在等待磁盘I/O时CPU就闲着，太浪费了，于是操作系统引入了“并发”机制：让多个程序轮流使用CPU，谁等待I/O了，就切到另一个程序继续算。
进程在这个阶段就是并发的基本单位。但由于进程之间内存空间是隔离的，切换进程时不仅要保存CPU的寄存器状态，还要切换整个虚拟内存地址空间，也就是要换页表。页表一换，TLB（快表）直接失效，后续访存几乎都要重新查页表，代价非常大。所以后来的操作系统引入了线程，让同一进程内的多个线程共享地址空间，切换时不用换页表，成本低得多。
1.2 为什么不能只靠进程
如果并发只需要“多进程”，那线程是不是多余？现实是，多进程方案虽然隔离性好，但有两个硬伤。
第一是通信成本高。进程间通信要用管道、消息队列、共享内存、Socket这些机制，每次都要经过内核或做额外的同步，写起来也麻烦。而同一个进程内的线程天然共享内存，直接读写同一块变量就行，开发效率高很多。
第二是切换开销。一次进程切换，轻则几十微秒，重则上百微秒。对于高并发的网络服务，每秒可能要切换几十万次上下文，这个开销会被放大到不可接受。线程切换虽然也不便宜，但比进程切换省掉了地址空间切换这一步，整体开销可能只有进程切换的几分之一。
所以现代操作系统里，几乎所有大规模并发应用都是多线程模型，而不是多进程模型。比如Nginx的worker进程内部用事件循环和线程池配合，Redis虽然是单线程，但其实是“单线程 + 事件驱动”，它刻意避开线程切换的开销。这些设计的背后，本质上都是在权衡上下文切换带来的成本。
注意：并不是线程越多越好，也不是“多线程一定比单线程快”。如果任务以计算为主、CPU已经饱和，多线程反而会因为上下文切换变慢。线程的意义在于让CPU和I/O设备都能忙起来，而不是单纯“更多线程等于更高并发”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 上下文切换的完整拆解：保存、切换、恢复
2.1 上下文到底是什么
“上下文切换”里的“上下文”，英文是Context。很多人一听这个术语就发怵，其实它的含义非常朴素：CPU正在执行某条指令流，要想中途切走、之后再切回来继续跑，就必须把当前指令流的所有状态保存下来，这个状态集合就叫上下文。
具体来说，上下文至少包括这几类信息：
- CPU寄存器的值。包括通用寄存器（eax、ebx、ecx等）、程序计数器PC、栈指针SP、状态寄存器等。
- 线程的栈信息。每个线程有自己的内核栈和用户栈，函数调用链条、局部变量都在栈里。
- 浮点寄存器和SIMD寄存器状态。如果程序用到浮点运算或向量指令，这部分也必须保存。
- 如果是进程切换，还要保存页表基址、文件描述符表、信号处理信息等。
所以在操作系统的调度器眼里，每个线程就是一个“上下文实例”。调度器做的核心工作，就是从就绪队列里选一个线程，把它上次保存的上下文恢复进CPU，让指令流接着往下跑。
2.2 一次切换到底发生了什么
线程A正在CPU上执行用户代码，此时发生了时钟中断，或者A主动让出CPU（比如调用sleep、等待锁），操作系统切入内核态，调度器开始工作。大致步骤如下：
- 保存当前线程A的所有寄存器状态到A的内核栈或线程控制块中。
- 更新A的状态为阻塞或就绪，从运行队列中移除。
- 从就绪队列中按调度策略选择下一个要运行的线程B。
- 恢复B上次保存的寄存器状态，包括程序计数器，让CPU从B上次停下的位置继续执行。
- 切换页表（如果是跨进程切换）、刷新TLB。
单看每一步都很简单，但第4步“恢复”隐含一个复杂的问题：B可能属于另一个进程，那就要切换地址空间。即便B和A属于同一个进程，线程切换也要清空或部分刷新流水线，因为CPU流水线里预取的指令是A的指令，切到B之后这些预取内容全部作废。这就是为什么线程切换会带来性能损耗，不只是“保存几个寄存器”那么简单。
2.3 怎么量化上下文切换的开销
真实场景里，一次线程上下文切换大约消耗几微秒到几十微秒，看起来很小，但放大到高并发服务里就很可观。假设一个服务每秒要处理10万次请求，每次请求产生2次线程切换，每秒就是20万次切换，光切换时间就占了百分之几十的CPU。这还不算切换导致的内存访问局部性破坏和缓存失效。
所以排查性能问题时，第一步不是看CPU利用率，而是看上下文切换次数是否异常。常用的命令是：
bash复制vmstat 1
看cs列，也就是context switch。如果cs值长期达到几十万甚至上百万，说明系统在疯狂切换线程，这时候首先要怀疑线程数量太多了，或者锁竞争太激烈。
更细的排查用pidstat：
bash复制pidstat -w 1
能按进程统计自愿切换和非自愿切换次数。自愿切换是因为等待I/O或锁，非自愿切换是被更高优先级线程抢占或时间片用完。两条指标的含义完全不同，非自愿切换暴增通常说明线程数超过了CPU核心数。
3. 线程调度与线程池：把并发玩明白
3.1 调度策略：时间片与优先级
操作系统的调度器决定“下一个谁跑”，常见策略有先来先服务、短作业优先、时间片轮转、优先级调度、多级反馈队列。现代操作系统基本都用多级反馈队列，把不同优先级的线程放进不同队列，低优先级线程可能长时间得不到CPU。
这些策略对普通开发者来说不用深究，但有一个概念必须搞清楚：时间片。CPU给每个线程一小段时间，时间片用完后，时钟中断触发，当前线程被强制切换出去。时间片设置得太短，切换开销会拖低吞吐量；太长，交互式程序响应变慢。Linux默认时间片通常几毫秒到几十毫秒，具体数值取决于内核配置。
正因为有时间片，一个多线程程序在单核CPU上也能“同时”运行，只是宏观上看起来并行，微观上其实是轮流执行。这就是并发和并行的区别：并发是逻辑上同时处理多件事，并行是物理上同一时刻执行多条指令。理解这个区别，对后面设计线程池参数非常关键。
3.2 线程池核心参数是怎么定出来的
线程池能解决频繁创建销毁线程的开销问题，但配置不当也会成为性能瓶颈。以Java线程池为例，核心参数有核心线程数、最大线程数、任务队列容量、拒绝策略。很多人背过“CPU密集用N+1，I/O密集用2N”，但实际没这么简单。
从计算机原理的角度分析：核心线程数应该保证CPU尽量繁忙又不至于频繁切换。如果是纯计算任务，线程数接近CPU核心数最合适，多了反而因为上下文切换变慢。如果有I/O等待，线程在等待期间不占CPU，所以可以适当增加线程数，让一部分线程阻塞时另一部分线程继续计算。公式可以粗略估算：
线程数 = CPU核心数 × (1 + 平均等待时间 / 平均计算时间)
假设一个任务平均计算50ms，I/O等待150ms，那等待/计算比是3，8核机器上可以开到32个线程。但这只是理论值，实际还要考虑锁竞争和队列容量，最好通过压测逐步调整。
3.3 阻塞队列选择：LinkedBlockingQueue、ArrayBlockingQueue还是SynchronousQueue
线程池的任务队列选择是个容易被忽略的点。三种常见队列各有适用场景：
- LinkedBlockingQueue，无界队列（默认容量Integer.MAX_VALUE），任务积压不拒收，但可能导致内存暴涨。
- ArrayBlockingQueue，有界队列，任务超过队列容量后触发拒绝策略，内存可控，但需要合理设置容量。
- SynchronousQueue，不缓存任务的队列，每个任务必须直接被线程取走，否则阻塞。配合足够多的线程数使用，可以实现“任务直达线程”的效果。
从经验来看，默认配置别乱用无界队列。内存被打爆比丢弃任务更麻烦。如果系统允许短暂排队，ArrayBlockingQueue配合合理的拒绝策略是比较稳的组合。如果追求最大吞吐、任务本身很轻，SynchronousQueue可以避免任务在队列里滞留，但要求线程池最大线程数设得足够大。
3.4 submit和execute到底差在哪
Java线程池提交任务有两种方式：execute(Runnable)和submit(Callable/Runnable)。前者返回值是void，异常直接抛给线程处理，适合“只管执行不关心结果”的场景；后者返回Future对象，可以拿到执行结果，也能捕获任务内部异常。
有一个坑很多人遇到过：submit提交的任务内部抛异常，如果不去调用Future.get()，异常会被静默吞掉，日志里什么都看不到。排查线上问题时，如果发现某个任务没执行完还不报错，先看看是不是用了submit却忘了调用get()。这是典型的“只看原理不看实践”会踩的坑。
补充一个点：线程池里的核心线程在空闲时是否回收，不同语言、不同框架的默认策略不一样。Java的ThreadPoolExecutor默认不回收核心线程，但允许通过allowCoreThreadTimeOut(true)开启回收。像C#的ThreadPool也有一套自己的回收机制。理解自己所用语言的默认行为，才能正确配置“线程数上限”。
4. 线程安全、互斥与死锁：并发编程的三大坑
4.1 线程安全问题的本质
线程安全问题追根溯源，在于CPU执行指令并不是原子的。一行“count++”在字节码层面要拆成读主存、加1、写回三步，在多线程环境下可能交错执行，导致数据错乱。三个核心概念要记住：
- 可见性。一个线程修改了共享变量，另一个线程不一定能立即看到。因为CPU有缓存，线程操作的是缓存里的副本，不是主存。
- 原子性。一个操作在CPU执行过程中不能被中断，否则就会产生中间状态被其他线程看到的问题。
- 有序性。编译器和CPU为了优化会调整指令顺序，单线程下没问题，多线程下可能出现意想不到的结果。
Java里volatile能解决可见性和有序性，但解决不了原子性。要保证原子性，要么加锁，要么用原子类（基于CAS指令）。CAS其实利用了CPU提供的原子指令，比如x86的cmpxchg，这也是计算机组成原理课程里会讲到的硬件支持。
4.2 互斥与锁的实现思路
锁的本质是让临界区代码在同一时刻只有一个线程进入。底层的实现方式有两种主流思路：自旋锁和阻塞锁。
自旋锁是拿不到锁就原地空转循环，一直不停检查锁状态。好处是没有线程切换开销，坏处是白白消耗CPU。适合锁持有时间很短的场景。阻塞锁是拿不到锁就把线程挂起，放到等待队列里，等锁释放再唤醒。换成操作系统术语，就是把线程从运行状态转为阻塞状态，涉及一次上下文切换。
很多语言里的锁实际是混合实现：先自旋一小段时间，如果还没拿到锁，再阻塞挂起。这个自旋阈值调得好不好，直接影响性能。JVM里偏向锁、轻量级锁、重量级锁的升级路径，也是同样的思路在起作用。所以线程安全问题，终究绕回“如何用最低的成本保护临界区”。
4.3 死锁的产生条件与排查技巧
死锁的四个必要条件：互斥、持有并等待、不可剥夺、循环等待。缺一个就不会死锁。所以解决死锁的思路就是破坏这四个条件之一。实践中最常见的做法是破坏循环等待：所有线程按固定顺序加锁。
比如有锁A和锁B，线程1先拿A再拿B，线程2先拿B再拿A，就很容易互相卡住。改成统一“先A后B”，死锁就没了。
排查死锁的经验，三个步骤：
- 先用jstack（Java）或gdb（C++）导出线程栈，看哪些线程处于BLOCKED状态，等待哪把锁。
- 检查锁等待关系，画出“线程-锁”的循环图，循环出现了，死锁就到了。
- 分析代码路径，找出加锁顺序不一致的点。
我见过不少死锁案例，根因不是锁设计得多复杂，而是两个同事分别在不同模块里写代码，一个按“用户锁->订单锁”顺序，另一个按“订单锁->用户锁”顺序，合到一起就死锁了。所以团队里约定统一的加锁顺序，比任何技巧都重要。
5. 多语言线程实操：从命令行到生产环境的排查
5.1 Linux下如何查看线程和上下文
很多问题在开发环境复现不出来，必须上生产环境看现场。用到的命令其实就那几个，但用法很讲究。
查看系统整体线程数：
bash复制ps -eLf | wc -l
按进程统计线程数：
bash复制top -H -p <pid>
按线程排序找出CPU占用异常的线程：
bash复制ps -eLo pid,tid,pcpu,comm | sort -k3 -rn | head -20
查看CPU核数，决定线程池配置是否合理：
bash复制lscpu | grep "^CPU(s)"
如果线上环境不方便装额外工具，上面这些系统自带命令就够用了。有一点要注意：top的%Cpu(s)里还有si、hi这种软硬中断开销，如果si特别高，可能是网络中断太密集，这时候调线程池参数没意义，要找网卡队列的问题。
5.2 不同语言里线程的差异
每个语言对线程的封装都不一样，但底层的线程模型都来自操作系统。
Java线程是1:1模型，一个Java线程对应一个内核线程，创建和切换成本都高，所以Java里必须用线程池。C#的Thread在Windows上也是映射到内核线程，但Task是基于线程池和异步状态的轻量级调度。Go的goroutine是M:N模型，多个goroutine复用少量内核线程，由Go运行时自己调度，这其实是在应用层模拟了操作系统的调度器，把“上下文”做成了用户态切换，成本比内核线程低一两个数量级。
C++的std::thread也是1:1模型，但很多高性能服务会自定义用户态协程。Linux的clone系统调用可以控制子任务共享父进程的哪些资源，这是C++层面实现灵活线程模型的基础。
这些差异不是纯粹的语言之争，而是“线程调度该放在内核态还是用户态”的取舍。内核态切换功能完整但开销大，用户态切换成本低但需要自己管理所有状态——这又回到了上下文保存与恢复的核心问题。
5.3 Windows和JDK工具下的线程视角
Windows环境下查线程，任务管理器不够细，推荐用Process Explorer（微软官方工具）。它能列出进程内所有线程的CPU占用、线程ID、栈信息。排查“CPU居高不下但不知道是哪个线程”的问题时，比任务管理器好用太多。
Java应用还可以直接用JDK自带工具：
bash复制jps # 找Java进程
jstack <pid> # 导出线程栈
jstat -gcutil <pid> # 看GC情况
jstack是排查死锁和线程阻塞的神器，里面能看到线程状态（RUNNABLE、BLOCKED、WAITING、TIMED_WAITING）、等待的锁对象、调用栈。遇到高CPU问题时，用top -H找到线程ID，转成十六进制后去jstack里搜，能快速定位是哪段代码在空转。
5.4 常见线程问题排查速查表
| 现象 | 可能原因 | 排查命令/工具 | 处理思路 |
|---|---|---|---|
| CPU高但业务吞吐低 | 线程数过多、频繁上下文切换 | vmstat看cs列、pidstat -w | 调低线程池数量，减少锁竞争 |
| 线程阻塞不执行 | 锁竞争、I/O等待 | jstack看BLOCKED状态 | 优化锁粒度，缩短临界区 |
| 内存持续增长 | 无界任务队列堆积 | jstat / 堆dump | 改用有界队列，设置拒绝策略 |
| 死锁导致服务卡死 | 加锁顺序不一致 | jstack找循环等待 | 统一加锁顺序，引入超时机制 |
| 线程突然消失 | 线程池拒绝任务、异常未捕获 | 日志 + Future.get | 检查异常处理，配置监控告警 |
这张表是我平时排查问题的最小集合。很多问题不用上复杂的APM工具，先看系统指标、再看线程栈，基本能定位到根因。
6. “上下文”不只是操作系统概念：执行上下文、图形上下文与AI上下文
6.1 不同领域中的“上下文”其实是一家人
“上下文”这个词在计算机领域到处出现，但很多初学者会被搞混。操作系统里的线程上下文、JavaScript的执行上下文、OpenGL的GL上下文、AI大模型里的上下文窗口，名字都叫Context，本质却有共通之处：都需要保存和维护“当前运行所需的状态和环境信息”。
以JavaScript为例，你问“this指向的是运行时环境对象，是执行上下文吗”。答案是：this是执行上下文的一部分，但不是执行上下文的全部。JS的执行上下文包含变量环境、词法环境、this绑定、outer引用，函数执行时会创建新的执行上下文，栈式管理，函数执行完就销毁。这和操作系统线程切换时“入栈、出栈”的思路几乎一模一样。
图形学里的GL上下文类似。OpenGL的上下文保存了当前的所有状态，包括着色器程序、纹理绑定、混合模式、视口大小等。这也是为什么Cesium和Three.js共享一个WebGL上下文时，需要保存和恢复状态，否则一个库改了混合模式，另一个库的渲染结果就全错了。这种“共享上下文导致状态污染”的问题，和线程共享内存导致的线程安全问题，本质上是同一个问题在不同场景下的表现。
6.2 AI大模型的上下文窗口也是一种上下文
大模型经常说“上下文长度”“上下文爆了”。这里的上下文指模型能看到的token序列，包括用户输入的对话历史、工具返回的结果、系统提示词。模型每次预测下一个token时，只能基于上下文窗口内的内容，超出窗口的部分看不到也记不住。
这和线程上下文有相似之处：线程被切走后再切回来，如果上下文保存不完整，执行结果就错了；模型如果在对话中丢失了关键上下文，回答质量也会崩。只是线程切换的上下文是硬件状态，AI的上下文是可推理的文本序列。
为了解决“上下文窗口有限”的问题，出现了上下文压缩、历史摘要、向量检索召回等做法。原理也很朴素：把已经说过的话做摘要，把不重要的信息丢出去，把最相关的知识通过检索重新拽回来。这个过程可以类比操作系统里的缓存替换策略：缓存空间有限，就按一定算法淘汰旧数据，保证新数据能放进去。
6.3 上下文管理带来的启发
我越来越觉得，学习线程和上下文切换，不只是为了应付面试，而是建立一种“状态管理”的思维方式。从操作系统到编程语言，从图形引擎到AI应用，只要涉及并发、复用、有限资源，就一定会出现“如何保存、恢复、淘汰状态”的问题。
比如共享数据库连接、共享HTTP客户端、共享线程池，本质上都是“多用户复用同一份有限资源”，都需要通过排队、超时、容量限制来控制状态冲突。你理解了操作系统怎么管理上下文，再看这些分布式组件，会发现很多设计都似曾相识。
7. 高频问题与避坑经验
7.1 线程池阻塞队列选型错误导致线上故障
有次排查一个库存服务的内存暴涨问题，发现线程池用的LinkedBlockingQueue无界队列，任务提交量短时间飙升了几十倍，线程池处理不过来，任务全堆在队列里，最终堆内存被打爆。从原理上分析，无界队列能兜住所有任务，但代价是任务积压不会触发拒绝策略，服务表面“正常”，实际上已经濒临崩溃。
正确做法是改用ArrayBlockingQueue，容量设置成“每秒钟能承受的峰值任务数 × 容忍的等待秒数”。同时配置好拒绝策略，记录丢弃的任务数并报警。队列不是越大越好，它缓冲的是瞬时峰值，而不是无限积压。
7.2 上下文切换太高不一定是坏事
有时候你看到cs列很高，第一反应是线程太多，但其实要看具体场景。如果系统里本来就有大量短生命周期任务，比如每个请求都会创建一个线程池任务，即使单核CPU，cs数也会很高，因为任务本身执行时间极短，切换频率自然高。
更稳妥的排查方法是看每秒有效请求数。如果请求量确实很大，高cs是正常的；如果请求量不大，cs还居高不下，那才有问题。先看业务指标，再看系统指标，别顺序反了。
7.3 AI应用里的上下文“用量满了”怎么办
最近不少人问AI工具上下文满了怎么办。虽然领域不同，但处理思路可以借鉴操作系统：先确认时间线，哪些历史信息还有用，哪些可以精简。通用做法是让模型先把之前的对话总结成几条要点，再在新会话里把要点贴进去作为background，相当于把完整上下文“压缩”成摘要，再塞回上下文窗口。
这和操作系统里“淘汰旧页、保留热页”的思路很接近。真正需要长期保留的信息，应该放到外部存储里（比如向量数据库），而不是堆在对话上下文里。上下文窗口不是内存，它是“工作集”，工作集放不下的东西，要么换出，要么压缩。
7.4 排查线程问题的时间线模板
线上排查线程问题，我的固定顺序：
- 先看全局：uptime看负载，vmstat看runnable队列长度和cs值。
- 再看进程：top按CPU排序，找异常进程。
- 深入线程：top -H找线程，记录高CPU线程ID。
- 导出栈：jstack或gdb，把线程ID转成十六进制，搜索对应栈。
- 结合日志：看看这个线程所在业务模块最近有没有超时、报错、堆积。
- 看GC：Java应用顺便看一眼GC线程是不是频繁Full GC，GC本身也会导致线程停顿。
这套流程基本能覆盖90%的线程问题。我踩过的坑是：一开始直接上jstack，没有先看全局指标，结果线程栈是抓到了，但不知道是因为GC停顿还是锁竞争导致的，又得回头补数据，浪费了不少时间。正确的顺序是从系统到应用，从宏观到微观。
回到开头那个问题：线程切换到底在干什么。其实一句话就能说清楚：CPU把当前正在执行的任务状态完整保存下来，再恢复另一个任务之前保存的状态，让多个任务在一条物理流水线上轮转执行。但这句话背后藏着的知识量，足够牵扯出操作系统的调度器设计、CPU缓存体系、并发编程的同步机制，甚至还能延伸到AI模型的上下文管理。
有一点我自己的体会是要反复强调的：原理不是背出来的。你在jstack里看到BLOCKED状态，再回忆起操作系统里的阻塞队列；你在调线程池参数时想到上下文切换开销，再去翻讲调度的章节，原理才真正变成了你自己的东西。计算机原理这门课，工作五年后回头看，跟当时期末复习时看到的完全是两本书。