Java-JVM-jstat简单使用

Java-JVM-jstat简单使⽤1. 概述
1. jstat 的简单使⽤
2. 背景
1. jvm 是⾯试经常被问到的东西
1. ⾯试造⽕箭的典型
2. ⾯试完了, 基本不⽤, 所以就会被渐渐忘记
2. 我⼀直觉得, 这些监控⼯具, 是性能调优的基础
1. 看都看不清, 后续根本没法做
3. 环境
1. OS
1. win10
2. Java
1. 1.8.0_201
3. demo
1. Spring Boot
1. 2.1.3
4. shell
1. win10 cmd
1. 准备
1. jps
1. 作⽤
1. 查找 java 进程的 pid
2. jstat 命令需要基于 java 进程的 pid
2. jstat
1. 概述
1. jstat 是什么
2. jstat
1. Java ⼯具
1. 统计运⾏时 jvm 的信息
2. 信息
1. 内存信息
1. 堆栈容量
2. gc 信息
3. 编译信息
4. 其他
3. 基本格式
1. 概述
1. 命令基本格式
2. 这⾥只讲本地调试
2. 格式
# option 是命令⾏选项
# pid 是⽬标进程的 pid
# interval 是时间间隔, 单位是 ms
> jstat <option> <pid> [interval]
3. 例⼦
# 假设 pid 是 18436
# 1. 没有 interval, 只执⾏⼀次
> jstat -class 18436
# 2. interval = 1000ms, 每隔 1s 执⾏⼀次
# 可以通过使⽤单位 s 来调整, 这个我就不细说了
> jstat -class 18436 1000
4. 简单使⽤
1. 概述
1. 简单使⽤命令
2. 例⼦不带 interval
1. 类加载统计
1. 命令
>jstat -class 18436
Loaded Bytes Unloaded Bytes Time
6700 12069.9 1 0.9 2.03
2. 解释
1. Loaded
1. 已经加载的类数量
1. 6700 个
2. Bytes
1. 已经加载的类⼤⼩
1. 12069.9 kB
3. Unloaded
1. 卸载的类数量
1. 1 个
4. Bytes
1. 卸载的类⼤⼩
1. 0.9 kB
5. Time
1. 装载和卸载的总时间
1. 2.03 s
3. 疑问
1. unloaded 的理解
1. 问题
1. unloaded 到底是什么意思
2. 思考
1. 未加载
1. 没有加载的话, 为什么要统计 Bytes
2. 没有装在的话, Time ⾥为什么要占⽤时间
3. 结果
1. Unloaded 是指卸载
1. 曾经装载过, 并且⽬前已经不在堆内存⾥了
2. 编译统计
1. 命令
>jstat -compiler 18436
Compiled Failed Invalid Time FailedType FailedMethod
3456 0 0 0.63 0
2. 解释
1. Compiled
1. 编译的类
1. 3456 个
2. Failed
1. 编译失败的类
1. 0 个
3. Invalid
1. ⾮法的类
1. 0 个
4. Time
1. 编译时间
1. 0.63 s
5. FailedType
1. 失败类型
1. 0 个
6. FailedMethod
1. 失败的⽅法
1. ⽆
3. 疑问
1. 编译
1. HotSpot VM 的 JIT 编译
1. ⽼实说, 这块我不熟...
3. 编译情况
1. 命令
>jstat -printcompilation 18436
Compiled Size Type Method
3456 201 1 org/apache/coyote/AbstractProtocol startAsyncTimeout
2. 解释
1. Compiled
1. 同编译统计
2. Size
1. 最近被编译类的⼤⼩
1. 201 kB
3. Type
1. 最近被编译类编译类型
1. 1
4. Method
1. 最近被编译的⽅法
1. org/apache/coyote/AbstractProtocol 下的 startAsyncTimeout ⽅法
2. . 被换成了 /
3. 疑问
1. 编译类型
1. 这个 1 是什么意思?
4. gc 统计概览
1. 命令
>jstat -gcutil 18436
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 26.91 18.76 3.27 94.45 90.38 3 0.025 1 0.017 0.042
2. 解释
1. S0
1. S0区使⽤率
1. 0%
2. S1
1. S1区使⽤率
1. 26.91%
3. E
1. 伊甸区使⽤率
1. 18.76%
4. O
1. ⽼年区使⽤率
1. 3.27%
5. M
1. 元数据区使⽤率
1. 94.45%
1. 压缩类型区使⽤率
1. 90.38%
7. YGC
1. 青年代 gc 次数
1. 3 次
8. YGCT
1. 青年代 gc 时间
1. 0.025 s
9. FGC
1. 完全 gc 次数
1. 1 s
10. FGCT
1. 完全 gc 时间
1. 0.017 s
11. GCT
1. 所有 gc 总共⽤时
1. 0.042 s
2. 结果的由来, 是 YGCT + FGCT 的值
3. 问题
1. 堆内存的组成
1. 模糊的感觉
1. 青年代
1. 伊甸区
2. S0
3. S1
2. ⽼年区
3. 元数据区
1. 压缩类型
2. 区域划分的原因, 每个区域的责任
1. 后续
3. 对象在各个区域间, 运动的规律
4. gc 触发的规律
5. gc 统计
1. 命令
>jstat -gc 18436
S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 43520.0 43520.0 0.0 11712.6 262144.0 63436.5 455168.0 14880.5 34560.0 32641.5 4864.0 4395.9 3 0.025 1 0.017 0.042 2. 解释
1. S0C
1. S0区当前⼤⼩
1. 43520 kB
2. S1C
1. S1区当前⼤⼩
1. 43520 kB
3. S0U
1. S0区使⽤
1. 0 kB
4. S1U
1. S1区使⽤
1. 1171
2.6 kB
5. EC
1. 伊甸区当前⼤⼩
1. 262144.0 kB
1. 伊甸区使⽤
1. 63436.5 kB
7. OC
1. ⽼年区当前⼤⼩
1. 455168.0 kB
8. OU
1. ⽼年区使⽤⼤⼩
1. 14880.5 kB
9. MC
1. 元数据区当前⼤⼩
1. 34560.0 kB
10. MU
1. 元数据区使⽤⼤⼩
1. 32641.5 kB
11. CCSC
1. 压缩内存区当前⼤⼩
1. 4864.0 kB
12. CCSU
1. 压缩内存区使⽤⼤⼩
1. 4395.9 kB
13. YGC
1. 青年代 gc 次数
1. 3 次
14. YGCT
1. 青年代 gc 时间
1. 0.025 s
15. FGC
1. 完全gc 次数
1. 1 次
16. FGCT
1. 完全gc 时间
1. 0.017 s
17. GCT
1. 总 gc 时间
1. 0.042 s
6. gcold
1. 命令
>jstat -gcold 18436
MC MU CCSC CCSU OC OU YGC FGC FGCT GCT 34560.0 32641.5 4864.0 4395.9 455168.0 14880.5 3 1 0.017 0.042 2. 解释
1. 都快写完了, 发现好像之前已经解释过了
1. 于是我删除了...
7. gcold capacity
1. 命令
>jstat -gcoldcapacity 18436
OGCMN OGCMX OGC OC YGC FGC FGCT GCT
699392.0 11173888.0 455168.0 455168.0 3 1 0.017 0.042
2. 解释
1. OGCMN
1. ⽼年代初始⼤⼩
2. OGCMX
1. ⽼年代最⼤⼤⼩
3. OGC
1. ⽼年区当前容量
4. OC
1. ⽼年区当前容量?
3. 疑问
1. old space 和 old generation 是⼀个东西吗?
1. 这个我⽬前还不能确定
2. 但是 OGC 和 OC 这俩⼤多数时候, 是⼀样的
4. 后续
1. 其实, 还有⼀些其他的选项
1. ⽐如 new 也有 gc 和 capacity 类似的选项
2. 但是很多东西其实都⼤同⼩异, 内容上差不太多, 所以我就不介绍了
ps
1. ref
1.
1. 官⽹
2.
1. 另⼀篇中⽂描述
3.
1. metaspace 的简介
4.
1. 虽然有点⽂不对题
1. 但是 jstat 的命令⾏整理的还挺好
2. 后续问题
1. unload
2. 编译类型
3. jvm 内存模型
4. old generation 和 old space 的关系
5. 具体的优化思路
6. jstatd 是个类似的命令⾏⼯具, 不过它本质上是个 rmi 服务, 这块如果以后需要, 就去看看。