《Java架构师的第一性原理》91日常经验之如何快速定位线上生产问题

  • Z时代
  • 2024-01-10
  • 分类：综合

java

1）Linux性能查看工具

1 线上问题排查，这些命令你一定用得到！

1）了解机器连接数情况

问题：1.2.3.4的sshd的监听端口是22，如何统计1.2.3.4的sshd服务各种连接状态(TIME_WAIT/ CLOSE_WAIT/ ESTABLISHED)的连接数。 常见方法：

  • netstat -n | grep 1.2.3.4:22 | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’

  • netstat -lnpta | grep ssh | egrep “TIME_WAIT | CLOSE_WAIT | ESTABLISHED”

  • n [仅限于阿里云]

 说明：netstat是追查网络连接问题常用工具，和grep/awk结合更是神器，当然如果在阿里云上，还有更方便的方法。

2）从已经备份好的日志中查询数据

问题：从已备份的suyun.2019-06-26.log.bz2日志中，找出包含关键字1.2.3.4的日志有多少条。 常见方法：

  • bzcat suyun.2019-06-26.log.bz2 | grep '1.2.3.4' | wc -l

  • bzgrep '1.2.3.4' suyun.2019-06-26.log.bz2 | wc -l

  • less suyun.2019-06-26.log.bz2 | grep '10.37.9.11' | wc -l

 说明：线上日志文件一般以bz2 压缩之后保留，如果解压查询，非常耗空间与时间，bzcat和bzgrep是研发同学必须掌握的工具。

3）备份服务的技巧

问题：打包备份/opt/web/suyun_web目录，排除掉目录中的logs和目录，打包好的文件存放在/opt/backup目录下。 

常见方法：

tar -zcvf /opt/backup/shenjian.tar.gz \
    -exclude /opt/web/suyun_web/logs \
    /opt/web/suyun_web

说明：这个命令线上应用较为频繁，在项目需要打包迁移时，常常需要排除掉日志目录，exclude是需要掌握的参数。

4）查询线程数

问题：查询服务器运行服务的总线程数，当机器线程数超报警阀值时，能快速查出相关进程及线程信息。 

参考答案：

  • ps -eLf | wc -l

  • pstree -p | wc -l

5）磁盘报警，清空最大文件

问题：找出服务器上，某个正在运行的tomcat产生的大量异常日志，找出该文件，并释放空间。不妨设该文件包含log关键字，并且大于1G。

常见方法：

第一步，找到该文件

  • find / -type f -name "*log*" | xargs ls -lSh | more 

  • du -a / | sort -rn | grep log | more

  • find / -name '*log*' -size +1000M -exec du -h {} \;

第二步，将文件清空

假设找到的文件为a.log

正确的情况方式应该为：

echo "">a.log

文件空间会立刻释放。

很多同学会使用：

rm -rf a.log

这样文件虽然删除，但是因tomcat服务仍在运行，空间不会立刻释放，需要重启tomcat才能将空间释放。

6）显示文件，过滤注释

问题：显示server.conf 文件，屏蔽掉#号开头的注释行 

常见方法：

  • sed -n '/^[#]/!p' server.conf

  • sed -e '/^#/d' server.conf

  • grep -v "^#" server.conf

7）磁盘IO异常排查

问题：磁盘IO异常如何排查，类似写入慢或当前使用率较高，请查出导致磁盘IO异常高的进程ID。

常见方法：

第一步：

iotop -o

查看当前正在写磁盘操作的所有进程ID信息。

第二步：如果此时各项写入指标都很低，基本没有大的写入操作，则需要排查磁盘自身。

可以查看系统

dmesg

或

cat /var/log/message

看看是否有相关的磁盘异常报错，同时可以在写入慢的磁盘上touch一个空文件看看，是否磁盘故障导致无法写入。

希望对经常进行线上操作的同学有帮助，如果有更好的实践，也欢迎分享。

