线程和进程这两个词面试题里常青树搜索引擎里常客实战代码里更是天天见。我入行那几年被“进程和线程的区别”问过不下十次自己也背过八股答案可真到线上排查问题才发现教科书那几句“进程是资源分配的最小单位线程是CPU调度的最小单位”根本不够用。后来陆陆续续做过好几轮高并发服务改造、进程守护脚本、线程池调优把概念踩成经验才渐渐理解这两个东西到底是什么关系为什么说线程是进程的“子集”为什么共享内存的线程要小心死锁为什么虚拟线程能革了传统线程模型的命。这篇文章我不打算给你报教科书式定义也不整“三次握手、四层模型”那种大而全就围绕“线程和进程的区别和联系”这条主线把我在项目里实际遇到过的场景、排查过的坑、调整过的参数全部摊开来讲。既有基础示意也有实战代码还有踩坑记录。适合刚接触并发编程的同学建立框架也适合已经写过几年代码但被线程池、死锁、IPC 折腾得想翻桌的朋友直接拿去对照。1. 先建立心智模型进程是房子线程是住在屋里的人1.1 为什么必须把“资源”和“执行”分开理解讲进程和线程的区别网上最常见的解释叫“进程是资源分配的最小单位线程是CPU调度的最小单位”。这句话严格来说没问题但太干干到初学者背完就忘。我习惯用一个带生活气的类比进程是一套房子线程是住在房子里干活的人。房子有产权证、有面积、有水电煤独立计量这些对应进程的资源——地址空间、文件描述符、堆栈、全局变量。每个进程从操作系统拿到的这套“房产”是独立隔离的进程A的地址空间进程B默认碰不到这保证了系统里一个程序崩溃不会把另一个程序的地基也炸了。线程则是房子里的人。人可以共用客厅、厨房、厕所这些公共区域也就是同一个进程地址空间里的代码段、数据段、堆。但每个人自己也有独立的“私人物品”——线程栈、寄存器状态、程序计数器。这就是线程上下文是线程能独立被调度执行的前提。一个人干活干到一半要被换下去操作系统只需要把这个人身上的随身物品保存好把另一个人的随身物品装回来这就是上下文切换。这套模型的好处是你能直观解释为什么线程创建比进程快、线程切换比进程切换轻、线程之间通信方便但容易互相踩脚。房子之间打电话要绕物业IPC屋子里的人喊一嗓子就行共享内存但喊话如果没约定好容易被隔壁房间的人接错话头这就是数据竞争。1.2 地址空间与执行流一句话区分进程和线程我再给一个更严谨的版本适合你写进笔记里进程是操作系统分配资源内存、文件、信号量等的容器线程是进程内部可独立调度执行的执行流。进程是静态的容器线程是容器里面真正跑起来的执行流。写代码的时候这种感觉最明显。你启动一个 Java 程序操作系统先创建一个进程从这个进程的 main 主线程开始执行。在 Java 里手动 new Thread()其实是在创建进程内部的新执行流而不是新进程。用 jps 看 Java 进程一个应用就是一个进程 id哪怕里面开了 200 个线程也仍然是一个进程。Linux 下可以用 ps -eLf 看线程视图你会发现线程的 PID 和主进程 PID 是一样的但 LWP轻量级进程编号不同。这个 LWP 概念就很有意思Linux 内核里压根没有完全独立的线程数据结构它把线程实现为“共享地址空间的进程”叫轻量级进程。所以从内核角度看你创建 10 个线程相当于创建了 10 个共享同一套地址空间的“特殊进程”。这也就是为什么很多教材说线程是“轻量级进程”。但我们在用户态应用层编程时千万不要真把线程当进程处理否则你会搞混资源边界。1.3 没有进程的线程和没有线程的进程把关系再往深捋一层线程必须依附于某个进程存在。进程是线程的宿主线程是进程的执行体。一个进程至少有一个线程通常叫主线程。主线程如果退出了整个进程一般也就结束了因为进程的执行流没了。反过来进程可以没有线程吗严格说Linux 下进程创建后必须有主线程因为 exec 之后总要有一条指令开始执行。但有一种“僵尸进程”状态进程已经结束执行只留下 PCB 等资源描述信息等父进程回收这种状态下的进程从执行流角度已经“没线程了”但资源占位还在。我当年排查过 Node 服务里的僵尸子进程ps -ef能看到一堆 defunctCPU 占用 0内存只占一点点却堵住了 shell 脚本的进程回收逻辑就是因为父进程没有正确 wait 子进程。这恰好是“进程和线程联系”里最容易被忽略的一环进程的创建与回收不只是 fork/exec/exit 的问题还涉及父进程承担回收义务。后面讲守护进程时还会再提到。2. 资源和调度为什么线程切换开销小却容易惹麻烦2.1 上下文切换的成本对比进程切换时操作系统要切换虚拟内存地址空间这涉及页表切换TLBTranslation Lookaside Buffer缓存基本全部失效下次访问内存要重新走页表翻译。代价非常昂贵。线程切换发生在同一进程内地址空间没变TLB 大部分能保留要切换的只是寄存器、栈指针、程序计数器等线程上下文开销小一个数量级。这就是为什么高并发场景默认用多线程而不是多进程。但记住我说的是“默认”。极端情况下如果线程只做 CPU 密集计算且频繁争抢锁线程切换带来的 cache miss 和内核态进入成本叠加仍可能让多线程不如单线程。Go 的 GOMAXPROCS 在部分纯计算场景调到 1 反而更快就是这个道理。所以线程“轻量”不等于“无脑用就更快”。2.2 独立还是共享一张表看清差异我整理了一份常用对照表覆盖我平时面试别人时最常考的几个维度对比维度进程线程资源拥有独立地址空间、独立文件表、独立信号处理器共享进程地址空间、共享文件表、共享信号处理器调度单位进程是资源分配单位但线程才是被调度的执行体内核或用户态调度器直接调度线程创建开销fork/exec 开销大涉及资源复制或写时复制pthread_create 开销小只需分配栈和线程描述符切换开销高页表切换、TLB 失效低寄存器级上下文切换通信方式需管道、Socket、共享内存、消息队列等 IPC直接读写共享变量/内存但需同步机制隔离性强一个进程崩溃不影响其他进程弱一个线程非法访问会让整个进程崩溃生命周期独立生命周期随进程存在进程没了线程自然消失这张表背后对应着工程选型逻辑要隔离、要安全上进程要并发、要灵活上线程。后面第 6 章会结合实例展开。2.3 共享内存的代价原子性、可见性、有序性线程之间共享地址空间带来便利也带来三座大山——原子性、可见性、有序性。原子性指一个操作要么全部发生要么全部不发生比如 i 在 CPU 层面是读改写三步线程 A 读 i10线程 B 同时读 i10各自加 1写回结果可能是 11 而不是 12。可见性指一个线程修改了共享变量另一个线程可能因为 CPU 缓存还没来得及看到最新值这就是 Java 里为什么要加 volatile 的原因之一。有序性指编译器重排、CPU 乱序执行可能让代码实际执行顺序和源码不一致。把这三座大山对应到进程模型就会发现进程间共享内存很麻烦反而天然隔离不会遇到这种问题。但线程模型为了性能把地址空间共享了就必须引入锁、原子类、内存屏障这些机制来“补漏”。这就是为什么说进程和线程的联系不仅是“线程寄生在进程里”更是“共享资源需要在并发访问时付出额外同步成本”。成本划不划算要看业务场景。IO 密集任务线程等待 IO 时可以被切走用异步或虚拟线程更合适CPU 密集且数据互相依赖的任务锁竞争导致线程频繁阻塞反而可能不如拆成多个无共享数据的进程各自算。3. 实战一线程池配置、阻塞队列与线程中断踩坑记录3.1 ThreadPoolExecutor 的七个参数我劝你不要背要算Java 里最常用的线程池就是 ThreadPoolExecutor构造函数七个参数核心线程数 corePoolSize、最大线程数 maximumPoolSize、空闲存活时间 keepAliveTime、时间单位 unit、阻塞队列 workQueue、线程工厂 threadFactory、拒绝策略 handler。我见过很多人直接new ThreadPoolExecutor(10, 20, 10, TimeUnit.SECONDS, new LinkedBlockingQueue())一把梭核心线程 10最大 20无界队列。看起来简单实际隐藏问题无界队列意味着当核心线程全忙后续任务全部堆积在队列里最大线程数永远不会超过核心线程数等于 maximumPoolSize 没生效。极端情况下队列堆积几十万任务内存爆掉。正确做法是先评估任务类型。如果是 IO 密集任务比如 HTTP 调用、数据库查询线程大部分时间在阻塞等待核心线程数可以设得较高经验公式大约是 CPU 核数乘以 2。如果是 CPU 密集计算线程数最好接近 CPU 核数加 1避免过线程切换浪费 CPU。我这里说的“经验公式”不是银弹只是让你有个起步值最终要压测。我当时做订单状态同步服务8 核机器IO 密集先用 16 核心线程起步压测后调到 24整体吞吐提升明显但继续往 32 加就开始下降因为锁竞争和调度开销盖过了并发收益。参数配置背后要理解线程池的工作流程提交任务时如果当前线程数小于核心线程数创建新线程执行否则先放入阻塞队列队列满了才尝试创建新线程直到最大线程数再满触发拒绝策略。所以你在配置时核心线程和最大线程之间的差值是给突发流量预留的“缓冲余量”阻塞队列的长度则是让任务“排队”的容量。合理设置是队列长度根据该任务最长阻塞时间和平均请求速率估算大约等于速率乘以可接受的最大排队延迟。拒绝策略默认 AbortPolicy 直接抛异常生产环境我更喜欢 CallerRunsPolicy超出部分回退给提交任务的线程执行至少能抑制任务整体积压。3.2 内置阻塞队列怎么选ThreadPoolExecutor 常用队列有四种LinkedBlockingQueue、ArrayBlockingQueue、SynchronousQueue、PriorityBlockingQueue。前两个好理解一个有界性可配置一个固定有界SynchronousQueue 这个名字有点迷惑它其实不存储任何元素每个 put 必须等待一个 take相当于线程池内部只做“直接交接”无任务缓存。我踩过一个坑某服务用 SynchronousQueuemaximumPoolSize 设了 200结果任务陡增时直接创建了两百个线程线程数飙到 200 只是表象CPU 上下文切换率暴涨接口 RT 直接翻了 10 倍。后来我换成了带容量的 LinkedBlockingQueue比如容量 500maximumPoolSize 设 50流量波峰时任务先排队宁可响应延迟增高也不能让系统瞬间被线程淹没。线程池的意义从来不是“无限并发”而是“限流削峰”。还有个常见问题队列要不要有界、有界容量多大取决于你是否允许任务丢失。业务中查找“某用户待处理事件”的任务如果丢了会影响最终一致性就用有界队列配合 CallerRunsPolicy宁可提交者慢一点也不让任务直接丢弃。日志上报类任务则相反可允许丢弃用 DiscardOldestPolicy 比较合适优先保住最新日志。3.3 线程死锁从“互相等人”到“让线程定时汇报”死锁是线程和进程共享资源后最容易踩的坑之一。用一个小例子说明线程 A 持有了锁 1等待锁 2线程 B 持有了锁 2等待锁 1。两个线程互相等待谁也不放手程序假死。如果只是这两个线程还好jstack 能看到 Found one Java-level deadlock但现实里死锁往往更隐蔽往往是三层锁嵌套、循环等待。治理方案我总结了四条。第一加锁顺序全局一致所有代码都按同一顺序获取多个锁这是从源头避免循环等待。第二使用 tryLock 带超时拿不到锁就不死等Java 里用 Lock 接口的 tryLock(3, TimeUnit.SECONDS)等不到就放弃并记录日志。第三定期监控线上用 ThreadMXBean 定时抓线程栈检测 BLOCKED 状态线程数量和持锁情况超过阈值就告警。第四压测时故意制造并发高峰让死锁提前暴露。有个小技巧我习惯给线程池里的线程设置有意义的名字比如订单线程池、推送线程池。死锁时 jstack 出来一眼就能分清哪个业务点出了问题。如果全叫 pool-1-thread-1排查起来像在黑暗里摸钥匙。3.4 线程中断为什么 InterruptedException 这么难缠Java 里 Thread.interrupt() 不是“立刻杀死线程”而是给线程设置一个中断标志位。线程如果正阻塞在 sleep/wait 上会抛出 InterruptedException如果正在执行 CPU 计算不会中断需要代码里自己判断 Thread.currentThread().isInterrupted()。很多新手在 catch InterruptedException 之后直接吃掉异常既不处理也不恢复中断标志这样做导致的坑是外层代码再检查中断标志时发现没被标记中断逻辑失效。我自己的规范是如果业务代码不准备响应中断至少在 catch 里调用 Thread.currentThread().interrupt() 恢复标志位如果是要真正退出线程则清理资源后 return。线程池里执行任务时也同理如果任务被强制 shutdownNow()正在等待的线程会收到中断信号。这时候应该让任务尽快释放锁、关闭文件、返回结果而不是继续闷头跑完。4. 实战二IPC 与守护进程的现场复盘4.1 进程间通信到底用哪种进程间通信的常见方式有管道、FIFO、System V 消息队列、共享内存、信号量、Socket、信号。选择依据一句话若只是父进程往子进程传数据管道就够若多个进程频繁交换结构化数据共享内存加信号量性能最高若要跨机器通信Socket 天然合适。我最常用的是共享内存配信号量。共享内存速度快各大消息中间件底层都在用但任务要自己处理互斥。有一次排查线上两个采集进程偶发读脏数据的问题就是用 System V 信号量做互斥读端等待写端释放后进行内存复制解决了并发读写错乱。如果项目里不用 C/CJava 里做 IPC 一般走 Socket 或文件。Java 本身不直接暴露 SysV IPC要用 JNI 或框架。实际项目里我更多用 Unix Domain Socket性能比 TCP loopback 高配置也简单。4.2 守护进程与会话为什么 nohup 不是万能的Linux 守护进程的概念核心是脱离终端会话。普通进程如果终端退出会收到 SIGHUP 信号默认动作是终止进程。nohup 的作用是忽略 SIGHUP但如果你在 bash 里执行nohup python app.py app.log 21 这个进程仍然可能是会话的首进程终端退出后 shell 会向会话中的所有进程发送 SIGHUP虽然 nohup 帮你忽略了但有些依赖终端的程序还是可能出问题。真正规范的守护进程要调用 setsid() 创建新会话使进程完全脱离控制终端再把工作目录切换到根目录重定向标准输入输出到 /dev/null 或日志文件。这个逻辑被 toolsets/supervisord/systemd 封装过了。现在生产环境我几乎不用 nohup直接用 systemd 的 Unit 管理进程至少日志清理、开机自启、崩溃恢复都省心。不过有一次客户环境没有 systemd我只好写了个 C 语言小程序封装 daemon() 再调用业务进程效果也一样。4.3 进程名修改prctl 与 /proc 的实战Linux 默认进程名来自可执行文件路径或 argv[0]。遇到需要区分多个同名进程时修改进程名很实用。C 里用 prctl(PR_SET_NAME, worker_1)Python 里可以使用 setproctitle 库。Java 里只能通过修改 sun.java.command 属性而且没那么直接。我写过一个小工具调用 prctl 改进程名同时通过 /proc/PID/comm 查看改名是否成功。有个细节Linux 进程名限制为 15 个字符超过会被截断。最近几个朋友搜索linux 修改进程名称 大于15个字符问怎么绕过。改的是 comm 文件内核限制就摆在那一层。如果你需要更长描述性名称建议写到 /proc/PID/cmdline 里即修改 argv[0] 或者稍微 hack 一下环境变量很多监控系统优先读 cmdline。我当年给批量任务进程取名格式固定为worker_orders_2024_071216 个字符comm 显示只有worker_orders_2排查时发现多个同名被截断进程没法区分后来统一改成wo_20240712短而可识别问题解决。4.4 进程等待 wait僵尸进程的悲剧根源关于“进程等待 wait”我讲一个真实案例。脚本里通过 subprocess 启动几个子进程如果父进程没有 wait子进程结束后就会变僵为僵尸。僵尸进程不占内存但占用 PID当 PID 耗尽时系统可能无法创建新进程。在 C 里fork 子进程后必须调用 wait/waitpid 回收在 Python 里subprocess.Popen 对象如果长期不调用 communicate() 或 wait()子进程也可能残留。另一个常见做法是采用 SIGCHLD 处理器自动回收子进程在 handler 里循环 waitpid(-1, status, WNOHANG)这样父进程就不用一直阻塞等待。shell 脚本里也可以用 wait 命令等待多个后台任务适合批处理场景。5. 热点补课虚拟线程、自由线程和“线程安全”的本质5.1 虚拟线程到底动摇了什么Java 21 正式带出了虚拟线程很多朋友搜索“虚拟线程原理”一头雾水。简单理解传统线程是一一映射到操作系统线程的数量一多OS 线程创建成本和切换成本就高。虚拟线程是 JVM 层面模拟出来的“用户态线程”也叫协程或纤程。它把上万甚至几十万个轻量任务塞到少数几个 OS 线程载体线程上执行遇到 IO 阻塞时虚拟线程会被自动让出载体线程去跑别的虚拟任务阻塞恢复后再回来。等于线程模型里套了一层调度系统。为什么以前 Java 做高并发常规要靠线程池因为 OS 线程贵。而虚拟线程的语义希望让每个任务都有独立线程不用再为了省线程而费尽心思封装异步回调。虚拟线程的阻塞不再高昂因为它会释放底层载体线程。所以在典型 IO 密集型 Web 服务中虚拟线程能让吞吐量提升明显。不过虚拟线程不能无所不能CPU 密集场景没有收益加了 synchronized 等 native 代码时可能被载体线程“钉住”这个问题 JDK 后续版本也在优化。5.2 “自由线程”到底自由在哪里“自由线程”这个词近几年在部分编程语言和框架里频繁出现。它指的不是无锁并行而是“解释器和运行时允许同时执行多个线程”不再被全局解释锁卡住。典型就是 Python 社区在讨论的自由线程版解释器。以前 Python 的多线程受 GIL 限制同一时刻只有一个线程执行 Python 字节码所以 CPU 密集任务用多进程。自由线程版本的目标是移除或大幅降低 GIL 粒度允许多个线程并行利用多核。工程上的影响是现有依赖了大量线程安全假设的 C 扩展代码可能受到影响。很多库 API 的全局锁依赖 GIL 保护数据。所以自由线程不是简单撤掉锁而是重新设计运行时数据结构的线程隔离机制。这个话题很新如果你只是写写 Python 脚本建议暂时观望如果你是做数据分析框架的维护者就得开始编译测试 Py 3.13t 等自由线程分支了。5.3 AtomicInteger 线程安全吗别把“线程安全”理解得太绝对网上搜索“atomicinteger线程安全吗”的人多半是在纠结并发计数递增。AtomicInteger 基于 CAS在无锁情况下保证单个 getAndIncrement 操作是线程安全的。但注意“单个操作安全”不等于“业务逻辑安全”。例如if (atomic.get() 100) { atomic.incrementAndGet(); }这两个操作组合并不是原子的。并发请求可能同时读到 99都进入判断最终把计数推到 101。要修需要 CAS 自旋或者直接用 synchronized 包住整个逻辑。这就是我说的“不要神化原子类”。把这个道理推广到进程层面也一样进程间用共享内存通信如果每个进程对信号的读改写不是原子的也会出现类似错乱。所以无论线程还是进程并发协作的核心都是找出“临界区”并保证“互斥”或“原子性”。这也是进程与线程殊途同归的地方——资源访问共享时都要解决同步问题。6. 选型与经验总结到底什么时候用进程什么时候用线程6.1 选型口诀隔离要进程并发要线程我把选型逻辑浓缩成一句口诀别让线程承担“隔离”职责别让进程承担“高频数据共享”职责。如果你的业务或模块崩溃会影响主应用值得把它拆成独立进程哪怕进程通信困难一些也要做因为故障隔离的收益大于通信成本。如果是同一业务的数据并行处理频繁读写同一批内存对象那就用线程加锁而不是先序列化再用进程管道传数据否则吞吐会垮。举个我自己项目的例子一个数据同步服务主进程负责批量拉取数据子进程负责清洗入库。子进程崩溃时不能拖垮主进程所以用多进程模型进程间通过消息队列传清洗后的批次。但清洗逻辑内部同一个批次内的多个文件下载任务并发执行用线程池。进程负责边界隔离线程负责加速各司其职。6.2 踩坑清单UI 线程、进程无法关闭、后台进程狂占资源这个部分我当成“实战排雷手册”写给大家。首先说安卓里 Fragment 开线程的经验。在 fragment 里直接 new Thread 操作耗时任务如果数据库、网络回调接口没有 Activity 生命周期感知很容易出现页面销毁后线程还在跑回调里更新 UI 直接崩。规范做法是用生命周期感知的 ViewModel 协程或者 HandlerLooper 回到主线程操作 UI。如果是易语言或其他 GUI 环境子线程不能直接操作主线程 UI 控件必须通过消息队列把 UI 操作交给主线程执行。这背后就是线程模型的设计限制。然后是被无语到极点的“wps进程无法关闭”问题。很多办公软件会常驻后台进程任务管理器结束进程后又被文件关联唤醒。这种大多是因为安装了后台服务或升级器。你可以在计划任务和注册表里禁用自启动也可以卸载后手动清理服务项。技术细节不深但值得提醒一句如果只是临时要完全退出软件杀掉主进程后还得结束常驻托盘进程这种进程名和主程序相似但不完全一样。最后说说排查“后台进程 CPU 狂飙”。经验是先分清是哪个进程用 top -Hp PID 看线程级 CPU再配合 jstack 导出线程栈。比如之前 msmpeng.exe 占 CPU 极高是微软杀毒在做扫描我一般临时排除大目录JVM 进程 CPU 高多数是 GC 频繁或死循环线程jstat -gcutil 看 GC 时间如果 Young GC 每秒几十次说明堆太小或对象分配太快调堆大小不如修代码里的循环创建对象问题。6.3 实操心得main 线程等待所有任务完成的两种思路搜索“java线程等待都完成”时第一反应可能是 Thread.join()第二可能是 CountDownLatch第三是 CompletableFuture.allOf。三种我都用过用场景区分简单短任务join 最直观多个任务并行且要统一结果时CountDownLatch 可以用但每减一次 countDown 就要小心异常时是不是少减了漏减会导致永久等待。我踩过这个坑某定时任务里循环提交 100 个任务其中一个抛异常直接退出countDown 没执行主线程 await 永远停在原地定时任务从此不再执行。修复方式很粗暴finally 中确保 countDown但代码丑。后来换成 CompletableFuture.allOf配合 exceptionally 处理异常代码简洁多了。这也算“进程等待 wait”思想的线程版无论在进程还是线程层都要保证“等待”路径不会被异常截断。7. 写在最后的几个反直觉结论学进程和线程最难的不是记忆而是接受一些反直觉的结论。第一个反直觉线程越多系统不一定越快。线程是并发的最小单位但每个线程的切换都有成本。压力上来时盲目扩线程反而可能让吞吐降低。所以我常用“先压测再调参”的方式验证。第二个反直觉线程池参数不是固定值而是动态值。流量模型变了核心线程数也该变。我在生产环境做过动态调整低峰期 8 个核心线程高峰期动态扩展到 20 个靠的是监控线程池 activeCount 和队列深度。遇到任务积压持续超过阈值就调大 maximumPoolSize核心线程数一般不动避免频繁收缩产生波动。第三个反直觉进程隔离和线程共享之间没有绝对最优只有场景适配。用 cgroup 控制进程带宽也好用队列做线程限流也好都是为了找到系统资源与业务延迟之间的平衡点。你如果问我一开始从哪里下手我会说从画图开始把业务拆成“哪几条执行流必须顺序执行”“哪几组可以并发”“哪些数据会被多个执行流访问”画完这张图进程还是线程、锁还是 CAS、队列还是信号量心里基本就有数了。我自己这些年用下来最深的体会是面试时能背出概念只是第一步真正让别人认可你懂是你能说出“为什么线程切换比进程切换快”“为什么死锁要加锁顺序一致”“为什么线程池队列要用有界队列”。这些“为什么”都藏在资源模型、共享成本和边界隔离的关系里。把这层关系吃透再去写代码你自然会在并发编程和进程管理中游刃有余。如果这篇文章能帮你少踩一个死锁的坑少排查一次进程假死我觉得就值了。最后再分享一个小技巧给你的线程池、进程脚本都起有意义的名字写进日志。排查问题时别人在一堆 pool-1-thread 里抓头你直接 grep 自己的业务线程名几秒钟定位到问题。这个习惯虽然小长期下来节省的时间相当可观。
