第一次独立处理线上OOM告警时我在凌晨两点干了件蠢事先重启了服务。告警确实消失了但第二天监控上那根陡峭的内存曲线、日志里的OutOfMemoryError堆栈以及唯一一次保留现场的机会都随着重启一起没了。后来带团队排查内存泄漏的过程中我慢慢发现大多数OOM事故并不难定位难的是找对方向、留好现场、用对工具。这一章我会把内存泄漏与OOM排查的完整方法拆开讲从概念辨析、异常分类、线上操作链路、真实案例到工具的组合用法尽量让没有经验的同学也能在拿到一次OOM告警后走完从发现到修复的全过程。1. 内存泄漏不是OOM但90%的OOM背后都有它的影子1.1 先把概念捋直一个在积攒一个在爆炸很多刚接触排查的同学会默认OOM就是内存泄漏或者反过来没有泄漏就不会OOM。这两种说法都不完整。内存泄漏准确描述是对象本应结束生命周期却因为引用链仍然存在导致GC无法把它回收。GC判断对象是否存活的标准只有一个从GC Root出发能不能沿着引用链找到它。能找到就认为还活着哪怕业务上这个对象已经彻底没用了。典型场景就是对象被放进了静态集合、缓存、ThreadLocal里这些容器对象的存活时间特别长长到比业务数据的生命周期还长于是容器里堆积的业务对象越来越多堆内存被一点点吃掉。OOM是OutOfMemoryErrorJVM在分配内存时发现内存空间无法满足请求而抛出的Error。它和泄漏没有必然的等价关系。我举一个极端例子一个2GB堆的JVM业务代码试图一次性读入1.8GB的byte数组这也会OOM但此时进程里没有任何泄漏纯属一次性胃口太大。反过来泄漏引发的OOM一定有个过程对象缓慢堆积GC回收不掉堆占用越来越高直到某一刻分配新对象时突破上限。所以拿到任何OOM告警第一件事不是去翻代码找泄漏点而是先判断这个OOM属于哪一种是瞬间分配不过来还是长期缓慢堆积后的必然结果。方向错了后面全是白忙。1.2 判断方向的三个信号比任何工具都重要我判断方向一般只看三样东西第一看监控上堆内存使用率的形态。一个长期缓慢上升、重启后回落、过几天又爬上去的锯齿上坡基本就是泄漏而且大概率有固定的触发路径比如某个接口、某个定时任务在持续制造不可回收对象。如果堆曲线平时很平稳某一天某个时间点突然一根直线冲上去那更可能是大对象一次性分配比如导出一个超大Excel、全表查询、大报文解析。第二看Full GC之后的回收效果。内存泄漏的典型特征是即使你看到Full GC执行了老年代占用率也降不下去因为占着老年代的本来就不是真正可回收的垃圾。GC日志里如果出现连续多次Full GC间隔越来越短、回收比例越来越小的趋势哪怕还没OOM也已经在泄漏路上了。第三问自己几个问题OOM发生在什么时候是高峰期的某个特定操作吗最近有没有发版发版后多久开始出现有一次我排查一个服务OOM发现每次都是凌晨定时任务跑了十几分钟后开始Full GC最后定位到一个批处理任务在循环里往静态Map里塞数据做的又是不可中断的大批量调度泄漏速度被任务频率放大了好几倍。这类规律性的线索在动手抓dump之前就能帮你圈定搜索范围。注意单次堆内存使用率升高不等于内存泄漏。内存泄漏的判定核心是业务生命周期结束后对象是否仍然被引用而不是现在内存高不高。有些中间件本来就吃内存比如Kafka的broker、ES的fielddata看着高但曲线平稳那叫容量设计问题不叫泄漏。2. 读懂OOM的六种报错每一句都指向不同的真凶OutOfMemoryError不是一个孤立的异常名JVM会在报错信息里给出具体类型每一种对应不同的内存区域和根因。我见过不少排查卡壳的工程师看到OutOfMemoryError就一头扎进堆dump结果根因根本不在堆里白折腾几个小时。2.1 Java heap space堆内分配失败最直白的一种这是最常见的形态。报错信息是java.lang.OutOfMemoryError: Java heap space含义是堆内存中没有足够空间分配新对象。常见触发原因有三种一次性大对象分配比如把1GB的文件读成byte数组或者SQL查询把全表几百万行一次性拉进内存。并发请求量超过堆容量上限比如堆只有512MB但QPS冲到很高每个请求都持有大量中间对象。内存泄漏导致堆被挤占但如果不是泄漏堆占用曲线应该是平稳的只是某一个特定操作触发了超分配。排查时看具体场景如果是某一个大报表功能稳定复现几乎可以肯定是代码层面的分配不合理应该去优化SQL或分批处理如果是在业务高峰偶发优先看QPS、单请求内存开销和堆大小的匹配度。2.2 GC overhead limit exceededGC已经救不了场报错信息是java.lang.OutOfMemoryError: GC overhead limit exceeded。这是JVM的一个自我保护机制HotSpot默认启用-XX:UseGCOverheadLimit当GC花费了超过98%的时间但回收到的堆内存不足2%JVM会主动抛出OOM来结束这种垃圾回收空转的状态。这个报错几乎就是泄漏的高配版信号。它不是堆不够大而是堆里绝大多数对象都无法被回收GC白忙活。你可以把它理解成一个房间里堆满了垃圾清洁工一直在干活但垃圾永远清不掉最后房东宣布不干了。出现这个报错别再调大堆内存调大只是延长等死时间赶紧抓dump找不可回收对象。2.3 Metaspace类的元数据把内存吃满了JDK8之后类的元数据存储在Metaspace报错信息是java.lang.OutOfMemoryError: Metaspace。Metaspace默认没有上限受本机内存限制所以它一旦OOM通常意味着动态生成的类太多了。什么场景会搞出大量类热部署框架反复重新加载应用但没有清理旧类加载器、CGLIB/ByteBuddy/ASM动态代理创建了海量代理类、Groovy脚本或JavaScript引擎反复编译代码字符串、自定义类加载器没有正确卸载。这类问题dump堆往往看不出异常因为真正膨胀的是类元数据不在堆里。排查时需要关注加载类总数用jmap -clstats pid或Arthas的sc命令统计定位是哪个ClassLoader、哪类类名大量增长。2.4 Direct buffer memory堆外内存排查难度最高的一类报错信息是java.lang.OutOfMemoryError: Direct buffer memory。NIO的ByteBuffer.allocateDirect、Netty的堆外缓冲区、Kafka客户端的memory pool用的都是堆外内存。JVM默认最大直接内存约等于堆大小由-XX:MaxDirectMemorySize控制。堆外泄漏难查是因为普通的heap dump完全看不到堆外对象。你抓一个dump可能发现堆内非常健康但进程内存持续上涨。排查思路要换成如果用了Netty检查PooledByteBufAllocator是否设置了合理的池化上限如果是自研NIO框架重点查DirectBuffer是否在finally里回收是否存在堆积还可以配合-XX:NativeMemoryTrackingsummary启动JVM用jcmd pid VM.native_memory summary看Native内存的分布或者用pmap看进程地址空间的增长。2.5 unable to create new native thread线程创建失败别在堆上找原因报错信息是java.lang.OutOfMemoryError: unable to create new native thread。这个OOM虽然顶着OutOfMemory的名头但根源是操作系统无法创建新线程了跟堆内存几乎没有关系。排查链路依次看进程内到底创建了多少线程jstack统计线程数ps -eLf | grep java | wc -l操作系统对进程线程数的限制ulimit -u系统级全局线程数限制/etc/security/limits.conf、pids cgroup线程栈大小-Xss是否设置异常栈设得越大能创建的线程数越少。业务侧经常踩的是无界线程池——Executors.newFixedThreadPool没控制拒绝策略回调线程、异步任务无限创建最终打满线程上限。2.6 Requested array size exceeds VM limit不太常见但很好定位报错信息是java.lang.OutOfMemoryError: Requested array size exceeds VM limit。JVM对数组对象有长度上限比如最大约Integer.MAX_VALUE - 8当代码尝试分配一个超过上限的数组会直接抛这个OOM。绝大多数情况是代码bugbyte数组长度计算溢出、读取二进制协议时把长度字段解析成了负数或超大值、ArrayList扩容时int溢出。这种OOM不需要复杂的dump分析直接从异常堆栈就能定位到具体代码行重点检查所有涉及长度计算和位运算的地方。我把六种形态整理成一个对照表方便团队内部排查时直接查报错关键字内存区域典型原因优先排查方向Java heap space堆分配过大、堆过小、泄漏对象分配逻辑、堆大小、dumpGC overhead limit exceeded堆不可回收对象占满堆泄漏、静态集合、缓存Metaspace元空间动态类生成过多类加载器、代理库、脚本引擎Direct buffer memory堆外直接内存泄漏或配置过小NIO/Netty、NMT、MaxDirectMemorySizeunable to create new native thread线程栈线程数超限线程池、系统线程限制、XssRequested array size exceeds VM limit堆数组分配长度溢出代码长度计算、位运算提醒不要一看到OOM就调大-Xmx。内存不足时加内存属于兜底手段但如果根因是泄漏加再大的堆也只是推迟OOM时间而且堆越大重启后恢复的时间越慢事故影响面反而更大。3. 线上接到OOM报警后的五步排查链路OOM排查最怕的不是问题难而是现场被破坏。我把线上处理流程固定成五步团队里任何人接到告警都按这个来减少凭感觉操作。3.1 第一步先留现场再谈修复看到OOM告警的第一瞬间不要做任何可能改变进程状态的操作。先做的事按顺序来打开应用日志找到OutOfMemoryError关键字把完整堆栈存下来。确认启动参数里有没有-XX:HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath。如果配了去指定目录找OOM时自动生成的.hprof文件这是最干净、最准确的现场。如果没有自动dump但进程还活着用jmap -dump:formatb,file/data/logs/app.hprof pid手动抓。抓取过程中目标进程会暂停需要确认当前是否是业务高峰期必要时先摘流量再抓。如果进程已经退出或不可用保留系统日志和监控截图把上次自动dump的产物、GC日志、线程快照全部归档。有一个细节值得强调OOM后进程不一定会退出。JVM抛出OutOfMemoryError之后如果没有明确配置-XX:ExitOnOutOfMemoryError进程可能还赖活着但此时内存状态和OOM瞬间已经不一样了如果拖太久才抓dump怀疑点可能已经消失。所以抓dump要趁早宁可先抓再分析也别等。3.2 第二步用GC日志和监控判断泄漏还是突刺拿到现场数据后先不急着开MAT先把方向定了。我习惯用jstat -gcutil pid 1000观察10到20秒重点看Full GC次数FGC是否在快速上涨。老年代占用O在Full GC之后是否仍然降不下来。Eden区和S0/S1区的分配回收节奏是否异常紧凑。如果老年代占用在每次Full GC后都几乎不降且Full GC间隔越来越短那么基本可以判定堆里充斥着无法回收的对象——泄漏。如果Full GC次数很少堆占用在OOM前一直平稳只是某一次突然冲顶那么更可能是大对象一次性分配此时去查那个时间点的业务操作、上游流量、SQL或文件加载逻辑会比钻dump更有效。现在很多服务已经接入APM或监控平台如果你能看到堆内存的日维度曲线直接把告警时间往前拉一周观察趋势即可。一根持续上坡的曲线哪怕没有OOM也是高级别隐患。3.3 第三步用dump分析找到谁占了大头定位到是泄漏路径之后把dump文件交给MAT或JProfiler。我推荐直接先看MAT的Leak Suspects报告它会把最可能的泄漏根因按嫌疑程度列出来不是每次都准但能帮你在巨大信息量里找到切入点。然后按顺序做三件事打开Histogram按Retained Heap保留堆排序看哪些类占用了最多的内存。出现业务类名、自定义组件名说明问题很可能在业务代码如果全是byte[]、char[]、String继续往下钻到引用关系。打开Dominator Tree看支配树上最顶层的对象。这个方法能直接展示如果回收掉这个对象能释放多少内存比Histogram更能反映出容器类对象和集合的占用。右键你怀疑的对象选择Merge Shortest Paths to GC Roots或Path to GC Roots - exclude all phantom/weak/soft etc. references查看对象到底被谁引用着。这一步是后面反查代码的依据。3.4 第四步顺着引用链反查业务代码引用链上的每一个环节都可能是答案所在。我看到最多的三类静态集合兜底对象里存的是业务数据GC Root指向静态字段比如private static MapString,Object cache。这种最直接一眼就能认出是哪段逻辑塞进去的。容器对象持有时长过久Spring上下文里的单例Bean持有某个List或Map容量没有上限业务数据往里堆积。ThreadLocal借道线程池对象挂在ThreadLocalMap上而线程池里的线程是GC Root导致对象和线程同生共死。这种在MAT里会看到线程对象的引用链很长需要顺着线程名找对应线程池和业务代码。拿到引用链后去代码里定位set对象的位置、生命周期、释放逻辑。这里有个经验不要一上来就怀疑框架中间件先查业务代码再查自研公共组件最后才查第三方依赖。因为业务代码里塞对象进集合、ThreadLocal忘记释放占了实际泄漏案例的绝大部分。3.5 第五步修复、灰度、看趋势别修完就下结论修复的常见手段有静态集合加容量上限和淘汰策略、ThreadLocal在finally块里remove、缓存框架换成Caffeine或Redis、连接使用try-with-resources保证关闭、大对象处理改成分批和流式。但修完不等于结束。内存泄漏的验证周期不能以小时计至少要观察3到7天的内存曲线和Full GC趋势。我的习惯是先在低流量节点灰度观察老年代占用曲线的斜率是否变平FGC频率是否回落再逐步放量。如果只是看半小时没事就给结论很可能掉进没到水位线所以还没爆发的陷阱。4. 实战复盘一个平时没事的ThreadLocal泄漏是怎么被挖出来的讲一个我实际排查过的典型案例流程完整技术含量不算高但很有代表性。4.1 现象服务发版第4天开始频繁Full GC服务A是个内部查询平台一直很稳定。某次发版之后第4天凌晨1点开始Full GC频率明显上升到中午堆内存被打满进程直接OOM。监控显示老年代占用每天在涨而且涨幅一天比一天大GC回收后老年代占用率仍然保持在90%以上。这是非常典型的泄漏曲线。翻看发版记录改动涉及一个查询接口的优化。开发说只是加了个上下文参数没动什么内存相关的代码。但从天起算时间点和发版完全吻合。4.2 场景四与四的现场字符串数组与缓存的障眼法这个案例有点特殊报错关键词是Java heap space但dump分析后我发现对象大头是大量byte[]和String继续往里钻发现它们全被同一个业务对象引用着。那种情况不能光看Histogram因为任何业务数据最终落到内存里都是String和byte[]关键是要找到真正持有这些数据的外层对象。于是打开Dominator Tree按Retained Heap排序排第一的果然是一个自定义业务类再往下展开这个类里有一个MapMap里存放了海量查询结果。代码review后确认这段逻辑在业务方法里把查询结果无条件放进了静态Mapkey是查询参数拼接的字符串value是查询结果。原本设计者以为数据量不大但实际查询参数组合是无限的缓存只增不减。这类案例的处理方式比较简单把静态Map换成Caffeine设置最大容量和过期时间或者数据量确实大就走Redis缓存。核心教训是一样的——本地缓存无上限就是给内存埋雷。4.3 ThreadLocal案例线程池下的借尸还魂另一个高频案例发生在ThreadLocal上。现象、告警方式都和第一个案例高度相似但dump里看到的引用链更隐蔽Thread-ThreadLocalMap-Entry-业务上下文对象很多同学对ThreadLocal的认知停留在用完之后会释放但实际上容器线程池场景下线程是复用的ThreadLocalMap里的Entry不会因为一次请求结束就清理。关键点在于ThreadLocalMap.Entry的key是ThreadLocal实例用的是弱引用但value是强引用。线程池里的线程存活时间极长作为GC Root一直存在。只要线程不死ThreadLocalMap里的value就会一直强引用着目标对象。所以说ThreadLocal本身不泄漏泄漏的是误用了ThreadLocal并且没有remove。正确姿势是ThreadLocalContext ctx new ThreadLocal(); try { ctx.set(buildContext()); // 业务逻辑 } finally { ctx.remove(); }这个案例最后的修复代码只有几行排查的过程却走了大半天。原因就是第一反应一直在业务缓存上找忽略了线程引用链。4.4 这类案例给我们的通用排查顺序把两个案例放一起可以得出一个通用规律出现堆内存泄漏先按概率排优先级——静态集合、无界缓存、ThreadLocal后置清理不足、连接/IO未释放、容器对象生命周期超长。其中静态集合和缓存占了最多数ThreadLocal次之连接泄漏反而在连接池普及后少了很多。抓dump后不要被String和byte[]充斥的Histogram吓到Dominator Tree能直达幕后对象顺着幕后对象的引用链走基本都有明确答案。5. 排查工具的组合拳jmap、MAT、Arthas这样用才顺手工欲善其事必先利其器。排查工具的掌握程度直接决定了定位OOM的时间成本。我把日常最常用的一套组合和踩坑点整理如下。5.1 生产环境第一梯队命令按使用场景选命令用途风险等级使用建议jps -l找到目标JVM进程PID无第一步必用jstat -gcutil pid 1000实时看GC、堆内存走势无方向判断利器jmap -dump:formatb,filexx.hprof pid抓堆dump中会暂停业务摘流量后使用jmap -histo pid看对象分布低不触发FGC适合粗筛jmap -histo:live pid看存活对象分布高会触发Full GC生产环境慎用高峰禁用jstack pid看线程栈无排查线程数超限、死锁jcmd pid VM.native_memory summary看Native内存分布无需启动时开启NMT这里必须提醒很多教程会推荐jmap -histo:live用于分析但live会强制执行一次Full GC在内存已经很紧张的进程上可能直接演变成雪崩。我在生产上几乎不用-histo:live要粗筛对象分布jmap -histo足够要精确分析就直接抓dump离线看。5.2 MAT的使用别被Histogram带偏MATMemory Analyzer Tool是我最常用的dump分析工具。打开一个几百MB甚至几个GB的dump如果本机内存不够先改MemoryAnalyzer.ini里的-Xmx否则MAT自己会OOM。打开之后不要第一时间进Histogram。很多新手看到Histogram里全是byte[]和String瞬间不知道怎么继续。我建议按这个顺序走Leak Suspects报告让MAT自动帮你圈定可疑对象看它的结论和解释。Dominator Tree在怀疑对象上右键展开看最顶层的支配者是谁。支配树的价值在于它按保留堆计算能消解掉String/byte[]带来的干扰直接展示最外层的容器。Path to GC Roots从支配者右键找GC引用路径这条路径就是代码定位的直接证据。在MAT里看Path to GC Roots时有一个小细节默认会排除弱引用但不排除强引用所以你能直接看到强引用链。如果链路上出现java.lang.Thread基本可以断定和线程池、ThreadLocal有关如果出现类名里的静态字段比如com.xxx.Processor.cache那么静态集合的问题就实锤了。5.3 Arthas在生产环境的几个高光时刻生产环境不能随意停应用Arthas这类在线诊断工具的价值就体现出来了。我常用的命令dashboard实时看到内存、GC、线程的概览判断方向比jstat更直观。memory直接输出堆、非堆、直接缓冲区等各区域使用情况。heapdump不需要摘流量就能导出堆快照虽然也会STW但比裸用jmap友好。thread -n 3按CPU占用排序线程排查线程数超限、线程卡死都很方便。watch在线追踪某个方法入参和调用次数在复现阶段能快速确认某个接口是否就是泄漏入口。Arthas还有一个好处它不要求目标JVM以特殊参数启动attach上去就能用。这意味着很多当时没留dump、但是进程还活着的现场还有补救机会。5.4 dump之外的思路前端和其他中间件是同一套方法论排查思路是可以跨技术栈复用的。前端内存泄漏排查Chrome DevTools里的Heap Snapshot两次对比、Performance面板的JS堆内存曲线本质上和MAT的比较dump找不回收对象是一样的。Kafka的broker OOM、Netty的堆外泄漏排查链路仍然是留现场、看趋势、找最大占用、反查引用关系。工具不同方法论一致。经验不要等出问题了才学工具。找一台测试环境JVM人为构造一个静态List塞数据再手动触发OOM把整个抓dump - MAT分析 - 定位引用链流程跑两遍熟练之后线上再怎么忙也不会慌。6. 把OOM扼杀在发布之前监控指标与代码防泄漏清单排查是事故发生的功课但对团队来说更值钱的是让OOM在发布前就失去生存土壤。这一节聊预防层面的落地手段。6.1 上线前就配好的兜底参数即使预防做得再好也要假设某次发版还是会出问题。所以启动参数必须在一开始就配齐# JDK8 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/oom-%p.hprof -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize64m -XX:PrintGCDetails -XX:PrintGCDateStamps# JDK9 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/oom-%p.hprof -Xlog:gc*:file/data/logs/gc.log:time,uptime,level:filecount10,filesize64m如果希望OOM时进程直接退出由编排平台重启可以加-XX:ExitOnOutOfMemoryError避免进程在半死不活的状态下持续接受流量、持续报错。HeapDumpPath目录要提前确认写权限和磁盘空间。我见过一次事故OOM发生时确实触发了自动dump但磁盘空间不足dump写到一半失败现场直接丢失。这个细节太容易栽了。6.2 监控指标报警的不应该是OOM本身很多团队的OOM告警是基于检测到OutOfMemoryError日志这已经是灾难发生后的通知了。真正有价值的告警应该前置到内存趋势上。我建议至少盯住几个指标堆内存使用率的日趋势和周趋势。老年代占用率特别是Full GC后的老年代占用率。Full GC频率和单次耗时。GC后堆回收比例等于回收掉多少/GC前占用多少。如果这个比例持续走低就是泄漏前期信号。原文连接应用RT/P99在Full GC频繁期的抖动情况。告警阈值不要只配绝对值比如老年代大于70%因为很多服务常年老年代60%也正常。更好的方式是对曲线的斜率做告警连续7天老年代占用率的日最低值逐日递增哪怕每日只涨1个百分点也值得人工关注。内存泄漏从来不是一分钟爆炸的它会给足你机会只是很多团队没设这类告警。举个量化例子便于和开发、运维对齐严重性如果每个请求泄漏512KBQPS是100那么一天泄漏约4.3GB512KB × 100 × 86400秒 / 1024 / 1024。也就是说4GB堆撑不过一天。这类计算在故障复盘和需求评审里非常有说服力能让评估缓存容量ThreadLocal记得remove从嘴上说说变成硬性评审项。6.3 代码防泄漏自查清单贴在CI门禁旁边每次发布前代码评审增加一栏内存安全检查重点看静态集合是否有容量上限和淘汰策略无界Map存入业务数据必须给出理由。ThreadLocal初始化在方法内部是否保证了finally里的remove特别关注线程池场景。IO、网络连接、JDBC连接是否使用try-with-resources。批量插入/导出是否分批避免一次性把全量数据载入内存。本地缓存组件是否配置了最大容量和过期时间换Caffeine或Guava后是否配置了淘汰。异步任务队列是否有界无界队列在生产者速度大于消费者时本身就是内存泄漏的温床。动态生成类、脚本编译是否有类加载器回收机制Metaspace的坑大多来自这里。6.4 稳定性压测里的泄漏预演最后一个建议把内存泄漏纳入稳定性压测的通过标准。每次大版本发布前在测试环境跑48小时稳定性压测过程中持续记录老年代占用和Full GC次数。如果48小时内Full GC次数越往后越频繁老年代占用没有回归哪怕没有OOM也要按泄漏预警处理。通常这类问题在测试环境跑24小时以上就会露出端倪但很多团队的压测只跑半小时一小时完全不足以暴露内存缓慢增长的问题。把压测时长拉长是最便宜的线上事故保险。每次做稳定性压测的时候我习惯在压测结束后再抓一次heap dump和触发一次Full GC对比压测前后的对象分布。如果发现压测后静态缓存类、业务收集类的对象数量没有回落就说明这个场景下存在对象残留值得在上线前修掉。结合个人经验说几句我一般会在每次发版后连续盯三天的内存曲线不看告警只看斜率。如果老年代占用第三天比第一天还高说明有东西没释放立刻回去翻最近改的代码。这个习惯帮我提前拦下过好几次线上事故比任何工具都便宜也比任何经验都可靠。内存泄漏这件事从来不会只给你一次机会但也不要幻想着它每次都给你机会。把现场留好把趋势盯住剩下的就是把工具用顺、把清单落到实处。 
长河君 · 2026/9/16 5:42:33 · 阅读 1.2k 内存泄漏与OOM排查实战：从现场保留到工具组合
第一次独立处理线上OOM告警时我在凌晨两点干了件蠢事先重启了服务。告警确实消失了但第二天监控上那根陡峭的内存曲线、日志里的OutOfMemoryError堆栈以及唯一一次保留现场的机会都随着重启一起没了。后来带团队排查内存泄漏的过程中我慢慢发现大多数OOM事故并不难定位难的是找对方向、留好现场、用对工具。这一章我会把内存泄漏与OOM排查的完整方法拆开讲从概念辨析、异常分类、线上操作链路、真实案例到工具的组合用法尽量让没有经验的同学也能在拿到一次OOM告警后走完从发现到修复的全过程。1. 内存泄漏不是OOM但90%的OOM背后都有它的影子1.1 先把概念捋直一个在积攒一个在爆炸很多刚接触排查的同学会默认OOM就是内存泄漏或者反过来没有泄漏就不会OOM。这两种说法都不完整。内存泄漏准确描述是对象本应结束生命周期却因为引用链仍然存在导致GC无法把它回收。GC判断对象是否存活的标准只有一个从GC Root出发能不能沿着引用链找到它。能找到就认为还活着哪怕业务上这个对象已经彻底没用了。典型场景就是对象被放进了静态集合、缓存、ThreadLocal里这些容器对象的存活时间特别长长到比业务数据的生命周期还长于是容器里堆积的业务对象越来越多堆内存被一点点吃掉。OOM是OutOfMemoryErrorJVM在分配内存时发现内存空间无法满足请求而抛出的Error。它和泄漏没有必然的等价关系。我举一个极端例子一个2GB堆的JVM业务代码试图一次性读入1.8GB的byte数组这也会OOM但此时进程里没有任何泄漏纯属一次性胃口太大。反过来泄漏引发的OOM一定有个过程对象缓慢堆积GC回收不掉堆占用越来越高直到某一刻分配新对象时突破上限。所以拿到任何OOM告警第一件事不是去翻代码找泄漏点而是先判断这个OOM属于哪一种是瞬间分配不过来还是长期缓慢堆积后的必然结果。方向错了后面全是白忙。1.2 判断方向的三个信号比任何工具都重要我判断方向一般只看三样东西第一看监控上堆内存使用率的形态。一个长期缓慢上升、重启后回落、过几天又爬上去的锯齿上坡基本就是泄漏而且大概率有固定的触发路径比如某个接口、某个定时任务在持续制造不可回收对象。如果堆曲线平时很平稳某一天某个时间点突然一根直线冲上去那更可能是大对象一次性分配比如导出一个超大Excel、全表查询、大报文解析。第二看Full GC之后的回收效果。内存泄漏的典型特征是即使你看到Full GC执行了老年代占用率也降不下去因为占着老年代的本来就不是真正可回收的垃圾。GC日志里如果出现连续多次Full GC间隔越来越短、回收比例越来越小的趋势哪怕还没OOM也已经在泄漏路上了。第三问自己几个问题OOM发生在什么时候是高峰期的某个特定操作吗最近有没有发版发版后多久开始出现有一次我排查一个服务OOM发现每次都是凌晨定时任务跑了十几分钟后开始Full GC最后定位到一个批处理任务在循环里往静态Map里塞数据做的又是不可中断的大批量调度泄漏速度被任务频率放大了好几倍。这类规律性的线索在动手抓dump之前就能帮你圈定搜索范围。注意单次堆内存使用率升高不等于内存泄漏。内存泄漏的判定核心是业务生命周期结束后对象是否仍然被引用而不是现在内存高不高。有些中间件本来就吃内存比如Kafka的broker、ES的fielddata看着高但曲线平稳那叫容量设计问题不叫泄漏。2. 读懂OOM的六种报错每一句都指向不同的真凶OutOfMemoryError不是一个孤立的异常名JVM会在报错信息里给出具体类型每一种对应不同的内存区域和根因。我见过不少排查卡壳的工程师看到OutOfMemoryError就一头扎进堆dump结果根因根本不在堆里白折腾几个小时。2.1 Java heap space堆内分配失败最直白的一种这是最常见的形态。报错信息是java.lang.OutOfMemoryError: Java heap space含义是堆内存中没有足够空间分配新对象。常见触发原因有三种一次性大对象分配比如把1GB的文件读成byte数组或者SQL查询把全表几百万行一次性拉进内存。并发请求量超过堆容量上限比如堆只有512MB但QPS冲到很高每个请求都持有大量中间对象。内存泄漏导致堆被挤占但如果不是泄漏堆占用曲线应该是平稳的只是某一个特定操作触发了超分配。排查时看具体场景如果是某一个大报表功能稳定复现几乎可以肯定是代码层面的分配不合理应该去优化SQL或分批处理如果是在业务高峰偶发优先看QPS、单请求内存开销和堆大小的匹配度。2.2 GC overhead limit exceededGC已经救不了场报错信息是java.lang.OutOfMemoryError: GC overhead limit exceeded。这是JVM的一个自我保护机制HotSpot默认启用-XX:UseGCOverheadLimit当GC花费了超过98%的时间但回收到的堆内存不足2%JVM会主动抛出OOM来结束这种垃圾回收空转的状态。这个报错几乎就是泄漏的高配版信号。它不是堆不够大而是堆里绝大多数对象都无法被回收GC白忙活。你可以把它理解成一个房间里堆满了垃圾清洁工一直在干活但垃圾永远清不掉最后房东宣布不干了。出现这个报错别再调大堆内存调大只是延长等死时间赶紧抓dump找不可回收对象。2.3 Metaspace类的元数据把内存吃满了JDK8之后类的元数据存储在Metaspace报错信息是java.lang.OutOfMemoryError: Metaspace。Metaspace默认没有上限受本机内存限制所以它一旦OOM通常意味着动态生成的类太多了。什么场景会搞出大量类热部署框架反复重新加载应用但没有清理旧类加载器、CGLIB/ByteBuddy/ASM动态代理创建了海量代理类、Groovy脚本或JavaScript引擎反复编译代码字符串、自定义类加载器没有正确卸载。这类问题dump堆往往看不出异常因为真正膨胀的是类元数据不在堆里。排查时需要关注加载类总数用jmap -clstats pid或Arthas的sc命令统计定位是哪个ClassLoader、哪类类名大量增长。2.4 Direct buffer memory堆外内存排查难度最高的一类报错信息是java.lang.OutOfMemoryError: Direct buffer memory。NIO的ByteBuffer.allocateDirect、Netty的堆外缓冲区、Kafka客户端的memory pool用的都是堆外内存。JVM默认最大直接内存约等于堆大小由-XX:MaxDirectMemorySize控制。堆外泄漏难查是因为普通的heap dump完全看不到堆外对象。你抓一个dump可能发现堆内非常健康但进程内存持续上涨。排查思路要换成如果用了Netty检查PooledByteBufAllocator是否设置了合理的池化上限如果是自研NIO框架重点查DirectBuffer是否在finally里回收是否存在堆积还可以配合-XX:NativeMemoryTrackingsummary启动JVM用jcmd pid VM.native_memory summary看Native内存的分布或者用pmap看进程地址空间的增长。2.5 unable to create new native thread线程创建失败别在堆上找原因报错信息是java.lang.OutOfMemoryError: unable to create new native thread。这个OOM虽然顶着OutOfMemory的名头但根源是操作系统无法创建新线程了跟堆内存几乎没有关系。排查链路依次看进程内到底创建了多少线程jstack统计线程数ps -eLf | grep java | wc -l操作系统对进程线程数的限制ulimit -u系统级全局线程数限制/etc/security/limits.conf、pids cgroup线程栈大小-Xss是否设置异常栈设得越大能创建的线程数越少。业务侧经常踩的是无界线程池——Executors.newFixedThreadPool没控制拒绝策略回调线程、异步任务无限创建最终打满线程上限。2.6 Requested array size exceeds VM limit不太常见但很好定位报错信息是java.lang.OutOfMemoryError: Requested array size exceeds VM limit。JVM对数组对象有长度上限比如最大约Integer.MAX_VALUE - 8当代码尝试分配一个超过上限的数组会直接抛这个OOM。绝大多数情况是代码bugbyte数组长度计算溢出、读取二进制协议时把长度字段解析成了负数或超大值、ArrayList扩容时int溢出。这种OOM不需要复杂的dump分析直接从异常堆栈就能定位到具体代码行重点检查所有涉及长度计算和位运算的地方。我把六种形态整理成一个对照表方便团队内部排查时直接查报错关键字内存区域典型原因优先排查方向Java heap space堆分配过大、堆过小、泄漏对象分配逻辑、堆大小、dumpGC overhead limit exceeded堆不可回收对象占满堆泄漏、静态集合、缓存Metaspace元空间动态类生成过多类加载器、代理库、脚本引擎Direct buffer memory堆外直接内存泄漏或配置过小NIO/Netty、NMT、MaxDirectMemorySizeunable to create new native thread线程栈线程数超限线程池、系统线程限制、XssRequested array size exceeds VM limit堆数组分配长度溢出代码长度计算、位运算提醒不要一看到OOM就调大-Xmx。内存不足时加内存属于兜底手段但如果根因是泄漏加再大的堆也只是推迟OOM时间而且堆越大重启后恢复的时间越慢事故影响面反而更大。3. 线上接到OOM报警后的五步排查链路OOM排查最怕的不是问题难而是现场被破坏。我把线上处理流程固定成五步团队里任何人接到告警都按这个来减少凭感觉操作。3.1 第一步先留现场再谈修复看到OOM告警的第一瞬间不要做任何可能改变进程状态的操作。先做的事按顺序来打开应用日志找到OutOfMemoryError关键字把完整堆栈存下来。确认启动参数里有没有-XX:HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath。如果配了去指定目录找OOM时自动生成的.hprof文件这是最干净、最准确的现场。如果没有自动dump但进程还活着用jmap -dump:formatb,file/data/logs/app.hprof pid手动抓。抓取过程中目标进程会暂停需要确认当前是否是业务高峰期必要时先摘流量再抓。如果进程已经退出或不可用保留系统日志和监控截图把上次自动dump的产物、GC日志、线程快照全部归档。有一个细节值得强调OOM后进程不一定会退出。JVM抛出OutOfMemoryError之后如果没有明确配置-XX:ExitOnOutOfMemoryError进程可能还赖活着但此时内存状态和OOM瞬间已经不一样了如果拖太久才抓dump怀疑点可能已经消失。所以抓dump要趁早宁可先抓再分析也别等。3.2 第二步用GC日志和监控判断泄漏还是突刺拿到现场数据后先不急着开MAT先把方向定了。我习惯用jstat -gcutil pid 1000观察10到20秒重点看Full GC次数FGC是否在快速上涨。老年代占用O在Full GC之后是否仍然降不下来。Eden区和S0/S1区的分配回收节奏是否异常紧凑。如果老年代占用在每次Full GC后都几乎不降且Full GC间隔越来越短那么基本可以判定堆里充斥着无法回收的对象——泄漏。如果Full GC次数很少堆占用在OOM前一直平稳只是某一次突然冲顶那么更可能是大对象一次性分配此时去查那个时间点的业务操作、上游流量、SQL或文件加载逻辑会比钻dump更有效。现在很多服务已经接入APM或监控平台如果你能看到堆内存的日维度曲线直接把告警时间往前拉一周观察趋势即可。一根持续上坡的曲线哪怕没有OOM也是高级别隐患。3.3 第三步用dump分析找到谁占了大头定位到是泄漏路径之后把dump文件交给MAT或JProfiler。我推荐直接先看MAT的Leak Suspects报告它会把最可能的泄漏根因按嫌疑程度列出来不是每次都准但能帮你在巨大信息量里找到切入点。然后按顺序做三件事打开Histogram按Retained Heap保留堆排序看哪些类占用了最多的内存。出现业务类名、自定义组件名说明问题很可能在业务代码如果全是byte[]、char[]、String继续往下钻到引用关系。打开Dominator Tree看支配树上最顶层的对象。这个方法能直接展示如果回收掉这个对象能释放多少内存比Histogram更能反映出容器类对象和集合的占用。右键你怀疑的对象选择Merge Shortest Paths to GC Roots或Path to GC Roots - exclude all phantom/weak/soft etc. references查看对象到底被谁引用着。这一步是后面反查代码的依据。3.4 第四步顺着引用链反查业务代码引用链上的每一个环节都可能是答案所在。我看到最多的三类静态集合兜底对象里存的是业务数据GC Root指向静态字段比如private static MapString,Object cache。这种最直接一眼就能认出是哪段逻辑塞进去的。容器对象持有时长过久Spring上下文里的单例Bean持有某个List或Map容量没有上限业务数据往里堆积。ThreadLocal借道线程池对象挂在ThreadLocalMap上而线程池里的线程是GC Root导致对象和线程同生共死。这种在MAT里会看到线程对象的引用链很长需要顺着线程名找对应线程池和业务代码。拿到引用链后去代码里定位set对象的位置、生命周期、释放逻辑。这里有个经验不要一上来就怀疑框架中间件先查业务代码再查自研公共组件最后才查第三方依赖。因为业务代码里塞对象进集合、ThreadLocal忘记释放占了实际泄漏案例的绝大部分。3.5 第五步修复、灰度、看趋势别修完就下结论修复的常见手段有静态集合加容量上限和淘汰策略、ThreadLocal在finally块里remove、缓存框架换成Caffeine或Redis、连接使用try-with-resources保证关闭、大对象处理改成分批和流式。但修完不等于结束。内存泄漏的验证周期不能以小时计至少要观察3到7天的内存曲线和Full GC趋势。我的习惯是先在低流量节点灰度观察老年代占用曲线的斜率是否变平FGC频率是否回落再逐步放量。如果只是看半小时没事就给结论很可能掉进没到水位线所以还没爆发的陷阱。4. 实战复盘一个平时没事的ThreadLocal泄漏是怎么被挖出来的讲一个我实际排查过的典型案例流程完整技术含量不算高但很有代表性。4.1 现象服务发版第4天开始频繁Full GC服务A是个内部查询平台一直很稳定。某次发版之后第4天凌晨1点开始Full GC频率明显上升到中午堆内存被打满进程直接OOM。监控显示老年代占用每天在涨而且涨幅一天比一天大GC回收后老年代占用率仍然保持在90%以上。这是非常典型的泄漏曲线。翻看发版记录改动涉及一个查询接口的优化。开发说只是加了个上下文参数没动什么内存相关的代码。但从天起算时间点和发版完全吻合。4.2 场景四与四的现场字符串数组与缓存的障眼法这个案例有点特殊报错关键词是Java heap space但dump分析后我发现对象大头是大量byte[]和String继续往里钻发现它们全被同一个业务对象引用着。那种情况不能光看Histogram因为任何业务数据最终落到内存里都是String和byte[]关键是要找到真正持有这些数据的外层对象。于是打开Dominator Tree按Retained Heap排序排第一的果然是一个自定义业务类再往下展开这个类里有一个MapMap里存放了海量查询结果。代码review后确认这段逻辑在业务方法里把查询结果无条件放进了静态Mapkey是查询参数拼接的字符串value是查询结果。原本设计者以为数据量不大但实际查询参数组合是无限的缓存只增不减。这类案例的处理方式比较简单把静态Map换成Caffeine设置最大容量和过期时间或者数据量确实大就走Redis缓存。核心教训是一样的——本地缓存无上限就是给内存埋雷。4.3 ThreadLocal案例线程池下的借尸还魂另一个高频案例发生在ThreadLocal上。现象、告警方式都和第一个案例高度相似但dump里看到的引用链更隐蔽Thread-ThreadLocalMap-Entry-业务上下文对象很多同学对ThreadLocal的认知停留在用完之后会释放但实际上容器线程池场景下线程是复用的ThreadLocalMap里的Entry不会因为一次请求结束就清理。关键点在于ThreadLocalMap.Entry的key是ThreadLocal实例用的是弱引用但value是强引用。线程池里的线程存活时间极长作为GC Root一直存在。只要线程不死ThreadLocalMap里的value就会一直强引用着目标对象。所以说ThreadLocal本身不泄漏泄漏的是误用了ThreadLocal并且没有remove。正确姿势是ThreadLocalContext ctx new ThreadLocal(); try { ctx.set(buildContext()); // 业务逻辑 } finally { ctx.remove(); }这个案例最后的修复代码只有几行排查的过程却走了大半天。原因就是第一反应一直在业务缓存上找忽略了线程引用链。4.4 这类案例给我们的通用排查顺序把两个案例放一起可以得出一个通用规律出现堆内存泄漏先按概率排优先级——静态集合、无界缓存、ThreadLocal后置清理不足、连接/IO未释放、容器对象生命周期超长。其中静态集合和缓存占了最多数ThreadLocal次之连接泄漏反而在连接池普及后少了很多。抓dump后不要被String和byte[]充斥的Histogram吓到Dominator Tree能直达幕后对象顺着幕后对象的引用链走基本都有明确答案。5. 排查工具的组合拳jmap、MAT、Arthas这样用才顺手工欲善其事必先利其器。排查工具的掌握程度直接决定了定位OOM的时间成本。我把日常最常用的一套组合和踩坑点整理如下。5.1 生产环境第一梯队命令按使用场景选命令用途风险等级使用建议jps -l找到目标JVM进程PID无第一步必用jstat -gcutil pid 1000实时看GC、堆内存走势无方向判断利器jmap -dump:formatb,filexx.hprof pid抓堆dump中会暂停业务摘流量后使用jmap -histo pid看对象分布低不触发FGC适合粗筛jmap -histo:live pid看存活对象分布高会触发Full GC生产环境慎用高峰禁用jstack pid看线程栈无排查线程数超限、死锁jcmd pid VM.native_memory summary看Native内存分布无需启动时开启NMT这里必须提醒很多教程会推荐jmap -histo:live用于分析但live会强制执行一次Full GC在内存已经很紧张的进程上可能直接演变成雪崩。我在生产上几乎不用-histo:live要粗筛对象分布jmap -histo足够要精确分析就直接抓dump离线看。5.2 MAT的使用别被Histogram带偏MATMemory Analyzer Tool是我最常用的dump分析工具。打开一个几百MB甚至几个GB的dump如果本机内存不够先改MemoryAnalyzer.ini里的-Xmx否则MAT自己会OOM。打开之后不要第一时间进Histogram。很多新手看到Histogram里全是byte[]和String瞬间不知道怎么继续。我建议按这个顺序走Leak Suspects报告让MAT自动帮你圈定可疑对象看它的结论和解释。Dominator Tree在怀疑对象上右键展开看最顶层的支配者是谁。支配树的价值在于它按保留堆计算能消解掉String/byte[]带来的干扰直接展示最外层的容器。Path to GC Roots从支配者右键找GC引用路径这条路径就是代码定位的直接证据。在MAT里看Path to GC Roots时有一个小细节默认会排除弱引用但不排除强引用所以你能直接看到强引用链。如果链路上出现java.lang.Thread基本可以断定和线程池、ThreadLocal有关如果出现类名里的静态字段比如com.xxx.Processor.cache那么静态集合的问题就实锤了。5.3 Arthas在生产环境的几个高光时刻生产环境不能随意停应用Arthas这类在线诊断工具的价值就体现出来了。我常用的命令dashboard实时看到内存、GC、线程的概览判断方向比jstat更直观。memory直接输出堆、非堆、直接缓冲区等各区域使用情况。heapdump不需要摘流量就能导出堆快照虽然也会STW但比裸用jmap友好。thread -n 3按CPU占用排序线程排查线程数超限、线程卡死都很方便。watch在线追踪某个方法入参和调用次数在复现阶段能快速确认某个接口是否就是泄漏入口。Arthas还有一个好处它不要求目标JVM以特殊参数启动attach上去就能用。这意味着很多当时没留dump、但是进程还活着的现场还有补救机会。5.4 dump之外的思路前端和其他中间件是同一套方法论排查思路是可以跨技术栈复用的。前端内存泄漏排查Chrome DevTools里的Heap Snapshot两次对比、Performance面板的JS堆内存曲线本质上和MAT的比较dump找不回收对象是一样的。Kafka的broker OOM、Netty的堆外泄漏排查链路仍然是留现场、看趋势、找最大占用、反查引用关系。工具不同方法论一致。经验不要等出问题了才学工具。找一台测试环境JVM人为构造一个静态List塞数据再手动触发OOM把整个抓dump - MAT分析 - 定位引用链流程跑两遍熟练之后线上再怎么忙也不会慌。6. 把OOM扼杀在发布之前监控指标与代码防泄漏清单排查是事故发生的功课但对团队来说更值钱的是让OOM在发布前就失去生存土壤。这一节聊预防层面的落地手段。6.1 上线前就配好的兜底参数即使预防做得再好也要假设某次发版还是会出问题。所以启动参数必须在一开始就配齐# JDK8 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/oom-%p.hprof -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize64m -XX:PrintGCDetails -XX:PrintGCDateStamps# JDK9 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/oom-%p.hprof -Xlog:gc*:file/data/logs/gc.log:time,uptime,level:filecount10,filesize64m如果希望OOM时进程直接退出由编排平台重启可以加-XX:ExitOnOutOfMemoryError避免进程在半死不活的状态下持续接受流量、持续报错。HeapDumpPath目录要提前确认写权限和磁盘空间。我见过一次事故OOM发生时确实触发了自动dump但磁盘空间不足dump写到一半失败现场直接丢失。这个细节太容易栽了。6.2 监控指标报警的不应该是OOM本身很多团队的OOM告警是基于检测到OutOfMemoryError日志这已经是灾难发生后的通知了。真正有价值的告警应该前置到内存趋势上。我建议至少盯住几个指标堆内存使用率的日趋势和周趋势。老年代占用率特别是Full GC后的老年代占用率。Full GC频率和单次耗时。GC后堆回收比例等于回收掉多少/GC前占用多少。如果这个比例持续走低就是泄漏前期信号。原文连接应用RT/P99在Full GC频繁期的抖动情况。告警阈值不要只配绝对值比如老年代大于70%因为很多服务常年老年代60%也正常。更好的方式是对曲线的斜率做告警连续7天老年代占用率的日最低值逐日递增哪怕每日只涨1个百分点也值得人工关注。内存泄漏从来不是一分钟爆炸的它会给足你机会只是很多团队没设这类告警。举个量化例子便于和开发、运维对齐严重性如果每个请求泄漏512KBQPS是100那么一天泄漏约4.3GB512KB × 100 × 86400秒 / 1024 / 1024。也就是说4GB堆撑不过一天。这类计算在故障复盘和需求评审里非常有说服力能让评估缓存容量ThreadLocal记得remove从嘴上说说变成硬性评审项。6.3 代码防泄漏自查清单贴在CI门禁旁边每次发布前代码评审增加一栏内存安全检查重点看静态集合是否有容量上限和淘汰策略无界Map存入业务数据必须给出理由。ThreadLocal初始化在方法内部是否保证了finally里的remove特别关注线程池场景。IO、网络连接、JDBC连接是否使用try-with-resources。批量插入/导出是否分批避免一次性把全量数据载入内存。本地缓存组件是否配置了最大容量和过期时间换Caffeine或Guava后是否配置了淘汰。异步任务队列是否有界无界队列在生产者速度大于消费者时本身就是内存泄漏的温床。动态生成类、脚本编译是否有类加载器回收机制Metaspace的坑大多来自这里。6.4 稳定性压测里的泄漏预演最后一个建议把内存泄漏纳入稳定性压测的通过标准。每次大版本发布前在测试环境跑48小时稳定性压测过程中持续记录老年代占用和Full GC次数。如果48小时内Full GC次数越往后越频繁老年代占用没有回归哪怕没有OOM也要按泄漏预警处理。通常这类问题在测试环境跑24小时以上就会露出端倪但很多团队的压测只跑半小时一小时完全不足以暴露内存缓慢增长的问题。把压测时长拉长是最便宜的线上事故保险。每次做稳定性压测的时候我习惯在压测结束后再抓一次heap dump和触发一次Full GC对比压测前后的对象分布。如果发现压测后静态缓存类、业务收集类的对象数量没有回落就说明这个场景下存在对象残留值得在上线前修掉。结合个人经验说几句我一般会在每次发版后连续盯三天的内存曲线不看告警只看斜率。如果老年代占用第三天比第一天还高说明有东西没释放立刻回去翻最近改的代码。这个习惯帮我提前拦下过好几次线上事故比任何工具都便宜也比任何经验都可靠。内存泄漏这件事从来不会只给你一次机会但也不要幻想着它每次都给你机会。把现场留好把趋势盯住剩下的就是把工具用顺、把清单落到实处。