2 关注负载和CPU

2.1 CPU负载和CPU利用率的区别是什么？

CPU利用率----显示的是程序当前正在运行期间实时占用的CPU百分比；cpu使用率反映的是当前cpu的繁忙程度，忽高忽低的原因在于占用cpu处理时间的进程可能处于io等待状态但却还未释放进入wait。

CPU负载----是指某段时间内占用cpu时间的进程和等待cpu时间的进程数，这里等待cpu时间的进程是指等待被唤醒的进程，不包括处于wait状态进程。

CPU利用率高，并不意味着CPU的负载大。无论CPU的利用率是高是低，与后面有多少任务在排队没有关系。

首先，我们可以通过uptime，w或者top命令看到CPU的平均负载。

Load Average ：负载的3个数字，比如上图的4.86，5.28，5.00，分别代表系统在过去的1分钟，5分钟，15分钟内的系统平均负载。他代表的是当前系统正在运行的和处于等待运行的进程数之和。也指的是处于可运行状态和不可中断状态的平均进程数。

如果单核CPU的话，负载达到1就代表CPU已经达到满负荷的状态了，超过1，后面的进行就需要排队等待处理了。

如果是是多核多CPU的话，假设现在服务器是2个CPU，每个CPU2个核，那么总负载不超过4都没什么问题。

怎么查看CPU有多少核呢？

通过命令cat /proc/cpuinfo | grep "model name"查看CPU的情况

cat /proc/cpuinfo | grep "model name"

通过cat /proc/cpuinfo | grep "cpu cores"查看CPU的核数

cat /proc/cpuinfo | grep "cpu cores"

CPU 利用率：和负载不同，CPU利用率指的是当前正在运行的进程实时占用CPU的百分比，他是对一段时间内CPU使用状况的统计。

我举个栗子????：

假设你们公司厕所有1个坑位，有一个人占了坑位，这时候负载就是1，如果还有一个人在排队，那么负载就是2。

如果在1个小时内，A上厕所花了10分钟，B上厕所花了20分钟，剩下30分钟厕所都没人使用，那么这一个小时内利用率就是50%。

2.2 那如果CPU负载很高，利用率却很低该怎么办？

CPU负载很高，利用率却很低，说明处于等待状态的任务很多，负载越高，代表可能很多僵死的进程。通常这种情况是IO密集型的任务，大量请求在请求相同的IO，导致任务队列堆积。

同样，可以先通过top命令观察(截图只是示意，不代表真实情况)，假设发现现在确实是高负载低使用率。

然后，再通过命令ps -axjf查看是否存在状态为D+状态的进程，这个状态指的就是不可中断的睡眠状态的进程。处于这个状态的进程无法终止，也无法自行退出，只能通过恢复其依赖的资源或者重启系统来解决。(对不起，我截不到D+的状态)

ps -axjf

2.3 那如果负载很低，利用率却很高呢？

如果你的公司只有一个厕所，外面没人排队，却有一个人在里面上了大半个小时，这说明什么？

两种可能：他没带纸，或者一些奇怪的事情发生了？

这表示CPU的任务并不多，但是任务执行的时间很长，大概率就是你写的代码本身有问题，通常是计算密集型任务，生成了大量耗时短的计算任务。

怎么排查？直接top命令找到使用率最高的任务，定位到去看看就行了。如果代码没有问题，那么过段时间CPU使用率就会下降的。

2.4 那如果CPU使用率达到100%呢？怎么排查？

如果你的公司只有一个厕所，外面没人排队，却有一个人在里面上了大半个小时，这说明什么？

1）通过top找到占用率高的进程。

2）通过top -Hp pid找到占用CPU高的线程ID。这里找到958的线程ID

3）再把线程ID转化为16进制，printf "0x%x\n" 958，得到线程ID0x3be

4）通过命令jstack 163 | grep '0x3be' -C5 --color 或者 jstack 163|vim +/0x3be - 找到有问题的代码

