生产问题排查与性能瓶颈定位日志、监控、链路追踪、压测与 Arthas生产问题最怕的不是报错而是没人知道从哪下手。一个接口突然变慢用户说提交订单失败监控开始报警日志里一堆异常CPU 又有点高。这个时候如果只是凭感觉去猜很容易越查越乱。生产排障要有顺序先确认影响范围再拿日志、监控、链路追踪定位层级然后用压测或复现缩小问题必要时用 Arthas 进入 JVM 内部观察最后修复、验证、复盘。一、先把问题说清楚遇到生产问题第一步不是打开代码而是把问题描述清楚。至少要回答这几个问题问题目的什么时间开始缩小日志和监控时间范围影响哪些用户判断是否全量故障哪些接口异常定位业务入口表现是什么区分慢、错、卡、丢数据是否刚发布判断和变更是否相关是否有外部依赖判断第三方、数据库、缓存、消息队列是否异常可以用这个流程先收口不要一上来就问是不是数据库慢。数据库当然可能慢但也可能是线程池打满、缓存击穿、远程服务超时、锁竞争、GC 停顿、发布引入了死循环。排障最重要的是用证据缩小范围。二、一条通用排障主线生产问题可以按现象、范围、层级、原因、修复、验证来推进。这个顺序很笨但很稳。它避免了一个常见问题还没确认影响范围就开始改代码还没确认瓶颈层级就开始加机器。三、日志看什么日志适合回答发生了什么。排查生产问题时先用时间范围和 traceId 收敛日志。常见查询条件条件示例时间2026-06-08 10:00:00 到 10:10:00服务名order-service级别ERROR、WARNtraceIda1b2c3d4业务主键orderId10086异常类型TimeoutException日志里重点看几类信息日志类型关注点异常栈报错位置和异常类型入口日志请求参数、用户、接口出口日志调用下游的耗时和返回码慢调用日志哪一步耗时最高业务状态日志数据状态有没有异常跳变一个好的排障日志应该能回答请求有没有进来。请求在哪一步失败。失败前后关键业务状态是什么。下游调用是否成功耗时多少。异常是否集中在某个服务、某台机器、某类用户。如果日志只能看到操作失败看不到业务主键和调用耗时那不是排障能力差而是日志本身没设计好。四、监控看什么监控适合回答系统状态是否异常。排查时不要只看 CPU。CPU 高只是现象不一定是根因。常见指标与可能问题指标可能问题CPU 高计算密集、死循环、频繁 GC、线程竞争内存上涨缓存过大、对象堆积、内存泄漏Full GC 频繁堆空间不足、对象生命周期异常线程数过高线程池配置不合理、阻塞调用多磁盘 IO 高日志过量、慢查询、大文件读写网络延迟高下游依赖慢、跨机房访问、网络拥塞错误率升高业务异常、依赖失败、发布缺陷响应时间升高数据库慢、锁竞争、远程调用慢监控的核心监控的核心不是看一个点而是看趋势和关联。例如接口变慢时应该同时看如果 QPS 没变CPU 没变但数据库慢查询突然增加很可能瓶颈在数据库。如果 QPS 暴涨线程池队列堆积下游超时增多问题可能是流量超过了服务承载能力。如果响应时间呈周期性尖刺同时 Full GC 频繁就要重点看 JVM 内存。五、链路追踪看什么链路追踪适合回答慢在哪里。一次请求经过多个服务时单看日志很容易碎。链路追踪能把调用关系画出来并显示每一段耗时。看到这条链路就不用猜了——主要耗时在优惠券服务。链路追踪通常关注维度说明调用拓扑请求经过哪些服务单段耗时哪个服务或方法最慢错误节点哪个下游返回错误调用次数是否出现重复调用traceId和日志关联定位细节常见工具有 SkyWalking、Zipkin、Jaeger、OpenTelemetry 体系。工具名字不重要重要的是系统要能把日志、指标、调用链用同一个 traceId 关联起来。有了这种关联排查体验会完全不同。六、压测用来验证瓶颈压测不是为了跑一个漂亮数字而是为了知道系统在哪个压力点开始撑不住。注意压测通常在上线前或压测环境做用来验证容量和找潜在瓶颈生产排障是在问题已经发生时用日志、监控、链路追踪、线程栈、Arthas 等手段收集证据。不要为了定位线上问题直接在生产环境随意压测那很容易把故障扩大。常见指标指标说明并发数同时发起请求的用户或线程数量QPS每秒处理请求数吞吐量单位时间处理的请求或数据量响应时间从发出请求到收到完整响应的耗时延迟从发出请求到收到首个响应的耗时错误率失败请求占比CPU服务端计算资源使用情况内存堆内存、缓存、对象堆积情况磁盘 IO日志、数据库、文件读写压力网络 IO上下游传输压力响应时间和延迟不是完全一回事。在 JMeter 里elapsed time 更接近一次请求从发送前到完整响应接收后的耗时latency 更接近从发送前到收到响应第一部分的时间。实际分析时响应时间更适合看用户整体等待延迟更适合看服务开始响应的速度。压测流程压测时不要只看 JMeter 报告。客户端报告告诉你请求表现如何服务端监控告诉你为什么会这样。常见压测现象与瓶颈现象可能瓶颈QPS 上不去CPU 很低线程池、连接池、下游阻塞QPS 上升后错误率升高服务容量不足或限流触发响应时间越来越长队列堆积、锁竞争、数据库慢CPU 打满计算逻辑重、序列化开销大、死循环Full GC 频繁内存分配过快、对象无法回收数据库连接池耗尽SQL 慢、事务过长、连接未释放压测结论要落到可执行动作上扩容、调线程池、改 SQL、加缓存、拆热点、限流、降级、异步化或者修代码。七、Arthas 适合查什么Arthas 是 Java 线上诊断工具适合在不重启应用的情况下观察 JVM 内部状态。常用场景场景Arthas 能做什么CPU 高看线程占用和调用栈方法慢trace 方法耗时参数异常watch 方法入参和返回值怀疑代码版本不对jad 反编译已加载类内存异常看 JVM 内存和对象情况日志级别不合适动态查看或调整 logger常用命令dashboard查看 JVM、线程、内存、GC 等实时概览。thread查看 Java 线程信息。CPU 高时经常用它找热点线程。thread-n5查看最忙的几个线程。jadjad com.example.OrderService反编译 JVM 里实际加载的类确认线上运行的代码是不是你以为的版本。tracetrace com.example.OrderService createOrder跟踪方法内部调用耗时适合定位慢在哪个子调用。watchwatchcom.example.OrderService createOrder{params, returnObj, throwExp}-x3观察方法入参、返回值和异常。使用注意事项Arthas 很强但不能乱用。trace、watch这类命令会对目标类做字节码增强生产环境使用时要精确指定类和方法避免范围过大。用完要及时reset或stop。八、远程调试要谨慎远程 debug 很好用但它不适合随便用在生产环境。原因很简单断点可能让线程挂起业务请求会被卡住如果断在锁、事务、连接池相关位置影响会被放大。更麻烦的是生产数据是真实用户数据调试过程还有权限和安全风险。合理边界环境建议本地可以自由 debug测试环境可以远程 debug预发环境谨慎 debug尽量模拟生产流量生产环境默认不使用断点式远程 debug生产环境更推荐用日志、监控、链路追踪、Arthas、线程栈、堆转储、慢查询等方式拿证据。如果极端情况下必须在生产环境打开诊断能力也要满足几个条件审批明确、范围极小、时间极短、有人值守、随时可回滚。能不用断点就不用断点。九、常见问题怎么定位接口突然变慢如果慢点在数据库就查慢 SQL、索引、锁等待、连接池。如果慢点在下游接口就查下游错误率、超时配置、重试策略。如果慢点在本服务就查线程池、锁、CPU、GC、热点方法。CPU 飙高可以用 Arthas 的thread -n 5看热点线程也可以用系统命令配合线程栈。关键是找到具体线程正在执行的代码而不是只说CPU 高。内存持续上涨内存问题要区分类型表现正常高水位GC 后能回落内存泄漏GC 后仍持续上涨瞬时大对象某些请求触发大分配缓存无上限数据越跑越多数据库慢很多线上数据库问题不是 SQL 写错这么简单而是流量上来后索引选择变差、事务持有时间过长、热点行竞争、连接池配置过小或者应用重试把数据库打得更狠。消息堆积消息堆积时不要只扩消费者。要先确认消费者是不是因为下游慢、数据库慢、代码异常导致消费失败。如果根因不解决扩容只会把压力更快打到下游。十、项目难点怎么表达很多技术面试会问项目中遇到过什么难点。这个问题不能回答成我用了 Redis、MQ、ELK、Arthas工具名不是难点。一个好的表达结构可以按这个模板讲当时订单服务在活动期间出现响应时间升高主要表现是下单接口 P95 从 200ms 涨到 1.5s错误率也有抬升。我先通过监控确认不是全站故障而是订单链路变慢再用 traceId 查日志和链路追踪发现耗时主要集中在库存扣减和优惠券锁定随后结合数据库慢查询和连接池监控确认优惠券服务存在慢 SQL并且失败重试放大了数据库压力。处理上我们先临时降级非核心优惠券规则降低活动期间的下游压力随后优化 SQL 和索引调整连接池与超时重试策略并补充了慢调用告警。最终下单接口 P95 恢复到 300ms 以内错误率回落后续活动期间没有再出现同类故障。这段话有几个关键点有业务背景。有明确指标。有排查路径。有根因。有解决动作。有结果验证。这才像真实做过项目的人讲出来的。十一、一套生产排障清单具体动作可以按优先级来阶段动作止血回滚、降级、限流、扩容、切流量定位日志、监控、链路追踪、Arthas、慢查询修复改代码、调配置、优化 SQL、补缓存、改重试验证看错误率、响应时间、QPS、业务成功率复盘补告警、补日志、补压测、补预案总结生产排障的关键不是会背多少工具而是能不能沿着证据链把问题一步步压缩。从用户说慢压缩到某个接口慢。从某个接口慢压缩到某个服务慢。从某个服务慢压缩到某个方法、某条 SQL、某个下游调用慢。再从这个点拿出修复方案和验证结果。这就是排障能力。