文章目录
- 一、gc日志和dump快照
- GC日志是什么,要怎么看?
- dump快照是什么?要怎么看?
- 二、gc日志和dump快照实战
- java.lang.OutOfMemoryError:Java heap space
- 1、gc.log怎么看
- 2、heapdump.hprof怎么看?
- ①jvisualvm查看
- ②使用MAT查看
- java.lang.OutOfMemoryError:Metaspace
- 1、实时分析—jstat
- 2、实时分析—jvisualvm
- 3、离线分析—gc.log
- 4、离线分析—dump快照
- java.lang.OutOfMemoryError:GC overhead limit
- java.lang. stackoverflowError
- 三、java命令行工具
- jps
- jstat
- jstat -gc 10376 1000 10
- jstat -gcutil 6384 1000 30
- -t参数分析垃圾回收的时间占比
- jstat还可以用来判断是否出现内存泄漏。
- jinfo
- jinfo -flags xxx
- jmap
- jmap -dump 导出堆内存日志
- jmap -heap xxx 显示堆内存信息
- jmap histo xxx 显示
- jhat
- jstack
- jstack pid 线程诊断
- jcmd
- 四、面试必问(异常类)
- 内存泄露和内存溢出的关系?
- 内存泄露的几种情况
- JVMOOM问题如何排查和解决?
- java.lang.OutOfMemoryError: Java heap space堆内存溢出问题如何排查和解决?
- 如果JVM出现频繁FullGC该如何解决
- 我实际遇到的内存泄露:
- 线上OOM、CPU预警、内存预警问题排查的步骤?(宏观谈)
- OOM、CPU预警、内存预警之类的问题具体排查步骤:
- 第一步:查看硬件的资源
- 第二步、使用实时分析工具
- 第三步,离线分析
- 线上的 API 接口响应比较慢,该如何快速排查和定位问题?
- 线程诊断_CPU占用过高
- 线程诊断_迟迟得不到结果
- MySQL 数据库cpu 飙升的话,要怎么处理呢?
- 数据库出现死锁如何排查?
- 五、面试必学(调优类)
- GC 调优
- 如何进行GC调优?
- 1. 新生代调优
- 2. 幸存区调优
- 3. 老年代调优
- GC调优的案例
- 六、JVM性能优化案例
- 案例1:调整堆大小提高服务的吞吐量
- 案例2:如何调整堆内存?/ 生产环境该给服务器分配多少内存?
- 案例3:调整垃圾回收器,提高服务吞吐量
- 案例4:服务器升级后为什么卡顿十分严重?
一、gc日志和dump快照
当服务发生堆内存溢出时,你可以从系统里面拿到两类日志:一个是gc日志,另一个是dump快照
gc日志可以直接看(不推荐),但是直接看晦涩难懂,建议用GCEasy去分析
dump快照是二进制文件,你想直接看也看不懂,所以你需要借助JvisualVm、MAT、Jprofile等专业工具分析
上面都是离线分析。
我们可以用JvisualVm、MAT、Jprofile连上我们的idea进行实时监控堆内存然后实时分析,但是这个在生产环境中不适用;
生产环境发生堆内存溢出时我们拿到gc日志和dump快照然后进行离线分析;
也就是说,对于dump快照和gc日志而言,我们生产环境主打的就是离线分析。
jinfo、jstat、jmap这些命令行工具有啥用?我们能用JvisualVm、MAT、Jprofile去图像分析,那为啥要学这些命令行?
JvisualVm、MAT、Jprofile是分析dump快照的,但是我如果想知道①生产环境堆内存大小是多少?②生产环境老年代使用了多少了?是否快发生堆内存溢出了?③生产环境出现死锁了④生产环境cpu过高 等等问题,你是只能用命令行去解决的
GC日志是什么,要怎么看?
添加如下的启动参数-XX:+PrintGCDetails -XX:+PrintGCDataStamps -XLoggc:./logs/gc.log
-XX:+PrintGCDetails 在发生垃圾回收时打印内存回收详细的日志,并在进程退出时输出当前内存各区域分配的情况
-XX:+PrintGCDataStamps GC发生时输出时间戳
-XLoggc:./logs/gc.log 把GC日志写入到一个文件里面去
上面的gc.log可以到GcEasy官网去分析
Minor GC日志该怎么看?(了解)
以下内容来自别的视频
Full GC日志该怎么看?(了解)
以下内容来自别的视频
Full GC由于包括了新生代、老年代、元空间等,所以它的日志很长
dump快照是什么?要怎么看?
dump快照是二进制文件,你想直接看也看不懂,所以你需要借助JvisualVm、MAT、Jprofile等专业工具分析
Jconsole
略,这个工具不如JvisualVm、MAT、Jprofile
JvisualVM
JvisualVM怎么分析我们后面慢慢讲,我们先说一下它怎么安装插件
MAT
MAT可以分析heap dump文件。在进行内存分析时,只要获得了反映当前设备内存映像的hprof文件,通过MAT打开就可以直观地看到当前的内存信息。
面试问答:MAT里面能看到哪些内存信息?
- 所有的对象信息,包括对象实例、成员变量、存储于栈中的基本类型值和存储于堆中的其他对象的
引用值。 - 所有的类信息,包括classloader、类名称、父类、静态变量等.
- GCRoot到所有的这些对象的引用路径
- 线程信息,包括线程的调用栈及此线程的线程局部变量(TLS)
Jprofile
Jprofile是收费的,所以Jprofile更强大,它支持实时分析正在运行的程序,也支持离线对dump文件的分析
这个工具就先不介绍了,老师课程里面都是实时分析,但是我们真实生产环境要的是离线分析,而且JvisualVm、MAT使用的更多一些
其它工具
还有JMC、Flame Graphs 、Tprofiler 、 Btrace 、YouKit、JProbe、Spring Insight等工具
二、gc日志和dump快照实战
对于gc日志和dump快照怎么看,我们必须依赖案例来去了解JvisualVm、MAT、GCEasy这些工具的使用,离开案例都是耍流氓。
java.lang.OutOfMemoryError:Java heap space
jvm参数配置:
-Xms50M -Xmx50M -XX:MetaspaceSize=64M
-XX:+PrintGCDetails -XX:+PrintGCDataStamps -XLoggc:./logs/gc.log
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=heap/heapdump.hprof-Xms50M -Xmx50M 这两个参数保证你的堆内存足够小能够发生堆内存溢出
-XX:+PrintGCDetails 在发生垃圾回收时打印内存回收详细的日志,并在进程退出时输出当前内存各区域分配的情况
-XX:+PrintGCDataStamps GC发生时输出时间戳
-XLoggc:./logs/gc.log 把GC日志写入到一个文件里面去,方便后面分析
-XX:+HeapDumpOnOutOfMemoryError 保证当服务器出现堆内存溢出时能够把当前的堆使用情况记录下来(这个很关键,你要是没有这个参数就不会记录当时的堆内存情况。这就好比是一个人被杀了,临死之前拍了一段录像一样。)
-XX:HeapDumpPath=heap/heapdump.hprof 保证当服务器出现堆内存溢出时能够把当前的堆使用情况记录到heap目录下的heapdump.hprof 文件中(这就好比是一个人被杀了,临死之前拍了一段录像,然后把录像放到某个柜子里)
经过上面堆内存参数的配置,发生堆内存溢出后你本地会有两个文件gc.log和heapdump.hprof
gc.log记录了gc情况,可以到GcEasy官网去分析
heapdump.hprof记录了堆内存情况,借助jvisualvm工具或MAT工具分析
1、gc.log怎么看
gc.log怎么看?
GcEasy
下面为其它视频讲解的内容
其它GC日志分析的工具
GCViewer
还有GChisto
2、heapdump.hprof怎么看?
①jvisualvm查看
备注:下面的截图来自另一个视频>
②使用MAT查看
MAT是Eclipse自带的工具,可以单独安装,而且MAT是专门做堆内存分析的,功能比JvisualVM更强大
备注:下面的图来自其它视频
Histogram直方图:
内存泄露情景之一:有些对象生命周期本身没有必要那么长,但是由于外面有对象引用它了,导致它迟迟不能回收
thread overview
thread overview可以查看系统中的所有的Java线程,也可以查看到线程里面局部变量的信息
线程对应一个独立的栈,栈里面保存着栈帧(局部变量)
支配数
概览
OQL语句
java.lang.OutOfMemoryError:Metaspace
这段代码是个死循环,期间它创建了大量代理类导致方法区被撑爆,而你元空间内存设置的过小-XX:MetaspaceSize=60m -XX:MaxMetaspaceSize=60m
1、实时分析—jstat
因为代码是死循环所以一直在运行,上面代码程序运行时,你可以使用jstat分析
jstat -gc 10376
是查看当前进程gc的信息,jstat -gc 10376 1000 10
是每1000ms(每1秒)打印一次,一共打印10次
可以看到,FullGC非常频繁,而且我们的方法区,占用了58729KB/1024= 57.8M空间,你JVM参数里面方法区设置的是60M,几乎把整个方法区空间占用,所以得出的结论是方法区空间设置过小,或者存在大量由于反射生成的代理类。
2、实时分析—jvisualvm
因为代码是死循环所以一直在运行,上面代码程序运行时,你可以使用jvisualvm分析
3、离线分析—gc.log
因为你加了-XX:+PrintGCDetails -XX:+PrintGCDataStamps -XLoggc:./logs/gc.log
这些jvm参数,所以-XLoggc:./logs/gc.log
把GC日志写入到一个文件里面去,你查看这个文件可以看到频繁发生Full GC
使用GcEasy查看这个gc.log
4、离线分析—dump快照
因为你加了-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heap/heapdumpMeta.hprof
这些jvm参数,所以你可以分析生成的dump文件
-XX:+HeapDumpOnOutOfMemoryError 保证当服务器出现堆内存溢出时能够把当前的堆使用情况记录下来(这个很关键,你要是没有这个参数就不会记录当时的堆内存情况。这就好比是一个人被杀了,临死之前拍了一段录像一样。)
-XX:HeapDumpPath=heap/heapdumpMeta.hprof 保证当服务器出现堆内存溢出时能够把当前的堆使用情况记录到heap目录下的heapdumpMeta.hprof 文件中(这就好比是一个人被杀了,临死之前拍了一段录像,然后把录像放到某个柜子里)
使用JvisualVM分析