3 Java服务，内存OOM问题如何快速定位

某Java服务（假设PID=10765）出现了OOM，最常见的原因为：

  • 有可能是内存分配确实过小，而正常业务使用了大量内存

  • 某一个对象被频繁申请，却没有释放，内存不断泄漏，导致内存耗尽

  • 某一个资源被频繁申请，系统资源耗尽，例如：不断创建线程，不断发起网络连接

画外音：无非“本身资源不够”“申请资源太多”“资源耗尽”几个原因。
 更具体的，可以使用以下工具逐一排查。

1）确认是不是内存本身就分配过小

方法：jmap -heap 10765

如上图，可以查看新生代，老生代堆内存的分配大小以及使用情况，看是否本身分配过小。

2）找到最耗内存的对象

方法：jmap -histo:live 10765 | more

如上图，输入命令后，会以表格的形式显示存活对象的信息，并按照所占内存大小排序：

  • 实例数

  • 所占内存大小

  • 类名

是不是很直观？对于实例数较多，占用内存大小较多的实例/类，相关的代码就要针对性review了。 上图中占内存最多的对象是RingBufferLogEvent，共占用内存18M，属于正常使用范围。

如果发现某类对象占用内存很大（例如几个G），很可能是类对象创建太多，且一直未释放。例如：

  • 申请完资源后，未调用close()或dispose()释放资源

  • 消费者消费速度慢（或停止消费了），而生产者不断往队列中投递任务，导致队列中任务累积过多

画外音：线上执行该命令会强制执行一次fgc。另外还可以dump内存进行分析。

3）确认是否是资源耗尽工具：

  • pstree

  • netstat

查看进程创建的线程数，以及网络连接数，如果资源耗尽，也可能出现OOM。 

这里介绍另一种方法，通过

  • /proc/${PID}/fd

  • /proc/${PID}/task

可以分别查看句柄详情和线程数。

例如，某一台线上服务器的sshd进程PID是9339，查看

  • ll /proc/9339/fd

  • ll /proc/9339/task

 如上图，sshd共占用了四个句柄

  • 0 -> 标准输入

  • 1 -> 标准输出

  • 2 -> 标准错误输出

  • 3 -> socket（容易想到是监听端口）

 sshd只有一个主线程PID为9339，并没有多线程。

所以，只要

  • ll /proc/${PID}/fd | wc -l

  • ll /proc/${PID}/task | wc -l （效果等同pstree -p | wc -l）

就能知道进程打开的句柄数和线程数。

4 Java服务，CPU100%问题如何快速定位？

假设，服务器上部署了若干Java站点服务，以及若干Java微服务，突然收到运维的CPU异常告警。如何定位是哪个服务进程导致CPU过载，哪个线程导致CPU过载，哪段代码导致CPU过载？

简要步骤如下：

（1）找到最耗CPU的进程；

（2）找到最耗CPU的线程；

（3）查看堆栈，定位线程在干嘛，定位对应代码；

1）步骤一、找到最耗CPU的进程

工具：top方法：

  • 执行top -c ，显示进程运行信息列表

  • 键入P (大写p)，进程按照CPU使用率排序

图示：

如上图，最耗CPU的进程PID为10765。

2）步骤二：找到最耗CPU的线程

工具：top方法：

  • top -Hp 10765 ，显示一个进程的线程运行信息列表

  • 键入P (大写p)，线程按照CPU使用率排序

图示：

 如上图，进程10765内，最耗CPU的线程PID为10804。

3）步骤三：查看堆栈，定位线程在干嘛，定位对应代码

首先，将线程PID转化为16进制。

工具：printf

方法：printf "%x\n" 10804

图示：

 如上图，10804对应的16进制是0x2a34，当然，这一步可以用计算器。

 之所以要转化为16进制，是因为堆栈里，线程id是用16进制表示的。

