Java常见线上问题

于 2024-07-16 14:52:58 发布
阅读量2k 收藏 28
点赞数 31
文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43848975/article/details/140463653
版权

Java常见线上问题

线上的 API 接口响应比较慢，该如何快速排查和定位问题？

1.1 定位问题

  1. 查看是否是sql性能瓶颈，我们需要开启 mysql 的慢查询日志。把超过指定时间的 sql 语句，单独记录下来，方面以后分析和定位问题。

开启慢查询日志需要重点关注三个参数：

  • slow_query_log慢查询开关
  • slow_query_log_file慢查询日志存放地址
  • long_query_time超过多少秒才会记录日志
 # 通过 mysql 的 set 命令可以设置：
 set global slow_query_log='ON';
 set global slow_query_log_file='/usr/local/mysql/data/slow.log';
 set global long_query_time=2;

设置完之后，如果某条 sql 的执行时间超过了 2 秒，会被自动记录到slow.log文件中。当然也可以直接修改配置文件 my.cnf

[mysqld]
slow_query_log = ON
slow_query_log_file = /usr/local/mysql/data/slow.log
long_query_time = 2

但这种方式需要重启 mysql 服务

1.2 监控

常见开源监控系统是Prometheus，它提供了 监控 和 预警 的功能。
我们可以用它监控如下信息：

  • 接口响应时间
  • 调用第三方服务耗时
  • 慢查询 sql 耗时
  • cpu 使用情况
  • 内存使用情况
  • 磁盘使用情况
  • 数据库使用情况

1.3 链路追踪

有时候某个接口涉及的逻辑很多，比如：查数据库、查 redis、远程调用接口，发mq消息，执行业务代码等等。
该接口一次请求的链路很长，如果逐一排查，需要花费大量的时间，这时候，我们已经没法用传统的办法定位问题了。
用分布式链路跟踪系统：skywalking
在 skywalking 中可以通过 traceId（全局唯一的 id），串联一个接口请求的完整链路。可以看到整个接口的耗时，调用的远程服务的耗时，访问数据库或者redis 的耗时等等，功能非常强大。
之前没有这个功能的时候，为了定位线上接口性能问题，我们还需要在代码中加日志，手动打印出链路中各个环节的耗时情况，然后再逐一排查。

1.4 死锁问题

使用Arthas中的thread -b命令，找出当前阻塞其他线程的线程，就是造成死锁的线程

[arthas@11596]$ thread -b
"t1" Id=10 BLOCKED on java.lang.Object@26dee7d7 owned by "t2" Id=11
    at test.Deadlock.lambda$main$0(Deadlock.java:24)
    -  blocked on java.lang.Object@26dee7d7
    -  locked java.lang.Object@13a631ce <---- but blocks 1 other threads!
    at test.Deadlock$$Lambda$1/250421012.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:748)

其他相关命令

thread –all, 显示所有的线程；
thread id, 显示指定线程的运行堆栈；
thread –state：查看指定状态的线程，如：thread –state BLOCKED；
thread -n 3：展示当前最忙的前N个线程并打印堆栈；

线上CPU占用过高

可能导致 CPU 使用率飙升的操作

  • 无限循环的 while
  • 经常使用 Young GC
  • 频繁的 GC
  • 序列化和反序列化
  • 正则表达式
  • 线程上下文切换

如何排查

  1. 定位进程，使用top查看资源占用高的进程，获取到PID号，假设：18893
  2. 通过进程找到对应的线程，使用top -Hp 18893获取到线程号，假设：4519
  3. 通过线程定位到代码大概位置信息
    • 通过printf %x 4519，获取16进制线程号，结果为11a7
    • 通过jstack 18893 | grep 11a7 -A 30 -color获取到堆栈信息，拿到代码大致位置
  4. 通过Arthas中的thread -n 3查看cpu占比前三的线程

线上内存占用过高

如何排查

  1. 定位进程，输入top命令后按下M（按照内存占用由大到小排序）假设定位到进程ID是14279
  2. 找到对应线程top -Hp 14279，同样按下M（按内存占用由大到小排序）
    在这里插入图片描述
  3. 需要观察左上角的线程数量，现在的线程数量是54，属于正常，如果较大的话比如大于1000时，就需要考虑是不是代码有问题导致起了多个线程或者是是不是自己的线程池创建的最大个数太大了。
  4. 如果线程数量正常则找到占内存大的线程的PID，比如按下M后的第一个线程(这里没有模拟内存占用，只展示命令)，此时需要使用dump内存的快照信息来查看

