[fix]《手把手教你定位常见 Java 性能问题》图片修复
guide
@ -104,7 +104,7 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8 ](https://docs.oracle
|
||||
### 小技巧
|
||||
|
||||
1. [JAD 反编译](docs/java/tips/JAD反编译tricks.md)
|
||||
2. [手把手教你定位常见 Java 性能问题](./docs/java/tips/手把手教你定位常见Java性能问题.md)
|
||||
2. [手把手教你定位常见 Java 性能问题](./docs/java/tips/locate-performance-problems/手把手教你定位常见Java性能问题.md)
|
||||
|
||||
## 计算机基础
|
||||
|
||||
|
||||
|
After Width: | Height: | Size: 58 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 31 KiB |
|
After Width: | Height: | Size: 25 KiB |
|
After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 41 KiB |
|
After Width: | Height: | Size: 54 KiB |
|
After Width: | Height: | Size: 20 KiB |
@ -1,3 +1,5 @@
|
||||
> 本文来自木木匠投稿。
|
||||
|
||||
## 手把手教你定位常见 Java 性能问题
|
||||
|
||||
## 概述
|
||||
@ -127,15 +129,15 @@ MAT(Memory Analyzer Tool)工具是 eclipse 的一个插件(MAT 也可以单独
|
||||
|
||||
请求接口地址测试`curl localhost:8080/cpu/loop`,发现 CPU 立马飙升到 100%
|
||||
|
||||
|
||||
|
||||
|
||||
通过执行`top -Hp 32805` 查看 Java 线程情况
|
||||
|
||||
|
||||
|
||||
|
||||
执行 `printf '%x' 32826` 获取 16 进制的线程 id，用于`dump`信息查询，结果为 `803a`。最后我们执行`jstack 32805 |grep -A 20 803a`来查看下详细的`dump`信息。
|
||||
|
||||
|
||||
|
||||
|
||||
这里`dump`信息直接定位出了问题方法以及代码行，这就定位出了 CPU 占满的问题。
|
||||
|
||||
@ -158,7 +160,9 @@ MAT(Memory Analyzer Tool)工具是 eclipse 的一个插件(MAT 也可以单独
|
||||
|
||||
我们给启动加上堆内存大小限制，同时设置内存溢出的时候输出堆栈快照并输出日志。
|
||||
|
||||
`java -jar -Xms500m -Xmx500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heaplog.log analysis-demo-0.0.1-SNAPSHOT.jar`
|
||||
```bash
|
||||
java -jar -Xms500m -Xmx500m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/tmp/heaplog.log analysis-demo-0.0.1-SNAPSHOT.jar
|
||||
```
|
||||
|
||||
启动成功后我们循环执行 100 次,`for i in {1..500}; do curl localhost:8080/memory/leak;done`,还没执行完毕，系统已经返回 500 错误了。查看系统日志出现了如下异常：
|
||||
|
||||
@ -168,23 +172,23 @@ java.lang.OutOfMemoryError: Java heap space
|
||||
|
||||
我们用`jstat -gc pid` 命令来看看程序的 GC 情况。
|
||||
|
||||
|
||||
|
||||
|
||||
很明显，内存溢出了，堆内存经过 45 次 Full Gc 之后都没释放出可用内存，这说明当前堆内存中的对象都是存活的，有 GC Roots 引用，无法回收。那是什么原因导致内存溢出呢？是不是我只要加大内存就行了呢？如果是普通的内存溢出也许扩大内存就行了，但是如果是内存泄漏的话，扩大的内存不一会就会被占满，所以我们还需要确定是不是内存泄漏。我们之前保存了堆 Dump 文件，这个时候借助我们的 MAT 工具来分析下。导入工具选择`Leak Suspects Report`，工具直接就会给你列出问题报告。
|
||||
|
||||
|
||||
|
||||
|
||||
这里已经列出了可疑的 4 个内存泄漏问题，我们点击其中一个查看详情。
|
||||
|
||||
|
||||
|
||||
|
||||
这里已经指出了内存被线程占用了接近 50M 的内存，占用的对象就是 ThreadLocal。如果想详细的通过手动去分析的话，可以点击`Histogram`,查看最大的对象占用是谁，然后再分析它的引用关系，即可确定是谁导致的内存溢出。
|
||||
|
||||
|
||||
|
||||
|
||||
上图发现占用内存最大的对象是一个 Byte 数组，我们看看它到底被那个 GC Root 引用导致没有被回收。按照上图红框操作指引，结果如下图：
|
||||
|
||||
|
||||
|
||||
|
||||
我们发现 Byte 数组是被线程对象引用的，图中也标明，Byte 数组对像的 GC Root 是线程，所以它是不会被回收的，展开详细信息查看，我们发现最终的内存占用对象是被 ThreadLocal 对象占据了。这也和 MAT 工具自动帮我们分析的结果一致。
|
||||
|
||||