接着，查看堆栈，找到线程在干嘛。

工具：jstack

方法：jstack 10765 | grep '0x2a34' -C5 --color

  • 打印进程堆栈

  • 通过线程id，过滤得到线程堆栈

图示：

 如上图，找到了耗CPU高的线程对应的线程名称“AsyncLogger-1”，以及看到了该线程正在执行代码的堆栈。

最后，根据堆栈里的信息，找到对应的代码，搞定！

5 哪些场景会产生OOM？怎么解决？

5.1 堆内存溢出

堆内存溢出太常见，大部分人都应该能想得到这一点，堆内存用来存储对象实例，我们只要不停的创建对象，并且保证GC Roots和对象之间有可达路径避免垃圾回收，那么在对象数量超过最大堆的大小限制后很快就能出现这个异常。

写一段代码测试一下，设置堆内存大小2M。

一般的排查方式可以通过设置

-XX: +HeapDumpOnOutOfMemoryError

在发生异常时dump出当前的内存转储快照来分析，分析可以使用Eclipse Memory Analyzer(MAT)来分析，独立文件可以在官网下载。

另外如果使用的是IDEA的话，可以使用商业版JProfiler或者开源版本的JVM-Profiler，此外IDEA2018版本之后内置了分析工具，包括Flame Graph(火焰图)和Call Tree(调用树)功能。

5.2 方法区(运行时常量池)和元空间溢出

方法区和堆一样，是线程共享的区域，包含Class文件信息、运行时常量池、常量池，运行时常量池和常量池的主要区别是具备动态性，也就是不一定非要是在Class文件中的常量池中的内容才能进入运行时常量池，运行期间也可以可以将新的常量放入池中，比如String的intern()方法。

我们写一段代码验证一下String.intern()，同时我们设置-XX:MetaspaceSize=50m -XX:MaxMetaspaceSize=50m 元空间大小。由于我使用的是1.8版本的JDK，而1.8版本之前方法区存在于永久代(PermGen)，1.8之后取消了永久代的概念，转为元空间(Metaspace)，如果是之前版本可以设置PermSize MaxPermSize永久代的大小。

5.3 直接内存溢出

直接内存并不是虚拟机运行时数据区域的一部分，并且不受堆内存的限制，但是受到机器内存大小的限制。常见的比如在NIO中可以使用native函数直接分配堆外内存就容易导致OOM的问题。

直接内存大小可以通过-XX:MaxDirectMemorySize指定，如果不指定，则默认与Java 堆最大值-Xmx一样。

由直接内存导致的内存溢出，一个明显的特征是在Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，那就可以考虑检查一下是不是这方面的原因。

5.4 栈内存溢出

栈是线程私有，它的生命周期和线程相同。每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息，方法调用的过程就是栈帧入栈和出栈的过程。

在java虚拟机规范中，对虚拟机栈定义了两种异常：

  1. 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常

  2. 如果虚拟机栈可以动态扩展，并且扩展时无法申请到足够的内存，抛出OutOfMemoryError异常

先写一段代码测试一下，设置-Xss160k，-Xss代表每个线程的栈内存大小

6 JVM调优

6.1 JVM性能监控

JDK的命令行工具

  • jps(虚拟机进程状况工具)：jps可以列出正在运行的虚拟机进程，并显示虚拟机执行主类(Main Class,main()函数所在的类)名称 以及这些进程的本地虚拟机唯一ID(Local Virtual Machine Identifier,LVMID)。

  • jstat(虚拟机统计信息监视工具)：jstat是用于监视虚拟机各种运行状态信息的命令行工 具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据。

  • jinfo(Java配置信息工具)：jinfo的作用是实时地查看和调整虚拟机各项参数。

  • jmap(Java内存映像工具)：命令用于生成堆转储快照(一般称为heapdump或dump文 件)。如果不使用jmap命令，要想获取Java堆转储快照，还有一些比较“暴力”的手段:譬如 在第2章中用过的-XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出 现之后自动生成dump文件。jmap的作用并不仅仅是为了获取dump文件，它还可以查询finalize执行队列、Java堆和永 久代的详细信息，如空间使用率、当前用的是哪种收集器等。

  • jhat(虚拟机堆转储快照分析工具)：jhat命令与jmap搭配使用，来分析jmap生成的堆 转储快照。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在 浏览器中查看。

  • jstack(Java堆栈跟踪工具)：jstack命令用于生成虚拟机当前时刻的线程快照。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈 的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循 环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。线程出现停顿 的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做些 什么事情，或者等待着什么资源。