如果是线上环境，dump之前需要保证没有流量使用，否则较大内存的dump是直接卡死服务

  1. 使用jmap -dump:format=b,file=dump.hprof 19796来获取快照
  2. 使用工具查看业务相关实例，然后找到对应代码查看（比如：MAT、MAT、VisualVM、jhat）

线上磁盘问题

  1. 检查磁盘占用情况，使用df -h或du命令查看
  2. TPS是否正常，使用iostat、vmstat、lsof
    • iostat用来报告CPU使用情况和磁盘I/O统计信息
    • vmstat报告虚拟内存统计信息
    • lsof命令用于列出打开文件
  3. 通过这些命令，获取评估磁盘I/O统计信息中的TPS（每秒传输的I/O操作数），如果过高或者过低，意味着磁盘存在问题

线上GC问题导致程序卡顿

不管 Minor GC 还是 FGC，都会造成一定程度的程序卡顿（即Stop The World：GC线程开始工作，其他工作线程被挂起），即使采用 ParNew、CMS 或者G1 这些更先进的垃圾回收算法，也只是在减少卡顿时间，而并不能完全消除卡顿。

  1. FGC 过于频繁，FGC 通常比较慢，少则几百毫秒，多则几秒，正常情况FGC 每隔几个小时甚至几天才执行一次，对系统的影响还能接受。

一旦出现 FGC 频繁（比如几十分钟执行一次），是存在问题的，会导致工作线程频繁被停止，让系统看起来一直有卡顿现象，也会使得程序的整体性能变差。

  1. YGC 耗时过长，一般来说，YGC 的总耗时在几十或者上百毫秒是比较正常的，虽然会引起系统卡顿几毫秒或者几十毫秒，这种情况几乎对用户无感知，对程序的影响可以忽略不计。

如果 YGC 耗时达到了 1 秒甚至几秒（都快赶上 FGC 的耗时了），那卡顿时间就会增大，加上 YGC 本身比较频繁，就会导致比较多的服务超时问题。

  1. FGC 耗时过长，FGC 耗时增加，卡顿时间也会随之增加，尤其对于高并发服务，可能导致FGC期间比较多的超时问题，可用性降低，这种也需要关注
  2. YGC 过于频繁，即使 YGC 不会引起服务超时，但是 YGC 过于频繁也会降低服务的整体性能，对于高并发服务也是需要关注的。

如何排查

  1. JDK 自带工具：jmap、jstat
  2. 查看堆内存各区域的使用率以及 GC 情况：jstat -gcutil 进程pid 1000 （重点关注结果中的 YGC、YGCT、FGC、FGCT、GCT）
  3. 查看堆内存中的存活对象，并按空间排序：jmap -histo 进程pid | head -n20
  4. dump 堆内存文件：jmap -dump:format=b,file=heap 进程pid

线上JVM频率出现FullGC如何排查解决

触发FullGC的条件

  1. 程序执行了 System.gc() //建议 jvm 执行 fullgc，并不一定会执行
  2. 执行了jmap -histo:live pid 命令 //这个会立即触发 fullgc
  3. 在执行 minor gc 的时候进行的一系列检查

在执行MinorGC的时候，JVM会检查老年代中最大连续可用空间是否大于了当前新生代所有对象的总大小，
如果大于直接执行MinorGC，
如果小于了，JVM 会检查是否开启了空间分配担保机制，如果没有开启则直接改为执行 Full GC。
如果开启了，则 JVM 会检查老年代中最大连续可用空间是否大于了历次晋升到老年代中的平均大小，
如果小于则执行改为执行 Full GC。
如果大于则会执行 Minor GC，如果 Minor GC 执行失败则会执行Full GC

  1. 使用了大对象 //大对象会直接进入老年代

调整JVM参数

通常的处理，我们还是要在FULLGC时取到当时的dump文件，来分析内存里都有哪些数据占居着内存。这里有两种办法来获取dump文件：

  • 通过在jvm里添加参数配置：+HeapDumpBeforeFullGC，+HeapDumpAfterFullGC 这种方法需要在应用启动前要提前配置好，如果不需要的话，还需要修改jvm参数重启应用
  • 使用jinfo命令进行设置。（生产环境常用的方法）
    1. 获取java的进程id
    2. 调用jinfo设置JVM参数，jinfo -flag +HeapDumpBeforeFullGC 进程pid和jinfo -flag +HeapDumpAfterFullGC 进程pid，使用jinfo -flags 进程pid查看是否生效
    3. 下次发送FullGC的时候就会生成dump文件

