做后端这几年被问得最多的一个话题就是并发多线程。从新同事问“线程和进程到底什么区别”到面试里对方聊“这套高并发IM的系统是怎么设计的”再到现在做AI Agent的团队跑过来说“一上量并发就崩”。不管技术热点怎么轮转并发多线程始终是所有后端工程师绕不开的一座大山。这篇文章把我这些年对并发多线程的理解、踩过的坑、以及在不同语言里的实践揉在一起讲一遍。你会看到Java多线程、Python多线程、Swift并发安全、Qt多线程各自的门道也会看到高并发场景下生产者消费者、数据库并发锁、Nginx连接数这些关键点是怎么串联起来的。适合刚接触多线程的小白也适合准备多线程面试题或者正在做高并发改造的工程师对照参考。1. 想清楚再动手并发和多线程到底是什么关系1.1 并发不等于并行先统一概念我见过太多人把并发和并行当成一回事结果一聊就露馅。并发concurrency指的是系统同时处理多个任务的能力强调的是“交错执行”而并行parallelism指的则是同时执行多个任务强调的是“多核同时干活”。用食堂打饭来类比一个阿姨给好几个窗口轮流转着打菜这叫并发三个阿姨同时开三个窗口各打各的这叫并行。并发可以在单核上用时间片轮转实现并行必须有硬件上的多核支撑。这个概念上的区分有人觉得是抠字眼但工程上它直接决定优化方向。你看一家系统自称支持一万并发可能是靠事件循环把一万个请求轮流调度每个请求都在等待状态也可能是真的开了几百个线程分布在多核上跑。两者对CPU、内存、文件描述符的消耗完全不同排查问题的切入点也完全不一样。我之前接手过一个号称高并发的服务一看代码里所有请求都阻塞在线程池上线程池还是默认参数所谓高并发只是压测时用了短连接大量复用真实业务根本撑不住。1.2 线程与进程别把房子和房间搞混进程是操作系统分配资源的基本单位线程是CPU调度的基本单位。我习惯把进程比作一栋楼有独立的水电、燃气和物业线程是楼里的房间共享整栋楼的公共设施但每个房间自己又有独立的座椅板凳。Java里你new一个ThreadPython里调用threading.ThreadSwift里创建Task本质都是在这栋楼里开新房间。这个比喻能解释很多现象。一是开销开进程比开线程重得多因为要划分整栋楼的资源二是通信线程之间共享堆内存传数据很方便但正因为共享才有数据竞争问题三是崩溃影响一个线程因访问非法内存崩溃往往直接把整个进程带走这也是多线程系统比多进程系统更“脆弱”的原因。面试时很多人能背“线程共享堆、独享栈”但要他说出自己业务里哪些数据该进堆、哪些该保持线程隔离就语焉不详了。1.3 并发数到底指什么“并发数”这个词在热词里出现了好几次但它被用得太随意了。最常见的定义是系统在同一时刻处理的请求数或活跃连接数这里至少有三个口径要说清楚是1秒内的平均值是某瞬间的瞬时峰值还是持续负载下的稳态值。同一套系统按这三个口径报出来的数字能差出十倍。我在做压测的时候习惯把并发数拆成三层来看。接入层并发是Nginx或网关能同时维持的连接数应用层并发是线程池、协程或者Actor能同时处理的任务数数据层并发是数据库连接池大小以及锁能容忍的竞争程度。每一层都有自己的瓶颈点。所以当有人跑来跟我说“我们系统能扛十万并发”时我第一个反问是你说的十万是哪个层的十万连接数十万和数据库写并发十万压根是两个量级的问题。2. 跨语言的多线程形态同一目标不同解法2.1 Java多线程JMM、锁与线程池Java是多线程学习绕不开的重镇。它的核心痛点可以拆成三块内存模型JMM、锁体系、线程池。JMM解决的是可见性问题。每个线程有自己的工作内存线程A改了一个变量线程B不一定马上看得到因为写回主内存的时机不确定。volatile关键字能保证可见性和有序性但不保证原子性synchronized和Lock则在可见性、原子性、有序性上都能兜住。我排查过不少诡异的线上问题比如计数器偶尔少记、配置变更不生效最终元凶就是共享变量缺volatile线程间互相看不到更新。学Java多线程第一课不是背锁的用法而是先理解这个“为什么看不见”的问题。锁体系上synchronized是JVM内置锁从偏向锁、轻量级锁到重量级锁有自动升级过程java.util.concurrent包提供了更精细的Lock体系比如tryLock、超时中断、公平锁。我的个人经验是能用并发包工具就别自己造轮子。ConcurrentHashMap、CountDownLatch、Semaphore、CyclicBarrier这些组件已经过大规模生产验证自己用synchronized拼一个“看起来对”的集合类多半会在极端情况下翻车。线程池是Java并发里使用频率最高的组件。核心参数就那几项corePoolSize、maximumPoolSize、keepAliveTime、工作队列、拒绝策略。这里最常见的坑是队列选型。LinkedBlockingQueue如果设置成无界队列任务会无限堆积内存一点点涨上去直到OOMSynchronousQueue不缓存任务来一个必须马上开线程处理又对最大线程数要求很高。实际项目中我几乎都用有界队列配自定义拒绝策略宁可快速失败也不能让系统在毫无预警的情况下被拖到崩溃。2.2 Python多线程先看懂GIL再谈优化Python的多线程经常被拿来吐槽因为GIL全局解释器锁存在同一时刻只有一个线程能执行Python字节码。CPU密集型任务用Python多线程基本没有加速效果反而因为线程切换还要更慢。很多人一看到这里就认为Python多线程是“废的”其实不准确。在IO密集型场景下比如爬虫抓页面、读写文件、等待网络响应线程在阻塞等待IO的时候会主动释放GIL其他线程能利用这个空档继续跑。所以用Python多线程处理并发IO请求效果依然可观这也是很多爬虫框架早期能用多线程支撑几万并发的原因。但如果你要解决的是纯计算问题就该换思路用multiprocessing绕开GIL或者把热点计算下沉到C扩展、NumPy这类原生层面让计算在解释器外执行别在线程上死磕。现在做AI Agent服务Python是主力语言。这类服务的主要瓶颈从来不是CPU计算而是大量IO等待——调用大模型推理接口、检索知识库、编排工具调用几乎全程都在等网络。所以Python asyncio 协程的组合反而比裸线程更合适后面讲AI Agent高并发时会再展开。2.3 Swift并发安全从闭包到actorSwift的并发演进比Java更有意思。早期主要靠GCDGrand Central Dispatch管理队列用DispatchQueue.async提交任务配合串行队列、并发队列和栅栏函数控制访问。但GCD提供的线程安全手段比较原始开发者需要自己用锁、信号量、原子属性来保护共享状态稍有不慎就漏。Swift 5.5引入async/await和actor之后局面有了本质变化。actor是一种保护可变状态的类型编译器保证只有actor自身才能修改它的内部存储想从外部访问必须通过await调用它的方法。这在思路上和Java把并发控制交给JVM异曲同工但Swift更进一步把不变量放到了语言层面写错代码直接编译不过。做iOS和macOS开发的朋友处理并发安全我建议优先用actor同时配合Sendable协议确认值可以安全地跨并发域传递。老项目倒不用急着全量迁移但新模块最好从设计上就按并发安全来写。我见过不少Swift老代码靠DispatchQueue.sync套来套去一个不小心就把线程锁死改成actor之后逻辑清晰多了。2.4 Qt多线程信号槽与线程亲和性Qt在桌面客户端和嵌入式界面里依然很常见它的多线程有一个特别容易踩的坑线程亲和性。QObject默认在主线程创建它的所有事件处理也默认在主线程进行。如果你直接在worker线程里操作UI控件比如setText、setValue轻则界面无响应重则直接崩溃而且崩溃现场还不稳定时好时坏。正确做法是把耗时任务封装成QObject的worker对象用moveToThread把整个worker移到子线程主线程和worker之间只用信号槽通信。信号槽机制本身是线程安全的跨线程emit信号时连接类型会自动变成QueuedConnection在接收对象所在线程的事件循环里执行槽函数。这样UI操作始终发生在主线程耗时逻辑始终在子线程两者解耦。我接手过一个老旧的Qt项目代码里到处在线程函数里直接改界面每次启动都要碰运气。整改时我立了一条铁律UI操作永远在主线程工作逻辑永远在worker线程两者之间只允许走信号槽。改完以后那些时灵时不灵的问题基本绝迹。桌面开发的多线程难点从来不在“怎么开线程”而在“线程之间怎么安全地沟通”。3. 高并发应用怎么扛住压力3.1 高并发IM连接、推送和状态同步热词里“高并发im”是很典型的实战场景。IM系统的并发压力首先在连接层上万乃至百万级的长连接非常常见。长连接本身消耗的是内存和文件描述符单台机器能承载的连接数有限所以IM架构几乎都是网关层做连接收敛业务层做消息路由两层之间通过内部协议转发。真正把IM做难的是消息推送和顺序保证。新消息产生后如果直接逐条给每个在线成员写入数据库或者推送峰值一上来数据库就扛不住。高并发IM的常用做法是批量聚合先按会话维度把消息攒一批再一次性推给在线成员离线用户则走离线存储等上线后再拉取。消息的顺序性则靠序列号来保证同一发送者的一系列消息必须按序到达接收端根据版本号对乱序消息做校正。再补充一个很多人忽略的点离线消息的投递状态。用户不在线时消息不能丢在线推送成功和离线持久化成功是两个不同动作。我做过一个项目在线通道返回成功就把消息标记为已读结果用户在手机上看到消息但网页端一直没同步就是因为两个通道的状态没有对齐。后来给每条消息设计了完整的状态机pending、sent、delivered、read逐个流转才把这个坑填平。3.2 AI Agent怎么扛并发流式与异步是标准答案“AI agent 怎么扛并发”是最近被问爆的问题。AI Agent服务的并发压力不来自计算密集而来自请求的耗时结构。一次Agent调用经常要经历多轮大模型推理、工具调用、知识库检索整体耗时少说几秒多则几分钟。如果用同步阻塞的方式处理一个请求占住一个线程不放开几千路并发就能把线程池打爆。扛住并发的基本盘是异步化。接口层用async/await加流式响应SSE把首token返回时间压下去让用户感觉响应很快中层的任务编排用协程并发执行多个独立步骤比如同时检索多个知识库、并行调用多个子Agent。这里我强烈推荐事件驱动路由请求进队列工作线程消费结果通过WebSocket或SSE异步推回客户端不必一直挂着一个同步连接。限流和降级在AI场景里也是刚需。大模型API本身有每分钟调用次数限制你必须在自己的服务里做一层令牌桶去保护上游上游超时或者熔断时要有降级预案比如临时返回缓存的常见答案或者简化Agent的思考链路。我在实际项目里见过没有限流的Agent服务流量一涨上游大模型直接拒绝服务结果所有请求都堆积在内部队列里雪崩。记住AI Agent的并发上限不是由你的服务器决定的而是由你依赖的每个外部链路共同决定的。3.3 生产者-消费者模式为什么是高并发下的万金油生产者-消费者模式几乎出现在每一本多线程教材里也出现在几乎所有高并发系统里。它解决的问题本质是速率解耦生产者的产任务速率和消费者的处理速率不一定匹配中间加一个缓冲区让两边各按自己的节奏工作。实现方式从简单到复杂有好几层。单机内存里可以用Java的BlockingQueue或Python的queue.Queue跨机器就得引入消息队列Kafka、RabbitMQ本质上都是分布式生产者消费者缓冲区。我常把这个模式比作餐厅传菜口厨师只管把菜放到窗口服务员按自己的节奏端给客人高峰期后厨出菜再快也不会把服务员逼疯因为窗口本身就是缓冲。工程上消费者消费速度往往才是瓶颈所以常见做法是把消费者做成并发组多个消费者线程同时从队列里取任务配合手动确认机制保证消息不丢。这里最大的坑是重复消费消费者处理到一半崩溃消息重新入队被另一个消费者再处理一遍可能产生重复数据。所以生产级别的消费者必须设计成幂等——同一个任务处理两次和一次结果完全一致。没有幂等保障的生产者消费者模型在高并发下早晚会出数据问题。3.4 数据库并发锁乐观锁、悲观锁和间隙锁数据库并发锁是另一个高频关键词。先说概念悲观锁是“我怀疑你总会和我抢”操作前直接把记录锁住别人只能等待乐观锁是“我赌你不会抢”更新时用版本号或CAS判断数据有没有被别人改过被改了就重试。选择依据就一条冲突频率。冲突高的场景用悲观锁冲突低用乐观锁省心又高效。MySQL InnoDB的锁机制更细行锁、表锁、间隙锁、next-key lock是重点。很多人把行锁理解成“锁住了物理行”其实行锁锁的是索引记录没有索引的查询很可能退化到锁整个表或锁住大片区间。间隙锁锁的是记录之间的区间专门解决幻读问题。于是MySQL在RR隔离级别下做条件更新看起来只改了几行实际上可能把一片索引区间都锁住了并发一高就大量等待。排查锁问题我一般先查information_schema下的事务表、锁等待表找到阻塞事务再分析对应SQL。关键是要把慢查询和锁等待分开看一个SQL慢大概率是索引没走对一堆事务原地等待那才是锁竞争。曾经有个业务上线半年后并发突然暴跌查了半天发现某条update语句的where条件写得不够精确把一张大表半个区间的行都锁住了改成按主键精确匹配后并发立刻恢复。数据库的锁都是越小越好。3.5 Nginx连接数压测第一站先看这里热词里有“nginx最大并发链接数老是用超”这是压测时最常见的报错之一。Nginx的并发能力由几个参数决定worker_processes、worker_connections以及每个worker能维持的连接数上限。经典公式是max_clients worker_processes * worker_connections但这个公式算出来的只是连接数上限不是吞吐量很多人一开始就误读了。worker_processes一般设成CPU核心数worker_connections传统建议是1024或4096现代机器可以更大但也要看内核的文件描述符上限ulimit -n。如果日志里频繁出现“too many open files”先查系统fd限制再把worker_rlimit_nofile调上去。曾在生产环境见过Nginx没到流量峰值就报连接数超限排查后才发现是ulimit太小内核根本没允许Nginx开那么多文件句柄。另一个隐藏瓶颈是keepalive。长连接会一直占住连接不释放如果客户端keepalive超时设置过长Nginx维护的连接数会持续攀升把有限连接池耗尽。EE应用里适当缩短keepalive_timeout、在网关层做连接复用是降低连接压力的最直接手段。压测时看到“连接用超”别急着加机器先回头看看这几个参数是否调得合理。再补充一句如果问的是某个集成开发平台的并发上限比如网上常提的Zcode能同时并发多少个我的建议是先问清业务类型CPU密集还是IO密集底层是线程池还是协程调度瓶颈在连接数还是数据库锁没有这些前提任何对外宣传的并发数字都只能当参考值不能当设计依据。4. 实战中那些绕不开的坑与排查思路4.1 并发数上不去先按三层排查遇到并发数上不去我喜欢按“接入层→应用层→数据层”的顺序排查。接入层先看连接数限制和网关配置比如Nginx的worker连接数、操作系统的socket backlog、文件描述符上限。应用层再看线程池大小、队列长度、GC情况尤其是Java应用Full GC一旦频繁并发能力会断崖式下跌。数据层接着看连接池够不够、SQL有没有走索引、锁等待时间是否过长。三层都看完了通常能定位到一个或者几个具体瓶颈点。大多数并发问题到最后都指向一个事实不是某个组件不行而是系统里最弱的那个环节被击穿了。所以排查过程的产出应该是一张瓶颈清单而不是一句笼统的“系统不行”。我在做性能优化时最喜欢的就是找出那个最先扛不住的环节把它升级之后再跑压测让新的瓶颈暴露出来如此反复系统能力才一步步上去。4.2 常见并发问题排查方法几条从实践里打磨出来的核心思路看到CPU飙高先抓线程栈Java用jstackPython用py-spy看是不是有死循环、锁竞争空转或频繁上下文切换。看到内存上涨先想到无界队列堆积再抓堆dump分析对象引用链确认是谁持有了不该持有的对象。看到请求超时先分清是连接等待超时还是执行超时然后分别看连接池和线程池的状态。看到数据错乱先怀疑可见性再看是不是共享了可变对象加锁之前先想清楚“这个状态真的需要共享吗”。我遇到过一个经典死锁案例两个线程各自持有一把锁然后都在等待对方释放锁线程栈上互相等待一眼就能看出来。死锁的四个必要条件一是互斥、二是占有并等待、三是不可剥夺、四是循环等待。解决办法通常是给所有锁定一个全局获取顺序保证任何线程都以同样次序拿锁破坏循环等待这个条件。4.3 多线程面试高频题速查多线程面试题是热词的大头也是新人最焦虑的部分。其实常考题就那些不用漫天撒网进程和线程的区别线程间为什么需要同步。线程池核心参数和工作流程什么时候先建核心线程什么时候把任务放进队列什么时候创建非核心线程什么时候触发拒绝策略。volatile、synchronized、Lock三者的区别以及volatile为什么不能保证原子性。死锁的四个必要条件以及实际工程里怎么避免。Java内存模型和happens-before规则。数据库乐观锁和悲观锁的区别各自适合什么业务。生产者消费者模式怎么实现队列满了怎么办消费者崩溃了怎么保证不丢消息。面试官真正想看的不是你把概念背得多熟而是你有没有真实的并发工程判断力。比如问“线程池大小怎么设”教科书答案是CPU密集型N1、IO密集型2N但拿来就用会出问题。实际还要看任务队列长度、下游依赖的处理能力、系统的内存和GC表现。面试时给出一个逻辑清晰的推导过程和合理范围比报一个数字更有说服力。4.4 我的几条实操心得最后说几条自己踩坑踩出来的心得。第一并发编程里最危险的不是锁而是共享的可变状态。很多问题不是锁写得不对而是压根不该共享的数据被共享了。设计时先想清楚哪些数据是线程专属、哪些是只读、哪些才需要互斥访问能省掉后期大量调锁的时间。第二先跑压测再优化。凡是“我觉得这样更快”的改动都要用压测数据说话。压测的时候一定记得看响应时间的P99和P999平均值很容易骗人——99%的请求都很快但1%慢到超时的请求才是用户真实体验里的毒药。压测报告里缺P99基本等于没做。第三日志是并发排查的生命线。并发问题大多不可复现红了全靠日志找线索。给每个请求分配一个全局traceId异步线程里保持上下文透传日志里多打关键变量。这些习惯在平时看起来不起眼出问题时就是救命稻草。我救过不止一个线上事故靠的就是头一天随手加的几行日志。聊聊我现在的状态。学并发多线程不需要第一天就把JMM、actor、GIL这些全部弄明白但可以尽早养成一种条件反射看到共享状态就怀疑可见性看到任务堆积就检查队列和线程池看到请求变慢就排查连接和锁。这种条件反射只能来自真实项目的调试和劣后复盘。我自己的成长经验很简单多线程认知的提升速度取决于你踩坑的次数而不是看过的文章篇数。把每一次线上故障都当成一次免费的教学案例记下来留个复盘文档下次遇到相似场景你就比别人多一层底气。