JDK的可视化工具

  • JConsole

  • VisualVM

6.2 JVM常见参数

  1. -Xms20M：表示设置JVM启动内存的最小值为20M，必须以M为单位

  2. -Xmx20M：表示设置JVM启动内存的最大值为20M，必须以M为单位。将-Xmx和-Xms设置为一样可以避免JVM内存自动扩展。大的项目-Xmx和-Xms一般都要设置到10G、20G甚至还要高

  3. -verbose:gc：表示输出虚拟机中GC的详细情况

  4. -Xss128k：表示可以设置虚拟机栈的大小为128k

  5. -Xoss128k：表示设置本地方法栈的大小为128k。不过HotSpot并不区分虚拟机栈和本地方法栈，因此对于HotSpot来说这个参数是无效的

  6. -XX:PermSize=10M：表示JVM初始分配的永久代（方法区）的容量，必须以M为单位

  7. -XX:MaxPermSize=10M：表示JVM允许分配的永久代（方法区）的最大容量，必须以M为单位，大部分情况下这个参数默认为64M

  8. -Xnoclassgc：表示关闭JVM对类的垃圾回收

  9. -XX:+TraceClassLoading表示查看类的加载信息

  10. -XX:+TraceClassUnLoading：表示查看类的卸载信息

  11. -XX:NewRatio=4：表示设置年轻代（包括Eden和两个Survivor区）/老年代 的大小比值为1：4，这意味着年轻代占整个堆的1/5

  12. -XX:SurvivorRatio=8：表示设置2个Survivor区：1个Eden区的大小比值为2:8，这意味着Survivor区占整个年轻代的1/5，这个参数默认为8

  13. -Xmn20M：表示设置年轻代的大小为20M

  14. -XX:+HeapDumpOnOutOfMemoryError：表示可以让虚拟机在出现内存溢出异常时Dump出当前的堆内存转储快照

  15. -XX:+UseG1GC：表示让JVM使用G1垃圾收集器

  16. -XX:+PrintGCDetails：表示在控制台上打印出GC具体细节

  17. -XX:+PrintGC：表示在控制台上打印出GC信息

  18. -XX:PretenureSizeThreshold=3145728：表示对象大于3145728（3M）时直接进入老年代分配，这里只能以字节作为单位

  19. -XX:MaxTenuringThreshold=1：表示对象年龄大于1，自动进入老年代,如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象在年轻代的存活时间，增加在年轻代被回收的概率。

  20. -XX:CompileThreshold=1000：表示一个方法被调用1000次之后，会被认为是热点代码，并触发即时编译

  21. -XX:+PrintHeapAtGC：表示可以看到每次GC前后堆内存布局

  22. -XX:+PrintTLAB：表示可以看到TLAB的使用情况

  23. -XX:+UseSpining：开启自旋锁

  24. -XX:PreBlockSpin：更改自旋锁的自旋次数，使用这个参数必须先开启自旋锁

  25. -XX:+UseSerialGC：表示使用jvm的串行垃圾回收机制，该机制适用于单核cpu的环境下

  26. -XX:+UseParallelGC：表示使用jvm的并行垃圾回收机制，该机制适合用于多cpu机制，同时对响应时间无强硬要求的环境下，使用-XX:ParallelGCThreads=设置并行垃圾回收的线程数，此值可以设置与机器处理器数量相等。

  27. -XX:+UseParallelOldGC：表示年老代使用并行的垃圾回收机制

  28. -XX:+UseConcMarkSweepGC：表示使用并发模式的垃圾回收机制，该模式适用于对响应时间要求高，具有多cpu的环境下

  29. -XX:MaxGCPauseMillis=100：设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。

  30. -XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低响应时间或者收集频率等，此值建议使用并行收集器时，一直打开