线上JVM出现OOM问题如何排查

OutOfMemoryError属于java中常见的内存问题，oom 出现的原因就是内存不够用了，GC 虽然在回收，然后回收的速度赶不上新对象分配了或者根本就没有对象可以被回收，就会抛出OutOfMemoryError 错误，

常见的五种OOM错误：

  • java.lang.OutOfMemoryError: Java heap space
  • java.lang.OutOfMemoryError: unable to create new native thread
  • java.lang.OutOfMemoryError: Metaspace
  • java.lang.OutOfMemoryError: Direct buffer memory
  • java.lang.OutOfMemoryError: GC overhead limit exceeded

如何发现OOM错误

  1. 日志监控，通过监控日志中关键字 java.lang.OutOfMemoryError，就可以知道应用是否出现oom.对于文件的监控，可以使用 filebeat 或者 flume 等采集
  2. JVM参数配置-XX:+ExitOnOutOfMemoryError，当 jvm 启用该参数时，如果出现了 oom，就会自动退出程序，咱们的健康检测自然能发现应用不存在了，从而能发出告警
  3. 使用 jstat 监控 jvm 内存使用率，通过 jstat 工具可以查看 jvm 的内存使用情况，如果老年代使用率一直是100%，并且期间还在一直不断 GC，这也是发生了 oom 的一种现象，jstat -gcutil $pid 1000使用该命令即可实现每秒打印一次 jvm的内存信息。O列代表老年代内存使用比例，YGC和FGC分别代表新生代GC和老年代GC次数在这里插入图片描述

如何保证OOM出现时服务可用

当应用出现 oom 时，意味着应用无法申请到内存来分配对象，那么咱们的业务代码就会处于混沌状态，不清楚能进行到哪一步，不清楚状态是否完备，业务的请求可能在系统无限阻塞。这种情况对于用户体验的伤害会非常大。
所以这里有一个简单的方法就是，配置-XX:+HeapDumpOnOutOfMemoryError 参数，当应用发生 oom 后，自动关停，借助 k8s 的健康检测实现自动重启能力再次拉起来新的容器。注意，这里需要实现业务系统能够实现故障转移或者请求幂等。这样才能保证用户请求不会出问题。

OOM的解决方案

对于 unable to create new native thread 、Metaspace、Direct buffer memory和 GC overhead limit exceeded它们的原因相对简单，可以直接给出结论。

  • unable to create new native thread : 无法创建更多的操作系统线程
    • 说明当前系统的线程数过多，超过了系统线程数的上限，减少当前应用创建的线程即可。
    • 没有 native 内存了
  • Metaspace（存储类元数据的内存）
    • 说明 Metaspace 不够用，修改 -XX:MaxMetaspaceSize 启动参数，调大永久代空间即可。
  • Direct buffer memory（直接缓存区）它允许应用程序直接在堆外内存中分配数据
    • Direct ByteBuffer 的默认大小为 64 MB，一旦使用超出限制，就会抛出Directbuffer memory 错误。
  • GC overhead limit exceeded
    • 当 jvm 98%的时间都在 GC 时，就会出现该异常。这种情况需要增大堆或者结合下面的方法继续排查

当应用发生 oom 后，最佳的分析载体就是 heap dump。通过添加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/app.dump参数，可以实现发送OOM时自动导出heap dump，有了 heap dump，我们就可以借助 Eclipse MAT 这款工具来分析heap
dump 了

如何规避OOM

oom 发生的原因有两种:

  1. 应用正常，但是堆设置过小，无法支持正常的对象分配
    • 增大堆内存
    • 优化应用内存使用效率
  2. 应用发生了内存泄漏，导致应该被清理的对象没有清理，无限增长通过分析 heap dump，我们基本可以区分出两种情况，第一种情况，对象的分布都正确，没有那种以下占用 30%*-，甚至 50%的对象。第二种情况就是某一种类型的对象，占据了大量的内存空间。
    • 需要针对性分析，这里给出几个常见原因
    • ThreadLocal 未清理
    • 出现了未指定分页的大数据量查询
    • 定时任务中 list 忘记清空，每次都追加数据
    • 监控系统中使用了不可控的字段作为 label,导致 label 无限增长
