2024年最新Java系统线上生产问题排查一把梭，字节跳动java研发面试题社招

最后

Java架构学习技术内容包含有：Spring，Dubbo，MyBatis, RPC, 源码分析，高并发、高性能、分布式,性能优化，微服务 高级架构开发等等。

还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书+2021年最新大厂面试题。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

---

该环境下开发人员的权限最低，所以排查问题时障碍很大：

• 无法使用调试工具从远程附加进程

• 快速恢复为先，即使在结婚，也得赶紧修复线上问题。而且生产环境流量大、网络权限严格、调用链路复杂，因此更容易出问题，也是出问题最多的环境。

2 监控

===================================================================

生产环境出现问题时，因为要尽快恢复应用，就不可能保留完整现场用于排查和测试。因此，是否有充足的信息（日志、监控和快照）可以了解历史、还原bug 场景。

最常用的就是 ELK 的日志了，注意：

• 确保错误、异常信息可被完整记录到文件日志

• 确保生产上程序的日志级别是INFO以上

记录日志要使用合理的日志优先级，DEBUG用于开发调试、INFO用于重要流程信息、WARN用于需要关注的问题、ERROR用于阻断流程的错误

生产环境需开发配合运维才能做好完备监控：

主机维度

---

对CPU、内存、磁盘、网络等资源做监控。如果应用部署在虚拟机或k8s集群，那么除了对物理机做基础资源监控外，同样还要对虚拟机或Pod监控。监控层数取决于应用的部署方案，有一层OS就要做一层监控。

网络维度

---

监控专线带宽、交换机基本情况、网络延迟

所有的中间件和存储都要做好监控

---

不仅仅是监控进程对CPU、内存、磁盘IO、网络使用的基本指标，更重要的是监控组件内部的一些重要指标。比如最常用的Prometheus，就提供了大量exporter对接各种中间件和存储系统

应用层面

---

需监控JVM进程的类加载、内存、GC、线程等常见指标（比如使用Micrometer来做应用监控），此外还要确保能够收集、保存应用日志、GC日志

我们再来看看快照。这里的“快照”是指，应用进程在某一时刻的快照。通常情况下，我们会为生产环境的Java应用设置-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath=…这2个JVM参数，用于在出现OOM时保留堆快照。这个课程中，我们也多次使用MAT工具来分析堆快照。

分析定位问题的最佳实践

==========================================================================

定位问题，首先要定位问题出在哪个层次：Java应用程序自身问题还是外部因素导致。

• 可以先查看程序是否有异常，异常信息一般比较具体，可以马上定位到大概的问题方向

• 如果是一些资源消耗型的问题可能不会有异常，我们可以通过指标监控配合显性问题点来定位。

一般问题原因可归类如下：

程序发布后 Bug

---

回滚，再慢慢通过版本差异分析根因。

外部因素

---

比如主机、中间件或DB问题。

这种按主机层面问题、中间件或存储（统称组件）的问题分为：

主机层

可使用工具排查：

CPU相关

使用top、vmstat、pidstat、ps

内存相关

使用free、top、ps、vmstat、cachestat、sar

IO相关

使用lsof、iostat、pidstat、sar、iotop、df、du

网络相关

使用ifconfig、ip、nslookup、dig、ping、tcpdump、iptables

组件

从如下方面排查：

• 组件所在主机是否有问题

• 组件进程基本情况，观察各种监控指标

• 组件的日志输出，特别是错误日志

• 进入组件控制台，使用一些命令查看其运作情况。

系统资源不够造成系统假死

---

通常先通过重启和扩容解决问题，之后再分析，最好能留个快照。

系统资源不够，一般可能：

CPU使用高

若现场还在，具体分析流程：

• 在服务器执行top -Hp pid

查看进程中哪个线程CPU使用高

• 输入大写的P将线程按照 CPU 使用率排序，并把明显占用CPU的线程ID转换为16进制

• 在jstack命令输出的线程栈中搜索这个线程ID，定位出问题的线程当时的调用栈

若无法直接在服务器执行top，可采样定位：间隔固定时间运行一次jstack，采样几次后，对比采样得出哪些线程始终处于运行状态，找出问题线程。

若现场没了，可排除法分析。CPU使用高，一般是由下面的因素引起的：

• 突发压力

可通过应用之前的负载均衡的流量或日志量确认，诸如Nginx等反向代理都会记录URL，可依靠代理的Access Log进行细化定位，也可通过监控观察JVM线程数的情况。压力问题导致CPU使用高的情况下，如果程序的各资源使用没有明显不正常，之后可以通过压测+Profiler（jvisualvm就有这个功能）进一步定位热点方法；如果资源使用不正常，比如产生了几千个线程，就需要考虑调参

• GC

可通过JVM监控GC相关指标、GC Log确认。如果确认是GC压力，那么内存使用也很可能会不正常，需要按照内存问题分析流程做进步分析。

• 死循环或不正常处理流程

可以结合应用日志分析。一般情况下，应用执行过程中都会产生一些日志，可以重点关注日志量异常部分。

内存泄露或OOM

最简单的就是堆转储后使用MAT分析。堆转储，包含了堆现场全貌和线程栈信息，一般观察支配树图、直方图就可以马上看到占用大量内存的对象，可以快速定位到内存相关问题

Java进程对内存的使用不仅仅是堆区，还包括线程使用的内存（线程个数*每一个线程的线程栈）和元数据区。每一个内存区都可能产生OOM，可以结合监控观察线程数、已加载类数量等指标分析

注意看JVM参数的设置是否有明显不合理的，限制了资源。

IO问题

除非是代码问题引起的资源不释放等问题，否则通常都不是由Java进程内部因素引发的。

网络

一般也是由外部因素引起。对于连通性问题，结合异常信息通常比较容易定位；对于性能或瞬断问题，可以先尝试使用ping等工具简单判断，如果不行再使用tcpdump或Wireshark。

迷茫时的最佳实践

=======================================================================

偶尔可能分析和定位难题，会迷失自我。如果你也这样，可参考如下经验

cause or result？

---

比如业务执行的很慢，而且线程数增多，那就可能是：

• 代码逻辑有问题、依赖的外部服务慢

使得自己的业务逻辑执行缓慢，在访问量不变情况下，就需要更多线程处理。比如，10 TPS的并发原先一次请求1s即可完成，10个线程可支撑；现在执行完成需要10s，就需100个线程

• 请求量增大

使得线程数增多，应用本身CPU不足，上下文切换问题导致处理变慢

这时就需要多结合监控指标和各服务的入口流量，分析慢是cause or result。

探求规律

---

如果没头绪，那就试试总结规律吧！

读者福利

分享一份自己整理好的Java面试手册，还有一些面试题pdf

不要停下自己学习的脚步

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

一些面试题pdf

不要停下自己学习的脚步

[外链图片转存中…(img-3RI3es5T-1715147968416)]

[外链图片转存中…(img-HMs1ICOl-1715147968416)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取