6.3 JVM调优目标-何时需要做jvm调优

  1. heap 内存（老年代）持续上涨达到设置的最大内存值；

  2. Full GC 次数频繁；

  3. GC 停顿时间过长（超过1秒）；

  4. 应用出现OutOfMemory 等内存异常；

  5. 应用中有使用本地缓存且占用大量内存空间；

  6. 系统吞吐量与响应性能不高或下降。

6.4 JVM调优实战

  • Major GC和Minor GC频繁

    首先优化Minor GC频繁问题。通常情况下，由于新生代空间较小，Eden区很快被填满，就会导致频繁Minor GC，因此可以通过增大新生代空间来降低Minor GC的频率。例如在相同的内存分配率的前提下，新生代中的Eden区增加一倍，Minor GC的次数就会减少一半。

    扩容Eden区虽然可以减少Minor GC的次数，但会增加单次Minor GC时间么？扩容后，Minor GC时增加了T1（扫描时间），但省去T2（复制对象）的时间，更重要的是对于虚拟机来说，复制对象的成本要远高于扫描成本，所以，单次Minor GC时间更多取决于GC后存活对象的数量，而非Eden区的大小。因此如果堆中短期对象很多，那么扩容新生代，单次Minor GC时间不会显著增加。

  • 请求高峰期发生GC，导致服务可用性下降

    由于跨代引用的存在，CMS在Remark阶段必须扫描整个堆，同时为了避免扫描时新生代有很多对象，增加了可中断的预清理阶段用来等待Minor GC的发生。只是该阶段有时间限制，如果超时等不到Minor GC，Remark时新生代仍然有很多对象，我们的调优策略是，通过参数强制Remark前进行一次Minor GC，从而降低Remark阶段的时间。 另外，类似的JVM是如何避免Minor GC时扫描全堆的？ 经过统计信息显示，老年代持有新生代对象引用的情况不足1%，根据这一特性JVM引入了卡表（card table）来实现这一目的。卡表的具体策略是将老年代的空间分成大小为512B的若干张卡（card）。卡表本身是单字节数组，数组中的每个元素对应着一张卡，当发生老年代引用新生代时，虚拟机将该卡对应的卡表元素设置为适当的值。如上图所示，卡表3被标记为脏（卡表还有另外的作用，标识并发标记阶段哪些块被修改过），之后Minor GC时通过扫描卡表就可以很快的识别哪些卡中存在老年代指向新生代的引用。这样虚拟机通过空间换时间的方式，避免了全堆扫描。

  • STW过长的GC

    对于性能要求很高的服务，建议将MaxPermSize和MinPermSize设置成一致（JDK8开始，Perm区完全消失，转而使用元空间。而元空间是直接存在内存中，不在JVM中），Xms和Xmx也设置为相同，这样可以减少内存自动扩容和收缩带来的性能损失。虚拟机启动的时候就会把参数中所设定的内存全部化为私有，即使扩容前有一部分内存不会被用户代码用到，这部分内存在虚拟机中被标识为虚拟内存，也不会交给其他进程使用。

  • 外部命令导致系统缓慢

    一个数字校园应用系统，发现请求响应时间比较慢，通过操作系统的mpstat工具发现CPU使用率很高，并且系统占用绝大多数的CPU资 源的程序并不是应用系统本身。每个用户请求的处理都需要执行一个外部shell脚本来获得系统的一些信息，执行这个shell脚本是通过Java的 Runtime.getRuntime().exec()方法来调用的。这种调用方式可以达到目的，但是它在Java 虚拟机中是非常消耗资源的操作，即使外部命令本身能很快执行完毕，频繁调用时创建进程 的开销也非常可观。Java虚拟机执行这个命令的过程是:首先克隆一个和当前虚拟机拥有一样环境变量的进程，再用这个新的进程去执行外部命令，最后再退出这个进程。如果频繁执行这个操作，系统的消耗会很大，不仅是CPU，内存负担也很重。用户根据建议去掉这个Shell脚本执行的语句，改为使用Java的API去获取这些信息后，系统很快恢复了正常。

  • 由Windows虚拟内存导致的长时间停顿

    一个带心跳检测功能的GUI桌面程序，每15秒会发送一次心跳检测信号，如果对方30秒以内都没有信号返回，那就认为和对方程序的连接已经断开。程序上线后发现心跳 检测有误报的概率，查询日志发现误报的原因是程序会偶尔出现间隔约一分钟左右的时间完 全无日志输出，处于停顿状态。

    因为是桌面程序，所需的内存并不大(-Xmx256m)，所以开始并没有想到是GC导致的 程序停顿，但是加入参数-XX:+PrintGCApplicationStoppedTime-XX:+PrintGCDateStamps- Xloggc:gclog.log后，从GC日志文件中确认了停顿确实是由GC导致的，大部分GC时间都控 制在100毫秒以内，但偶尔就会出现一次接近1分钟的GC。

    从GC日志中找到长时间停顿的具体日志信息(添加了-XX:+PrintReferenceGC参数)， 找到的日志片段如下所示。从日志中可以看出，真正执行GC动作的时间不是很长，但从准 备开始GC，到真正开始GC之间所消耗的时间却占了绝大部分。

    除GC日志之外，还观察到这个GUI程序内存变化的一个特点，当它最小化的时候，资源 管理中显示的占用内存大幅度减小，但是虚拟内存则没有变化，因此怀疑程序在最小化时它的工作内存被自动交换到磁盘的页面文件之中了，这样发生GC时就有可能因为恢复页面文件的操作而导致不正常的GC停顿。在Java的GUI程序中要避免这种现象，可以 加入参数“-Dsun.awt.keepWorkingSetOnMinimize=true”来解决。 