gezi2023
关注
Java 应用线上问题排查思路、常用工具小结
uuuyy_的博客
12-17 563
前言 本文总结了一些常见的线上应急现象和对应排查步骤和工具。分享的主要目的是想让对线上问题接触少的同学有个预先认知，免得在遇到实际问题时手忙脚乱。毕竟作者自己也是从手忙脚乱时走过来的。 只不过这里先提示一下。在线上应急过程中要记住，只有一个总体目标：尽快恢复服务，消除影响。 不管处于应急的哪个阶段，我们首先必须想到的是恢复问题，恢复问题不一定能够定位问题，也不一定有完美的解决方案，也许是通过经验判断，也许是预设开关等，但都可能让我们达到快速恢复的目的，然后保留部分现场，再去定位问题、解决问题和复...
Java服务线上问题排查思路
土豆爱吃薯片的博客
08-20 327
前言 Java 语言是当前互联网应用最为广泛的语言，作为一名程序猿掌握 Java 服务线上问题排查思路并能够熟练排查问题常用工具/命令/平台是每一个 Java 程序猿进阶必须掌握的实战技能。 常见问题 总的来说线上问题可以分为两大类：系统异常、业务异常。系统异常不外乎，CPU、内存、磁盘、网络四个方面，例如常见问题CPU使用率峰值突然飙高、内存溢出、磁盘满了、网络流量异常、带宽满了等。 一般我们采用排除法、解决问题。当系统业务异常、首先我们想到的是查看业务日志。 问题定位 查看业务日志 常用的查看日志命令
java线上常见问题_java线上问题排查总结
weixin_35965498的博客
03-04 405
Linux命令类tailtail -999f fixed-center.log #倒数999行并进入实时监听文件写入模式grepgrep forest f.txt #文件查找grep forest f.txt cpf.txt #多文件查找grep 'log' /home/admin -r -n #目录下查找所有符合关键字的文件cat f.txt | grep -i shopbase #匹...
Java线上问题 | 大Json引发的血案
独行侠梦的博客
03-15 168
java线上问题分析大JSON引发的“血案”Java线上问题之日志打好与JVM参数配好这里想说的是打印日志的重要性，它在你定位问题时起到至关重要的作用。分析过程一、描述产生的问题服务无法...
java应用线上问题排查思路
迷途的小兵
07-18 739
java应用线上一般会出现什么问题？如何通过分类分析快速定位问题，避免事故蔓延呢。
Java应用线上问题排查思路
程序员博客
08-09 2297
一、前言 本文总结了一些Java应用线上常见问题的定位步骤，分享的主要目的是想让对线上问题接触少的同学有个预先认知，免得在遇到实际问题时手忙脚乱。毕竟作者自己也是从手忙脚乱时走过来的。 只不过这里先提示一下。在线上应急过程中要记住，只有一个总体目标：【尽快恢复服务，消除影响】。不管处于应急的哪个阶段，我们首先必须想到的是恢复问题，恢复问题不一定能够定位问题，也不一定有完美的解决方案，也许是通过经验判断，也许是预设开关等，但都可能让我们达到快速恢复的目的，然后保留部分现场，再去定位问题、解决问题和复盘。
Java常见线上故障排查方案
串一串爪娃子
02-02 396
文章目录一、前言二、Java常见线上问题总结三、如何定位问题3.1、业务日志分析排查3.2、APM分析排查3.3、物理环境排查3.3.1 CPU分析3.3.2 内存分析3.3.3 磁盘分析3.3.4 网络分析3.4、应用服务排查3.4.1 CPU分析3.4.2 内存分析3.5、云厂商或运营商问题排查四、常用Linux分析命令4.1 CPU4.2 内存4.3 磁盘4.4 网络五、Arthas诊断命令5.1 下载安装5.2 启动Arthas5.3 开始诊断5.4 查看dashboard5.5 arthas常见命
java线上容易出问题的点_Java线上故障排查，纯干货建议收藏哦
weixin_39609166的博客
02-27 216
线上故障主要会包括 CPU、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如 jstack、jmap 等工具也是不囿于一个方面的问题的，基本上出问题就是 df、free、top 三连，然后依次 jstack、jmap 伺候，具体问题具体分析即可。CPU一般来讲我们首先会排查 CPU 方面的问题。CPU 异常往往还是比较好定位的。原...
Java线上问题排查思路处理流程及定位工具
初心不改
08-22 3432
Java 语言是当前互联网应用最为广泛的语言，作为一名 Java 程序猿，当业务相对比较稳定之后平常工作除了 coding 之外，大部分时间（70%~80%）是会用来排查突发或者周期性的线上问题。由于业务应用 bug(本身或引入第三方库)、环境原因、硬件问题等原因，Java 线上服务出现故障 / 问题几乎不可避免。例如，常见的现象包括部分请求超时、用户明显感受到系统发生卡顿等等。尽快线上问题从系统表象来看非常明显，但排查深究其发生的原因还是比较困难的，因此对开发测试或者是运维的同学产生了许多的困扰。
Java进阶（四） 线上问题定位
qq_14828239的博客
06-05 692
备注：此文章参考《Java并发编程的艺术》 有很多问题在开发环境下并不会出现，在生产环境下才会出现，而在生产环境下又不能调试代码，只能根据线上日志，系统状态，dump线程来定位问题 一.查看每一个进程的状态 使用命令：top user：表示当前登录该机器的用户数 load average：一分钟负载，五分钟负载，十分钟负载（每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数
Java线上故障解决方案
浪人与酒
02-05 3749
一、前言： 我们在⽣产环境中，程序代码、硬件、⽹络、协作软件等任⼀因素，都会引发意想不到的问题，所以排查产线问题⽐较困难，所以问题的定位体现了⼀名⼯程师的基础能⼒，问题的解决则体现了⼯程师的技能素养。 二、线上常见问题 如出现 （CPU占⽤率过⾼、磁盘使⽤率100%、系统可⽤内存低、服务间调⽤时间过⻓、多线程并发异常、死锁等） 三、定位问题 方案 ： 业务⽇志分析排查 通常情况下，⼤部分错误信息都会在⽇志上有所体现 public class Test { public static v.
java线上问题排查基本命令
小安灬的博客
06-20 1880
java命令启动java应用程序。它通过启动Java运行时环境（JRE）、加载指定的类并调用该类的main（）方法来实现这一点。javap是 Java class文件分解器，可以反编译，也可以查看java编译器生成的字节码。用于分解class文件。javac 是java语言编程编译器。全称java compiler。javac工具读由java语言编写的类和接口的定义，并将它们编译成字节代码的class文件。javac 可以隐式编译一些没有在命令行中提及的源文件。用 -verbose 选项可跟踪自动编译。
Java应用线上问题排查的常用工具和方法
lipc_的博客
10-04 1905
在长期排查线上问题的过程中，总结了一些工具的用法和排查问题的思路，这里跟大家分享一下，在遇到类似的问题时，希望能给予一些帮助。 　　首先讲讲工具， jvm 自带的一些工具是必须熟练掌握的，例如jstack, jmap, jstat等，它们可以帮我们去深入了解JVM正在做的事情，主要的适用领域有这些： 1、jstack 　　jstack可以告诉你当前所有JVM线程正在做什么，包括用
一次线上问题排查所引发的思考
纯洁的微笑
07-17 1453
前言之前或多或少分享过一些内存模型、对象创建之类的内容，其实大部分人看完都是懵懵懂懂，也不知道这些的实际意义。直到有一天你会碰到线上奇奇怪怪的问题，如：线程执行一个任务迟...
eclipse内存分析工具MAT浅谈（一）
easyer2012的专栏
09-14 665
MAT(Memory Analyzer Tool) 是基于heap dumps来进行分析的，所以首先必须通过一定的手段得到JAVA堆的DUMP文件。JDK自带的。JConsole 或者 JMAP都是不错的工具。  准备  （·）下载eclipse3.7  （·）安装MAT插件：http://download.eclipse.org/mat/1.1/update-site/  安装完
一文搞懂：Java项目线上故障处理的基本方法
最新发布
景川的博客
04-02 1088
Java项目的调优和故障处理相关内容记录
JAVA线上问题排查与系统优化技巧
这篇文章提供的是一套实用的Java线上问题排查流程，包括监控系统资源、识别性能瓶颈、定位问题进程以及深入分析线程堆栈。这些技能对于任何Java开发人员来说都是至关重要的，能帮助他们在面对线上问题时迅速找到解决...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值