在别人问我“进程和线程到底有什么区别”的时候我通常不会直接背教科书上的定义而是先反问一句你现在遇到的问题是资源出问题了还是执行流出问题了这句话看着简单但很多线上事故排查到最后其实就是在回答这两个问题。这篇文章想聊的不只是把进程与线程的概念再讲一遍而是用这些年实际踩过的坑把这两者背后的资源归属、切换代价、选型逻辑和排错工具串成一条线。无论你是刚入门写代码还是已经在维护线上服务只要你遇到过任务管理器里CPU飙到100%、Java进程报OutOfMemoryError、某个文件被“另一个进程锁定”这种事这篇文章应该都能给你一点启发。1. 从“大箱子套小盒子”的误解说起进程管资源线程管执行1.1 一个被绝大多数教程带偏的第一印象先说一个最常见的认知偏差很多人把线程理解成“进程里面切出来的小单位”觉得线程就是进程的一部分跟俄罗斯套娃似的。这个印象不能说全错但会误导你对很多问题的判断。我更喜欢用公司来打比方。一个进程就像一家公司它有独立的注册地址地址空间、有注册资本分配到的内存区域、有独立的办公场地打开的文件、网络连接、信号处理这些资源都属于这家公司。而线程是这家公司里的员工员工在公司里办公用的是同一套办公场地、会议室、打印机和网络但每个员工有自己的工位栈、自己的工作节奏独立的执行流。员工辞职了公司照常运转公司倒闭了所有员工都没饭碗。线程中止进程还在进程中任意一个线程搞出严重问题整个进程可能随之崩溃。所以线程不是从进程里切出来的小块线程是跑在进程所提供的资源之上的执行流。进程是资源分配的基本单位线程是CPU调度的基本单位。这个区分绝不是咬文嚼字。你去看Windows任务管理器或者Linux的ps输出能看到的是进程列表和CPU占用但一个可视化IDE在你眼前卡死的时候任务管理器里那个进程的CPU可能只有5%真正疯狂跑的其实是它内部的某个线程。如果你脑子里一直拿“大箱子套小盒子”的模型去理解遇到这种场景你会觉得系统显示坏了实际上只是你看错了层。1.2 表象之下切换代价、通信代价、隔离代价聊完定义接着看三个最关键的实际差异切换代价、通信代价、隔离代价。切换代价这件事很多教科书喜欢列一串寄存器、程序计数器、栈指针来证明“线程切换比进程切换便宜”。我只说最核心的一点进程切换要换地址空间也就是要翻页表、刷新TLBCPU的高速地址翻译缓存这是一笔真金白银的开销线程切换不需要翻页表因为线程共享进程的地址空间只需要保存恢复寄存器状态和栈指针即可。所以线程切换比进程切换快但快多少取决于操作系统和CPU架构不能简单说“快十倍”。通信代价也是类似逻辑。进程之间互相独立想交换数据必须走IPC进程间通信常见的有管道、消息队列、共享内存、Unix套接字等这些机制要么慢、要么复杂、要么需要处理并发同步。线程之间通信呢共享内存里的变量就是天然的通道。看起来线程通信是不是完胜对但代价是你要自己处理互斥、可见性、死锁这些问题。共享不是免费的并发编程里一半以上的复杂性都来自“共享”这两个字。隔离代价则是另一个方向的权衡。正因为进程的地址空间互相独立一个进程崩了不会直接带走隔壁进程这也是为什么浏览器要搞多进程、为什么线上服务愿意拆出独立进程做隔离。而线程共享同一地址空间一个线程越界访问、死循环、把内存写坏了整个进程连同其他正常线程一起遭殃。用生活里的话说进程之间是“每家每户独立水电表”线程住的是集体宿舍宿舍里有人乱接线全楼跳闸。1.3 为什么任务管理器里看到的“线程数”才是执行真相最后说一个实用观察在Windows上用Process Explorer微软官方的增强版任务管理器看进程你会发现每个进程下面挂着几十个线程有些进程的线程数量甚至上百。这些线程有的在等待网络数据、有的在跑垃圾回收、有的在刷界面。你只看进程CPU占用率永远不知道热点在哪。我调试过一台CPU占用率持续100%的Windows机器任务管理器显示是“System”进程在吃CPU这基本等于没信息。后来打开Process Explorer双击System进程进入Threads标签页按CPU占用排序一下就定位到某个线程占了80%以上CPU再看线程堆栈顺着模块路径找到了一个第三方驱动的文件。整个过程不到五分钟但如果只会看进程号可能还在纠结要不要重启机器。所以面对“进程和线程”这个话题我建议你先把观念拧过来进程是资源容器线程是执行流。排查问题的时候第一步看清楚资源属于谁第二步看清楚线程在跑什么很多模糊的问题立刻变清晰。2. 选型定生死多进程与多线程的真实取舍场景2.1 从“爱用哪个用哪个”到“不选会出事”概念讲完下一步就是选型。很多新手对“用多进程还是多线程”没概念觉得反正都能并发哪个顺手用哪个。实际工作中这个选择能直接影响程序能不能跑、崩了之后能不能恢复。最典型的例子是Python。因为GIL全局解释器锁的存在Python的多线程在同一个进程里同一时刻只能有一个线程执行Python字节码纯计算密集型任务用线程等于没并行CPU多核完全吃不满。这时候该选的是多进程比如concurrent.futures.ProcessPoolExecutor每个进程有独立的解释器和GIL才能真正跑满多核。Java、C#这类语言没有GIL的制约多线程用起来很顺手但多线程也意味着所有线程共享同一个进程地址空间。如果你的业务需要高度隔离比如要执行用户上传的不可信脚本、要跑可能崩溃的第三方库多线程方案就不是简单的“好用不好用”的问题而是“安不安全”的问题。这种场景下多进程加沙箱、加资源限制反而更稳妥。2.2 一张决策清单隔离性、崩溃面、数据共享频率、编码成本我不喜欢给出“无脑用多线程”或者“无脑上多进程”这种一刀切的建议更靠谱的做法是拿几个维度打分选型自然就清楚了。内存隔离多进程占优。进程间地址空间独立一个进程把内存写坏不会污染别人多线程共享地址空间一个越界可能毁掉整个进程。启动与切换开销多线程占优。创建线程比创建进程轻量切换线程也比切换进程快。数据通信频率多线程占优。共享变量就能通信简单直接多进程得走IPC要么写管道、要么搞共享内存代码复杂度上一个台阶。崩溃影响范围多进程占优。一个worker崩了主进程可以拉起新的其他worker不受影响多线程呢一个线程段错误可能直接带走整个进程所有线程一起陪葬。维护与调试难度多线程前期开发爽后期调试起来很痛苦死锁、竞态、内存可见性问题都藏在暗处多进程的边界清晰崩溃了日志一看就知道是哪个进程挂了。资源上限控制多进程更稳。操作系统对进程数量、内存有独立限制一个进程吃内存不会直接挤爆另一个多线程的线程数堆太多光线程栈就能把地址空间吃干。我给过一个比较实用的经验式判断如果任务是计算密集且互相独立优先考虑多进程或分布式如果是IO密集且数据共享频繁优先多线程加线程池如果任务本身不可信或者可能崩溃必须多进程隔离如果团队刚接手这块代码且并发经验一般宁可先做成多进程再优化也别上来就写烂的多线程共享代码。2.3 真实案例为什么我会把一个爬虫服务从线程改成进程池这里分享一个我实际改过的项目。早先我写过一个数据采集服务最初用Java的ThreadPoolExecutor去并发抓网页逻辑很顺共享一个URL队列、共享一个结果Map代码写起来确实快。结果上线后隔三差五出问题某个第三方解析库在某些畸形的网页上会触发native层的崩溃这一崩不要紧整个JVM进程直接退出队列里还没处理的上万条任务全部丢了。重启后又要重新断点续抓搞得人很崩溃。后来我把架构改成了多进程方案一个Master进程负责调度和队列下面挂四五个Worker进程每个Worker独立抓取、独立解析崩溃后由一个Supervisor自动拉起已经落盘的任务记录不受影响。虽然要自己处理进程间通信和任务分发代码量变多了但系统从“三天一小崩”变成“稳定跑几个月”。这就是隔离性的真实价值多线程让整个进程一荣俱荣一损俱损多进程让故障范围被墙隔开。同时这也是为什么很多系统设计里会出现“进程池”和“守护进程”。进程池本质上是预先起一批独立进程接到任务就干避免频繁创建进程的开销守护进程则是那个脱离终端会话、常驻后台、负责拉起和管理其他进程的角色。它们不是高深的操作系统理论而是把“进程隔离”这个特性用在工程实践里的常规操作。3. 线程池不是调大就完事参数、队列与拒绝策略的实战配置3.1 线程池到底在解决什么问题聊多线程的时候离不开线程池。我发现很多人在项目里用了线程池却只把它当成“一个能跑并发的工具”对参数配置全靠复制。等到线上出问题不是任务堆积把内存撑爆就是线程创建太多把进程拖垮才回头研究线程池内部机制。线程池解决的第一个问题是复用频繁创建和销毁线程的成本不小池化以后线程可以反复干活。第二个问题是限流线程池核心线程数、最大线程数、队列大小组合起来就是一个并发闸门能防止系统被瞬时流量打爆。第三个问题是解耦任务丢给线程池不用自己关心线程怎么调度、怎么等待调用方只管异步提交。理解这三点之后你就明白为什么线程池不是“数字调越大越好”了。无脑把maximumPoolSize调到几百甚至上千线程栈默认是1MB左右一千个线程光是栈就要吃掉1GB虚拟内存GC线程、上下文切换、锁竞争的成本全都会跟着上去。我之前遇到过一台4核8G的服务器最大线程数配了512结果大部分线程都堵在锁等待上CPU空转接口响应却慢成狗。线程池的核心价值是“用合适的并发度把资源用满”不是“让线程数量最多”。3.2 核心参数设计不能只抄公式以Java的ThreadPoolExecutor为例我给过一个相对稳妥的默认配置你可以根据场景调整ThreadPoolExecutor pool new ThreadPoolExecutor( 8, // corePoolSize 核心线程数 16, // maximumPoolSize 最大线程数 30L, TimeUnit.SECONDS, // 非核心线程空闲存活时间 new ArrayBlockingQueue(2000), // 有界阻塞队列容量2000 new NamedThreadFactory(crawler-worker), new ThreadPoolExecutor.CallerRunsPolicy() );逐个参数说核心线程数是池子常驻的线程数量默认不会回收最大线程数是允许创建的线程上限当任务队列填满之后线程池才会在核心线程之外创建额外线程直到最大线程数非核心线程空闲超过keepAliveTime就会被回收。关于核心线程数的估算经典经验是CPU密集型任务设为N1左右比如CPU核数是8那就9个左右IO密集型任务可以放宽到2N甚至更高因为线程有大把时间在等网络、等磁盘。但这个公式只适合起步真正准确的数字要靠压测调优。我见过不少项目把corePoolSize设成几千理由是“以后并发可能很大”结果系统一启动就背着几千个线程在跑内存和调度成本白白浪费。最大线程数也不是越大越好。对于有容器限制的服务最大线程数要参考容器的CPU和内存配额别超过配额再叠加线程栈内存之后的安全余量。keepAliveTime要配合任务的波动性去设任务来得忽多忽少、尖峰明显的场景存活时间可以设长一点避免线程反复创建销毁业务平稳的场景可以设短一点。3.3 阻塞队列的选择无界队列的危险与SynchronousQueue的硬核队列选型是很多人忽略的细节但翻车概率极高。最危险的是无界队列比如默认的LinkedBlockingQueue如果构造函数不传容量容量就是Integer.MAX_VALUE。这种情况下任务可以无限堆积maximumPoolSize形同虚设因为队列永远填不满线程池永远不会创建核心线程之外的线程。任务多的时候内存里堆了海量待执行对象轻则GC压力暴增重则直接OutOfMemoryError。我之前排查过一个线上OOM事后分析就是用了无界队列任务生产速度远大于消费速度几百万个任务对象把堆吃满了。这个坑是真实存在且非常常见的。有界队列如ArrayBlockingQueue容量固定就要稳健得多。队列满之后线程池才会扩容到最大线程数如果连最大线程数也处理不过来就走拒绝策略。容量怎么定我一般结合corePoolSize估算假设核心线程每秒能处理总任务量的峰值产能队列长度至少能缓冲数秒到数十秒的突发流量。比如单线程每秒处理20个任务核心线程8个整体峰值约160个/秒如果希望缓冲10秒的突发队列容量大致在1600左右。SynchronousQueue则是另一个极端它不存储任务直接把任务交给一个空闲线程没有空闲线程就当场创建新线程。这种队列配合较大的maximumPoolSize可以做到非常灵敏的“即时处理”但代价是线程创建会比较频繁适合追求低延迟、任务生产节奏均衡的场景不适合突发大量任务配合短暂空闲的模型。还有LinkedTransferQueue这种带transfer语义的队列Java场景下用于实现类似“直接交接优先、必要时排队”的模型实际业务里用到的少这里就不展开。3.4 线程池拒绝策略和“任务都完成”的等待姿势当队列满了、线程也达到最大数之后新任务必须做出选择。Java内置四种拒绝策略AbortPolicy是默认的直接抛RejectedExecutionException如果你没处理这个异常任务就静默失败。好处是问题立刻暴露坏处是会导致调用方跟着出异常。CallerRunsPolicy是把被拒绝的任务交给提交它的线程去执行也就是让调用方自己跑。这个策略适合不希望丢任务的场景它还给系统一个隐性的天然背压调用方被拖住生产速度自然降下来。DiscardPolicy直接丢弃新任务DiscardOldestPolicy会丢弃队列里最老的任务再重试提交。这两个一般不推荐容易造成数据丢失且很难排查。我自己的习惯绝大多数线上服务用CallerRunsPolicy任务宁慢勿丢追求快速失败、能容忍重试的场景用AbortPolicy并在提交处捕获异常做补偿。Discard系列只有在对实时性要求极高且允许丢旧任务的场景才考虑比如实时行情推送里丢弃过期行情可以接受其他场景慎用。再聊一个热词里出现频率很高的问题“线程池的任务如何等待全部完成”。常见的做法是pool.shutdown(); if (!pool.awaitTermination(30, TimeUnit.SECONDS)) { // 超时未完成再做补偿处理 }shutdown会停止接收新任务awaitTermination会阻塞等待已提交任务执行完。还有用CountDownLatch计数、用Future.get逐个等待的做法。我的建议是能优雅关闭就用shutdown加awaitTermination因为这种做法对线程池内部状态的清理最完整如果希望并发等待多个Future可以用CompletableFuture.allOf来组合比手动CountDownLatch更简洁。4. 死锁、文件锁与僵死进程一次完整的资源冲突排查链路4.1 死锁不是理论概念是真实的工作事故线程并发最经典的事故就是死锁。教科书上说死锁需要满足四个必要条件互斥、持有并等待、不可剥夺、循环等待。我用自己的话翻译一下一把锁同时只能被一个人拿互斥你拿了一把锁之后还想拿另一把锁同时又没放开第一把持有并等待别人不能强行从你手里把锁夺走不可剥夺结果一圈人都在等对方手里的锁形成闭环循环等待。举个最简单的例子。线程A先拿锁1、再拿锁2线程B先拿锁2、再拿锁1。如果两个线程同时执行A可能已经握住锁1、正在等锁2而B已经握住锁2、正在等锁1。谁也等不到谁程序卡死。这种问题在代码review阶段经常能被review出来但线上死锁往往复杂得多锁的数量不止两把获取顺序在代码里隐藏得又深很难一眼看穿。排查死锁我用的固定套路是先找到进程再导线程栈然后找“Found one Java-level deadlock”或者循环等待的关键词。jps -l jstack 12345如果是Java应用jstack输出里很明确地告诉你哪几个线程互相持有哪些锁甚至直接把死锁环列出来。其他语言也有类似工具比如C#可以用dotnet-dump抓dump再用分析器看线程栈Windows上可以用Process Explorer的Threads窗口冻结线程、查看线程堆栈热词里提到的“Process Explorer冻结线程”就是这个用途——把可疑线程冻结住观察它的调用栈和锁状态确认它是不是卡在某个资源等待上。4.2 文件锁与“F盘被另一个进程锁定”锁定对象其实是句柄/资源和死锁同样高频的另一类事故是“文件被某个进程锁定”。热词里有“F盘被另一个进程锁定”这个我太熟了Windows用户经常遇到想删除一个文件、重命名一个目录提示“操作无法完成因为文件已在另一个程序中打开”或者更夸张一点整个F盘都显示被占用。先说结论Windows的“文件锁定”通常不是整张盘被锁而是某个进程打开了盘上的某个文件句柄导致相关目录操作被操作系统拒绝。排查序列我习惯这样走打开资源监视器WinR输入resmon。切到“CPU”这个页签展开“关联的句柄”搜索框。输入你怀疑被占用的文件路径、盘符或者文件名的关键字。系统会列出一堆进程看哪个进程持有这个文件的句柄。定位之后该杀进程杀进程该重启服务重启服务。如果连这个都搜不到那就打开Process Explorer用CtrlH打开句柄搜索框全局搜文件名。它能搜到的范围比资源监视器更细。至于“杀了一个PID又换了一个”这种幽灵进程现象我在很多热词里看到比如thunderplatform占用进程、baidunetdiskhost进程。这类进程通常有一个守护型父进程或者服务在持续拉起被杀的进程。如果你只结束子进程父进程过几秒又给你拉一个新PID出来。这时候正确姿势是别跟子进程较劲用Process Explorer的Process Tree功能看它的父进程是谁、谁注册了自启动把服务、计划任务、启动项里对应的条目禁用掉才能断根。热词里提到的“msedgewebview2.exe 进程如何关闭”也是同一类问题WebView2经常是某个桌面应用拉起来的子进程直接结束进程之后主程序又会拉新的需要在主程序设置里关掉相关功能或者结束主程序。4.3 进程资源图的可化简到底在说什么操作系统课程里有一个知识点叫“进程资源图的可化简”很多人学的时候觉得抽象其实它就是用图形表达死锁检测的核心逻辑。资源分配图里有两种节点进程节点圆圈和资源节点矩形边表示“进程请求资源”或者“资源已分配给进程”。判断系统是否有可能死锁就看这张图能不能完全化简。化简的意思是如果一个进程所需的资源都已经分配到位就让它运行完、释放资源然后把它占的边全部去掉依次做下去如果所有进程都能这样被消掉说明没有死锁如果最后还剩下一圈进程互相等资源消不掉那就是死锁环。这个知识点在面试里经常和“银行家算法”一起出现但放在工程里它的价值更多是训练一种直觉看到一组进程或者线程互相等待的时候先画一画它们之间的依赖关系找环。找到环你就找到了死锁的根源。我在实际排查的时候脑子里会快速过一遍“这是不是循环等待”比直接翻代码要快得多。热词里还有一个“异类线程调度策略”顺带说一句操作系统的线程调度策略多种多样有普通的分时调度、有实时调度如SCHED_FIFO、SCHED_RR。设置为实时调度后线程优先级非常高可能会造成其他线程吃不到CPU所以生产环境非特殊场景不要乱改调度策略否则你可能会看到某个线程把CPU占满、其他线程饿死的诡异现象。5. 进程内存与意外退出从堆设置到OOM再到进程悄悄消失的连锁反应5.1 堆只是进程内存的一部分热词里有一条非常典型“IDEA编译时进程堆大小调整为8000还是报错java.lang.OutOfMemoryError”。这句话暴露了一个经典误区以为调整Java堆大小就等于控制了进程内存。实际上一个Java进程所占的内存远不止堆。常见的内存区域包括Java堆存放对象实例受-Xmx控制。方法区/元空间Metaspace存放类元数据。新版JDK里元空间默认可以使用本地内存的大部分类加载太多也可能OOM。线程栈每个线程默认栈大小-Xss通常是512KB到1MB线程多了累积起来的数值非常可观。直接内存Direct BufferNetty、NIO等场景会使用堆外内存受-XX:MaxDirectMemorySize限制。JIT编译器、GC相关数据结构、本地内存分配器等也可能吃掉不少内存。如果是容器部署还要考虑容器本身的内存限制和操作系统页缓存。所以“堆调整为8000”还报OOM你要先确认到底OOM的堆空间、是元空间、是创建线程失败还是直接内存不够。堆OOM和线程过多OOM的处理方式完全相反前者需要加大堆或者减少堆内垃圾后者反而要减少线程数量、降低-Xss再加大堆只会雪上加霜。5.2 Java OOM的几种常见形态与判断口诀我整理了一份快速判断的清单遇到OOM先对号入座java.lang.OutOfMemoryError: Java heap space堆满了。用jmap -heap或者jstat看堆使用情况确认是内存泄漏还是对象太多了需要dump堆快照分析。java.lang.OutOfMemoryError: Metaspace类元数据太多常见于动态生成大量代理类、热部署不卸载类加载器。对策是调大-XX:MaxMetaspaceSize或者排查类加载器泄漏。java.lang.OutOfMemoryError: unable to create native thread无法创建本地线程通常是线程数已经逼近操作系统限制或者内存不够给新线程分配栈。这时候要先查进程到底有多少线程而不是盲目调大堆。java.lang.OutOfMemoryError: Direct buffer memory堆外直接内存耗尽常见于Netty和NIO应用。用NMTNative Memory Tracking或者jmc去看native区域。java.lang.OutOfMemoryError: GC overhead limit exceededGC时间占比过高但回收效果极差基本等价于堆太小或者已经有内存泄漏优先做堆dump。判断口诀其实就一句先看清楚OOM信息里的后缀是哪个区域再决定动哪个参数。别一看OutOfMemoryError就加堆十个里面有四五个根本不是堆的事。5.3 进程为什么悄悄消失MySQL 1067、SQL Server服务进程异常终止热词里还有“MySQL 1067进程意外终止”“SQL2000服务进程被异常终止无法继续提供服务”这类Windows服务问题这在老派的Windows运维里是经典难题。1067错误本质上是“进程意外终止”的通用提示它本身不告诉你原因你得去日志里翻线索。我的排查顺序是看Windows事件查看器运行eventvwr.msc在“Windows日志-系统”里查Event ID 7031、7034之类的服务崩溃记录里面通常会写进程终止时最后的错误代码。看服务自身日志MySQL的error log在数据目录下的.err文件里面有最后的报错SQL Server的错误日志也类似。绝大多数进程启动后秒退的根因日志里都写得清清楚楚。排查资源因素机器内存是否长期接近耗尽磁盘空间是否不足服务写不了日志也会自杀磁盘IO是否卡死进程是否被操作系统OOM Killer给杀了。Linux上可以查dmesg或者/var/log/messages里有没有Out of memory相关记录。排查权限因素服务账户是否有权限写数据目录、临时目录权限不足在服务启动阶段经常表现为秒退。最后检查配置是否有异常改动配置文件被改坏、字符编码错误、路径不存在都能让服务进程在初始化阶段就退出。把“进程意外终止”当成一个线索而不是一个结论顺着日志往下兜大部分答案都在最后几行日志里。热词里的“监控前台进程”“stystem进程”“microsoft contemporary进程”这些也属于同一个方向先通过可靠的监控工具确认进程的启动、存活、内存和CPU状态再结合日志做根因分析比上来就猜快得多。Windows上如果system进程CPU一直100%先用Process Explorer看是哪个线程再顺着内核栈定位到具体的驱动或者设备而不是直接怀疑“系统中毒”。6. 排查进程与线程问题的工具箱从Process Explorer到jstack的实战组合6.1 Windows侧Process Explorer的正确用法Windows自带的CtrlShiftEsc任务管理器能看的东西有限真正干活的时候我更推荐Process Explorer。它不是花架子核心功能都是为排查进程线程问题准备的双击进程进入属性面板切到Threads标签页就能看到进程内部的全部线程按CPU排序找热点线程。双击某个线程可以查看它的线程堆栈还能冻结/恢复线程。冻结线程用于在你做其他操作时保持线程状态不变化方便观察这在排查死锁和卡顿的时候特别好用。CtrlH打开句柄搜索输入一个文件路径就能找出哪个进程持有着它这正好对应前面说到的“F盘被另一个进程锁定”。CtrlD打开DLL搜索查看进程加载了哪些模块能定位到是哪个第三方驱动或者注入的DLL在捣乱。进程列表顶上默认有CPU、Private Bytes等列还可以开启“Process Tree”模式一眼看清谁是父进程、谁被谁拉起来。再补一个小技巧Windows资源监视器里能看到“关联的句柄”Process Explorer能看到更底层的内核句柄两者结合基本能解决99%的文件占用问题。热词里提到的“杀了一个PID又换了一个”在Process Explorer里看进程树是最直观的——子进程消失、父进程马上拉起新子进程这种父子关系在Process Tree下一目了然。6.2 Linux/Java侧一个组合命令拿全现场Linux下排查进程线程问题我的固定操作组合是这样的# 查看进程基本信息、父进程、线程数 ps -o pid,ppid,nlwp,cmd -p 12345 # 实时查看进程内各线程的CPU占用 top -Hp 12345 # 查看进程打开的文件夹句柄 lsof -p 12345 | head # 抓线程栈看锁等待和死锁 jstack 12345 # 查看堆内存使用 jmap -heap 12345 # 查看原生内存分配情况需要先开启NMT jcmd 12345 VM.native_memory summary这套组合拳覆盖了五个维度谁在跑进程结构、谁在吃CPU线程热点、打开了什么资源文件句柄、锁在哪里线程栈、内存去哪了堆和原生内存。我排查线上Java进程的卡死、CPU飙高、内存泄漏基本都靠这一套。热词里有“java获取当前线程名”顺带提一句多线程排查时给线程起好名字非常重要。Java里用ThreadFactory给线程命名比如前面例子里的“crawler-worker-1”Python里用threading.current_thread().name这能在jstack输出和日志里快速认出是哪个业务线程出了问题。别嫌这种细节碎真正出事故的时候一个清晰的线程名能省半小时定位时间。6.3 顽固进程与线程的收尾处理思路排查到最后总逃不开处理环节。我的原则是先留现场再动手。也就是说先导出线程栈、句柄列表、内存快照、进程树留下完整的证据再做结束进程或者禁用服务的操作。不要一看到可疑进程就急着Taskkill很多时候杀掉之后现场没了下次复现不知道猴年马月。对于循环自拉起的顽固进程记得处理思路不是“杀子进程”而是“干掉父进程/服务/计划任务/启动项”。父进程停了子进程自然就成了孤儿不会再被反复拉起。热词里“杀了一个pid又换了一个”的困惑本质上就是没看懂自拉起链路。用Process Explorer看准进程树、查服务列表、查任务计划程序、查注册表Run项把自启动源头掐掉问题才算真正处理完。至于“java线程等待都完成”“python线程嵌套线程”“atomicinteger线程安全吗”这些问题其实都可以归到同一类思考框架里线程等待要明确等什么、线程嵌套要清楚共享资源的访问边界、AtomicInteger这类原子类保证的是单变量操作的原子性而不是业务整体的原子性。线程安全没有银弹只有把资源共享边界画清楚把锁的粒度设计好才能既保证正确性又保住性能。我最后再分享一个实际体会遇到进程和线程相关的疑难杂症不要急着套结论先回答两个问题——“这个资源到底归谁管”“这条执行流到底在等什么”大多数排查卡壳都是这两个问题没答清楚。把现场信息拿全把资源归属和等待关系找出来剩下的通常只是时间问题。