7 生产环境JVM参数设置

7.1 某公司使用CMS收集器的配置

7.2 某公司使用G1收集器的配置

QTT

java -server -Xmx4096M -Xms1024M -XX:MaxMetaspaceSize=512M -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/logs/dump -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/data/logs/gc.log -XX:+UseGCLogFileRotation -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Djava.security.egd=file:/dev/./urandom -jar app.jar --spring.profiles.active=prod --server.port=12000

SL

-XX:+UseG1GC -Xms1g -Xmx1g -Djava.security.egd=file:/dev/./urandom -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/logs/heapdump.hprof -XX:-OmitStackTraceInFastThrow -Duser.timezone=Asia/Shanghai -XX:MaxDirectMemorySize=1026m -XX:+UseGCLogFileRotation -XX:SurvivorRatio=8 -Xloggc:/opt/logs/gc.log -XX:NumberOfGCLogFiles=1 -Xdebug -Xrunjdwp:transport=dt_socket,address=12346,server=y,suspend=n

99 直接读这些牛人的原文

面试官：哪些场景会产生OOM？怎么解决？

阿里技术：线上故障如何快速排查？来看这套技巧大全

阿里技术：CPU飙高，系统性能问题如何排查？

线上FullGC频繁问题的排查过程及解决方案

以上是 《Java架构师的第一性原理》91日常经验之如何快速定位线上生产问题 的全部内容， 来源链接： utcz.com/z/393685.html

回到顶部