凌晨两点被电话从床上拽起来登录堡垒机发现应用刚 OOM 重启完再翻监控又看到下午有几个超时毛刺线上恢复稳定后测试同学跑了一轮又一轮回归就是复现不了。干过几年后端研发或线上运维的人对这种场景应该都不陌生。这类问题最磨人的地方不是技术多深而是“证据不完整”OOM 瞬间进程没了超时毛刺一秒钟就过去等你想抓现场什么都没了。这篇文章我想把自己在类似问题上积累的排查思路完整梳理一遍。它不是某个具体 bug 的复盘而是一套可以套用的方法论先搞清楚为什么测试环境复现不了再把监控和日志做成“战备状态”然后分别针对 OOM 和随机超时给出从现象到根因的定位路径最后聊聊怎么用压测、故障注入、流量录制等方式让偶发问题稳定复现。适合正在被这类线上故障折磨的后端开发、运维工程师、SRE以及想提前建立排查体系的团队参考。1. 先搞清楚为什么生产环境出问题测试环境就是复现不了很多人上来就想着“复现”但复现不是第一步。第一步应该先想明白同样一套代码为什么生产就偶发 OOM、随机超时测试环境怎么跑都稳如果这个问题不想清楚后面所有复现尝试都是碰运气。1.1 流量与并发特征的巨大差距测试环境通常只有个位数到几十个 QPS生产环境可能是几百上千甚至上万 QPS。这个差距直接决定了很多问题只会出现在高并发下线程池排队低并发下每个请求都能及时拿到线程高并发下线程池一旦打满请求就开始等待表现为随机超时。锁竞争并发低的时候锁基本不会冲突并发高起来同一个锁上的线程可能堆积成一片 BLOCKED 状态响应时间瞬间拉高。内存分配速度高并发意味着短时间内会创建大量对象如果某个入口有“大对象”或“一次性加载大量数据”的逻辑生产环境的内存膨胀速度远超测试环境OOM 就是这样被触发的。我见过一个典型场景一个接口每次会把某张表的数据全量加载到内存做过滤测试环境表里只有几百条数据一点问题没有生产环境这张表有上千万行并发一上来直接堆内存爆炸。这种问题在测试环境跑到天荒地老也复现不了因为核心变量是“数据规模 × 并发数”两个条件缺一不可。1.2 数据分布与调用链路的差异生产环境的数据分布远比测试环境复杂。比如 Redis 里存在大 Key某个热点 Key 的访问量在特定时段飙升比如一条 SQL 在测试环境走索引只要几毫秒生产环境因为数据量大、统计信息不准优化器选了全表扫描耗时变成几秒钟。这些由数据引发的“偶发”问题测试环境如果只用了裁剪后的样本数据很难暴露出来。另外生产环境的调用链路更长也更真实。你依赖的第三方接口、下游 RPC 服务、数据库主从延迟、消息队列积压这些都是真实存在的。下游一旦抖动上游就会出现随机超时而测试环境的下游往往是 mock 的或空跑的稳定性好得不像话。1.3 部署拓扑与资源配置的差异容器内存限制、JVM 堆大小、连接池上限、超时配置、操作系统参数这些在生产环境和测试环境往往不一样。比如测试环境容器内存是 2GJVM 堆设了 1G生产环境容器内存是 1GJVM 堆却按习惯还是设了 1G那堆外内存一涨起来就容易把容器打爆直接触发 OOM Killer而不是 JVM 内部的 OutOfMemoryError。还有一类问题纯粹是“环境差异导致的路由漂移”。比如生产环境是多实例部署Nginx 负载均衡会把请求分散到不同节点某个节点因为机器旧一点、或镜像部署时漏了什么配置表现就是“每 10 个请求偶尔超时 1 个”测试环境单实例永远复现不了。所以收到这种问题后我建议做的第一件事不是去翻代码而是先拉一张“生产 vs 测试”的环境差异表把流量、数据量、资源配置、依赖关系列清楚。后面所有排查动作都围绕这些差异展开。2. 排查前置动作把监控、日志和现场存证做到“战备状态”很多人排查这类问题时的困境是问题发生的时候没有数据等发现问题了现场已经被重启回收了。所以任何偶发问题的排查前提是“有现场可查”。这需要在问题发生之前就把工具链准备好而不是等出事了再临时抱佛脚。2.1 日志规范全链路 TraceId 与异常上下文先看日志。如果你们的系统还没有统一的全链路 TraceId我建议先把这件事补上。没有 TraceId 的话一个请求在多个服务之间穿来穿去超时了你都不知道卡在哪个环节。有了 TraceId至少能把“随机超时”的请求链路串起来看它走到哪个服务、耗时花在哪一段。具体可以这样做在网关或入口处生成 TraceId通过 HTTP Header 或 RPC 隐式参数往下游传递。日志框架里统一打印 TraceId和业务日志、异常堆栈关联。对慢请求单独打点超过阈值比如 1 秒打印一条“慢请求日志”包含完整的入参、出参、耗时、TraceId、线程名。OOM 发生前往往有前兆比如 GC 频繁、内存持续上涨这时候业务日志里可能会出现“创建大对象”“批量加载”相关的痕迹。所以也要保证 OOM 之前那段时间的日志没有被滚动清理掉。日志这步看起来不起眼但它是整个排查过程中性价比最高的一环。很多随机超时问题靠慢请求日志直接就能定位到具体接口。2.2 系统监控容器内存、GC、线程、网络重传全覆盖监控指标不是越多越好而是要覆盖“可能出问题的维度”。针对 OOM 和超时我建议至少盯这几类指标内存指标容器内存使用量如 container_memory_working_set_bytesJVM 堆内存、非堆内存、元空间使用量GC 次数和耗时。GC 指标Young GC 频率、Full GC 频率、单次 GC 停顿时间。如果 Full GC 频繁说明堆内存压力很大很可能是 OOM 前兆同时也会导致随机超时。线程指标活跃线程数、线程池队列长度、BLOCKED / WAITING 状态的线程数。网络指标TCP 重传率、建立连接数、连接池活跃连接数、TIME_WAIT 数量。下游依赖指标每个下游接口的 P99 耗时、错误率、超时次数。有了这些指标后回到问题本身基本能区分出方向如果超时发生时 Full GC 频繁那超时大概率是 GC 停顿导致的如果线程池队列长度暴涨那就是线程不够用如果 TCP 重传率飙升那可能是网络层问题。这里顺便提一句生产环境的监控要保留足够长的历史。很多偶发问题是“一天出现两三次”如果监控只留 6 小时你可能连毛刺都看不全。建议关键指标至少保留 30 天。2.3 现场存证自动抓取 Dump 和线程栈监控是“事前”的眼睛但真正出问题时还需要“现场证据”。OOM 场景下最重要的证据就是堆 Dump 和 GC 日志超时场景下最重要的是线程 Dump。这些东西必须自动化不能等人工去抓。一个很实用的组合是JVM 启动参数加-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/dumps这样每次 OOM 时 JVM 会自动把堆快照写到指定目录进程随后崩溃但 Dump 文件留下来了。GC 日志打开建议同时保留 GC 前后的内存变化、各代容量、停顿时间。JDK 8 的写法是-Xloggc:/data/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStampsJDK 11 可以用统一日志-Xlog:gc*:file/data/logs/gc.log。对线程栈可以写一个简单的定时任务比如每 5 分钟抓一次jstack到文件或者接入 Arthas 的thread命令做周期性采样。超时问题发生时如果能抓到当时的线程栈一眼就能看出是卡在锁上、等待数据库还是线程池排队。我自己踩过一个坑早期遇到 OOMJVM 还是默认配置没有开 HeapDump进程一崩什么都没留下只能靠猜。后来所有线上 Java 服务强制统一加这些参数排查成本直线下降。如果你们公司容器化程度比较高还可以让容器在退出前把相关日志和 Dump 持久化到共享存储避免 Pod 被回收后证据丢失。3. OOM 专项排查从堆转储到根因定位的完整路径做好了前置准备下一步是针对 OOM 做专项排查。OOM 不是一种病而是很多种病共有的症状。不同区域的“内存不够用”对应的排查手段完全不一样。3.1 拿到堆 Dump 后怎么快速定位如果启动了-XX:HeapDumpOnOutOfMemoryErrorOOM 时会生成一个 .hprof 文件。这个文件就是破案的核心。推荐用 Eclipse MAT 或 JProfiler 打开我平时用 MAT 多一些因为免费且对内存分析够用。打开 Dump 之后先看Overview页面的几个关键信息总的堆大小和已经使用的量。最大的对象类型是什么。如果是byte[]或char[]占大头那大概率是“缓存了大字符串、读取了大文件、或批量加载了数据库记录”。Leak Suspects视图会给出疑似泄漏的调用链虽然它不一定完全准确但能给一个不错的入手方向。我的习惯是先用Dominator Tree支配树看从 GC Roots 到最大对象的引用链。这里有个很典型的场景一个HashMap里塞了大量对象但你没看到明显的“泄漏代码”那就要看这个 Map 是被谁持有的。有可能是本地缓存没设过期时间、ThreadLocal 没清理、静态集合在并发下不断增长。还有一种情况是堆里全是一些“小对象”的重复实例比如 Kafka consumer 拉取消息时把整个 MessageSet 读进内存又因为批量配置过大一次拉了几万条每条又包装成新对象。表面上没有泄漏其实每个请求/每条消息创建的对象都滞留到了 GC 来不及回收最终 OOM。这种问题靠 Dump 能看出来但需要结合业务代码进一步确认。3.2 GC 日志与堆内存参数解读Dump 是“死后”的证据GC 日志是“生前”的过程记录。两者配合起来才能还原 OOM 是怎么一步步发生的。看 GC 日志时重点关注几个信息Young GC 后存活对象大小有没有明显上升。如果持续上升且波动大说明有对象晋升到了老年代老年代可能很快被打满。每次 Full GC 前后的内存占用。如果 Full GC 后内存降不下来说明老年代里堆了无法回收的对象。GC 停顿时间。如果 Full GC 停顿长达几秒业务侧的表现就是“随机超时”——请求刚好撞上 GC 停顿窗口响应就慢了或直接超时。一个常见的调优点是-Xmx和-Xms设成了固定值比如都是 2G。这种做法优点是避免堆大小动态变化但缺点是给堆外内存、线程栈、元空间留的余量不够容器可能被整体压爆。我的经验是容器内存如果是 4GJVM 堆最多设 2G剩下的给堆外内存、线程栈、DirectByteBuffer、Metaspace、JIT 等留足余量。还有一个容易被忽视的参数是-XX:MaxDirectMemorySize它控制 DirectByteBuffer 的上限。很多 OOM 不是堆内存溢出而是堆外内存被 NIO 的 DirectBuffer 吃光了但错误信息里也可能显示为OutOfMemoryError: Direct buffer memory。排查时如果 Dump 文件很小而内存占用很高就要怀疑堆外内存。3.3 常见的 OOM 触发场景拆解我把实际工作中遇到过的 OOM 场景整理成了一张表方便对号入座错误信息典型场景核心排查手段Java heap space堆内存被大对象、缓存、批量加载撑爆堆 Dump MAT/Dominator TreeGC overhead limit exceededGC 反复回收但内存回收效果差98% 时间在 GCGC 日志、线程栈、检查内存泄漏Metaspace动态生成类过多如反射、CGLIB、热部署监控 Metaspace 使用量检查类加载器泄漏Direct buffer memoryNIO 使用 DirectByteBuffer 超出MaxDirectMemorySize检查是否未释放 ByteBuffer、Netty 相关代码unable to create native thread线程数超过操作系统限制无法再创建线程查看线程数、ulimit 限制、线程池滥用举个例子Kafka 消费端 OOM 很常见。很多团队把max.poll.records调大想提升吞吐但没考虑单条消息的大小。如果业务高峰期消息量暴涨一次 poll 加载到内存的消息总大小可能达到几百 MB堆自然就爆了。再比如Spring Boot 工程本地开发时遇到 OOM很多人第一反应是调整 IDE 里 JVM 运行内存把-Xmx调大。这个思路没错但如果生产环境也 OOM光调大堆内存往往治标不治本关键还是要找到谁把内存吃掉了。4. 随机超时专项排查从网络到线程池逐层定位随机超时比 OOM 更隐蔽因为它的“证据链”更短可能只有一条超时报错没有 Dump 也没有现场。排查超时问题的思路是分层的先看网络再看容器和 JVM再看线程池和连接池最后看下游依赖。每一层都有对应的观测手段。4.1 第一层网络与连接层很多人一想到超时就直接怀疑代码但网络层的排查优先级应该更高。一个很典型的现象是客户端报了 Read timed out但服务端日志显示请求根本没收到。这时候就不是服务端处理慢而是网络传输出了问题。网络层要看的指标TCP 重传率如果重传率飙高说明网络丢包严重数据一直在重传延迟自然上去了。连接数连接数打满会导致新连接排队或失败。TIME_WAIT 数量大量短连接下TIME_WAIT 积累过多会占用端口资源导致新连接无法建立。DNS 解析耗时偶尔的 DNS 慢也会造成请求超时尤其是驱动里配置了域名而不是 IP 时。我自己就遇到过一次诡异超时客户端调服务 A 偶尔超时但查看服务 A 的日志记录到的耗时只有几十毫秒。后来在客户端所在机器上抓包发现 TCP 重传率高达 5%是底层基础设施丢包引起的。这种问题你再怎么优化代码都没用只能推动网络团队处理。一个小技巧超时发生后第一时间用tcpdump在客户端和服务端双侧抓包对比同一请求的发出与到达时间能快速判断时间消耗在网络中还是服务端处理中。4.2 第二层容器与 JVM 资源争抢容器化部署下一个常见的隐蔽原因是 CPU 限流。Kubernetes 里给 Pod 设置了 CPU limit但实际使用中如果连续时间段内 CPU 使用率达到上限内核会进行 CPU Throttling表现为进程的 CPU 时间片被限制处理能力瞬间下降请求处理变慢反映到上游就是随机超时。排查方法是看 CPU Throttling 指标比如容器运行时的 throttled 时间。这种问题在测试环境很难复现因为你测试时根本不会把 CPU 打到限流阈值。另一个隐蔽原因是 GC。之前说过Full GC 停顿期间所有用户线程都会暂停请求处理被“冻结”几百毫秒甚至几秒。如果业务方设置了 1 秒超时那 GC 停顿超过 1 秒的请求就会超时。所以超时和 OOM 有时是同一根因下的两种表现内存持续膨胀 - GC 越来越频繁 - 随机超时出现 - 最终 OOM。如果是这种情况你会在监控里看到Full GC 次数和超时毛刺的时间点高度吻合。解决方向也很明确优化内存使用、调整堆大小、减少大对象分配而不是单纯加长超时时间。4.3 第三层线程池与连接池耗尽线程池耗尽是我见过最常见的超时原因。典型过程是某个慢接口占住了线程迟迟不释放后续请求全在队列里排队等待前端设置的超时时间到了客户端就报超时但服务端日志里可能能看到这些请求实际是被处理了只是耗时超出了客户端的耐心。排查线程池耗尽的直接手段是线程 Dump。在问题发生时抓jstack看线程都处于什么状态大量线程处于WAITINGparking大概率是线程池任务队列已满任务在等待可用线程。大量线程处于BLOCKED存在锁竞争多个线程在等同一把锁。大量线程处于TIMED_WAITING可能在等数据库连接、远程调用响应或Thread.sleep。还有一类隐蔽问题Java 8 和部分框架下HttpClient连接池或数据库连接池配置过小并发一高连接就不够用了。比如 Spring Boot 项目的默认 Tomcat 线程池是 200如果 200 个线程全被慢 SQL 占住后面的请求就只有排队。这时候把 Tomcat 线程数调大只是延后问题重点还是解决慢 SQL 和下游慢调用并给每个调用设置合理的超时时间。顺带提一个很有代表性的场景代码里用了限流器比如 Guava RateLimiter 或 JDK 的Semaphore.tryAcquire(timeout)超时时间单位理解错了也会引发奇怪的超时。有人把 1 写成了 1 毫秒结果稍微一排队就限流失效或疯狂抛超时异常。这种问题一行一行看配置就能发现但确实花了我不少时间去排查。4.4 第四层下游依赖异常与超时配置到了这一层问题是“别人家引起的”。下游服务慢、第三方接口不稳定、数据库锁等待、Redis 阻塞都会导致上游随机超时。排查手段主要靠链路追踪从 TraceId 里看到请求在下游停留了多久就能把责任方划分出来。数据库方面的常见坑连接池参数不合理如maxActive太小、connectionTimeout设置过短高峰期拿不到连接导致超时。SQL 走了全表扫描或索引失效数据量一涨查询就变慢。数据库主从延迟读操作路由到了延迟严重的从库。存在长事务锁等待时间拉长其他请求全部阻塞。Redis 方面也要注意大 Key、慢命令如KEYS *、集群节点故障等。这些问题都有个共同特点下游平时正常只有特定时段或特定数据才会触发所以表现为“随机”。我建议每个 JAVA 服务都梳理一遍所有外部调用的超时配置HTTP 调用要设置连接超时、读取超时三个值都要有。数据库连接池要设置获取连接超时而不是无限等待。RPC 调用要设置超时和重试策略但重试次数不宜过多否则会放大下游压力。5. 复现方法论有方法地从“复现不了”到“稳定复现”排查到最后你可能已经有了几个嫌疑点但还差一步证明在可控环境里把问题复现出来验证修复方案的有效性。对于这类偶发问题复现不能靠“多跑几遍碰运气”要有方法论。5.1 复现为什么难先找到“放大变量”偶发问题必然有一个或多个核心变量在起作用。复现的本质是把这个变量放大到足以触发问题的程度。常见的放大变量包括并发量通过压测把 QPS 抬到生产的 2 倍看内存和线程池是否先撑不住。数据量把测试数据灌到接近生产规模特别是大表、大缓存、大 Key。资源配置把测试环境的容器内存、JVM 堆设置成和生产一致甚至更小制造压力。时间周期有些问题是定时任务、缓存过期、日志轮转等周期性任务触发的需要按完整周期运行才能复现。举个例子如果怀疑是缓存穿透或缓存雪崩就不该在缓存命中的情况下测而应该把缓存全部清掉让请求直接打到数据库模拟热点失效的瞬间。很多“测试复现不了”其实是测试设计的问题——没有把触发条件构造出来。5.2 用压测和故障注入构造现场压测工具方面JMeter 是很多团队入门的选择它可以直接对 HTTP 接口做并发测试观察线程数、错误率、响应时间的变化。更专业的可以考虑 Gatling、Locust 这类支持脚本化压测的工具。但压测只能验证“压力够大时会出问题”不一定能复现真实的偶发场景。这时候可以结合故障注入比如模拟下游慢调用把某个依赖接口人为增加 3 秒延迟观察线程池是否被打满。模拟 GC 压力用工具触发频繁 Full GC观察超时是否出现。模拟内存泄漏增加不必要的内存分配逻辑快速造出 OOM 现场。模拟网络抖动在网关或主机层注入丢包、延迟验证重试机制和超时配置是否有效。ChaosBlade、tc/netem 这些工具都能做类似的事。故障注入的关键是“受控”在测试环境搞且每次只注入一个变量不然出了问题分不清是哪个变量引起的。5.3 生产环境的可观测性反哺流量录制与回放比压测更贴近真实的是流量录制与回放。方法是把生产环境的真实请求录制下来在测试环境或预发环境重新回放让服务“真实地再跑一遍”。这个方案比较适合 HTTP 接口和 Dubbo/gRPC 服务社区里有 GoReplay、AREX 等工具可以参考。流量录制回放的好处是它保留了生产的真实调用序列、参数分布和并发特征比压测构造的数据更真实。缺点是接入成本较高需要在前置代理或服务入口做流量拷贝并且要处理回放时的数据隔离问题比如避免把测试数据写进生产库。更轻量级的方式是“局部引流”在预发集群放一个影子节点把线上 1% 的流量切过去跑。这样既不给测试环境造数据又能让代码在真实流量下运行很容易暴露偶发问题。如果问题在影子节点复现了直接抓 Dump 和线程栈。这一套做下来“复现不了”的问题基本能变成“可控条件下稳定复现”。6. 常见问题与排查技巧实录直接可用的速查表与避坑经验最后整理一份速查表把排查过程中最常用的命令、工具和判断逻辑列出来方便遇到问题时直接对号入座。6.1 常用命令与工具速查场景命令 / 工具用途OOM 现场后分析堆jmap、Eclipse MAT、JProfiler分析堆 Dump定位大对象和引用链查看 JVM 内存与 GCjstat -gcutilpid实时查看各代空间占用和 GC 次数线程状态快照jstackpid查看线程状态、锁等待、死锁分析 GC 停顿GC 日志 GCViewer / gceasy.io看 GC 停顿时间、晋升情况、回收效果动态观测运行中的服务Arthasdashboard、thread、heapdump线上动态排查不重启进程网络抓包tcpdump、Wireshark定位网络层丢包、重传、延迟连接数统计ss -s、netstat、lsof查看连接数、TIME_WAIT、句柄占用压测JMeter、Gatling、Locust构造高并发场景验证问题故障注入ChaosBlade、tc模拟网络延迟、丢包、系统资源故障6.2 实际排查中的避坑经验先说我最大的一个体会不要在没有任何证据的情况下改配置、加超时时间。很多人遇到超时就把超时时间从 1 秒调到 3 秒遇到 OOM 就把-Xmx从 2G 调到 4G。这样做可能暂时掩盖了问题但下一个高峰期问题会以更严重的方式回来。调参只能作为短期止血不能作为根因解决方案。第二个经验是排查偶发问题时先把所有监控拿齐再说“不知道”。有相当一部分“复现不了”的问题其实不是复现不了而是当时没人看监控事后无法还原现场。如果监控历史足够长你至少能知道 OOM 或超时发生前 5 分钟系统是什么状态这能省下大量排查时间。第三个经验一定要重视“时间对齐”。把 OOM 时间、超时毛刺时间、GC 停顿时间、发布部署时间、数据变更时间放到同一张时间轴上对比。你会发现很多“随机问题”其实是“定时问题”每次定时任务一跑就 OOM每次凌晨批量数据处理完就超时每次发版后半小时开始出现毛刺。时间对齐是破案最有力的武器。第四个经验线程 Dump 要多抓几次抓连续序列。单次线程 Dump 可能正好抓不到问题现场但如果每 5 秒抓一次、连续抓 1 分钟基本能看到线程状态的变化趋势比如某个线程池的线程数是否持续增长、锁等待是否越来越严重。最后一个经验上线前把所有 JVM 参数、连接池参数、超时配置整理成巡检清单。我见过不少生产事故根因就是某个服务上线时漏配了超时时间、堆内存参数或连接池上限。如果团队能像检查上线清单一样检查这些参数一半以上的偶发问题根本不会发生。排查这类问题我最大的体会是它考验的往往不是局部代码能力而是“系统性地把监控、日志、现场证据、复现方法组合起来”的工程能力。偶发 OOM 和随机超时的根因五花八门但只要证据链完整绝大多数问题都能在几天内定位清楚。如果你们团队预算有限优先做好三件事开 HeapDump、配好 GC 日志、拉齐全链路 TraceId。这三件事的成本很低但足以让大多数“复现不了”的问题变成“有据可查”。