Day04_JVM实战
文章目录
- 一、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 保证当服务器出现堆内存溢出时能够把当前的堆使用情况记录下来（这个很关键，你要是没有这个参数就不会记录当时的堆内存情况。这就好比是一个人被杀了，临死之前拍了一段录像一样。&#x