java dump线程_java dump 查看线程运行情况

一、指标

通常应用服务性能关注以下两方面的指标：

性能指标.jpg

下面将主要是基于CPU指标进行实验模拟分析，下面是一些命令下，cpu指标：

1、top 命令下个字段含义，参考：https://www.jianshu.com/p/078ed7895b0f

2、vmstat 命令：

vmstat-指令.png

us：用户占用CPU的百分比

sy：系统(内核和中断)占用CPU的百分比

id：CPU空闲的百分比

二、实验

1、环境：Linux 2.6.32-696.18.7.el6.x86_64

2、流程：通过Jmeter 对服务接口进行压测，模拟高并发访问，从而使CPU负载飙升。

3、接口代码：

public PlainResult test() throws InterruptedException{

Integer n =0;

synchronized(locka){

try{

for(;;){

if(n < Integer.MAX_VALUE){

continue;

}

n++;

}

}catch (Exception e){

log.info("报错啦");

}

}

return ResultUtils.createSuccessResult("true");

}

4、JEMET 测试：线程数=100 ，循环调用：

Jemter.jpg

三、分析

此时，用户已经感知服务非常的慢，作为开发人员需要定位问题出在哪，以下是基本步骤。

1、首先，我们不知道是哪方面出现了性能问题，因此可以先整体看下服务的性能，通过vmstat 可以获取：

整机性能.png

从上图可以看出，内存、io等无性能瓶颈，但是CPU指标us(用户占用CPU的百分比)非常高，几乎接近100，id(CPU空闲的百分比)-->0，但是sy不高，另外in(系统中断)和cs(上下文切换)的数值非常高，这里可以猜测是用户应用中有大量的线程切换。

2、jps -l 查看有哪些Java进程：

Java 进程.png

可以看到，服务器上只有一个应用服务，其进程pid=24244

3、此时可用top命令可以查看具体信息：

image.png

从上图中可以看到，进程pid=24244一直cpu占用很高，基本可以定位到是该应用出现了性能瓶颈问题。

4、jstack -l 24244 > /data/logs/retail-scrm/test/24244.log dump出该进程下所有线程的堆栈信息.

5、使用 top -H -p 24244 进一步找出高占用CPU的线程：

image.png

从图中可以看出线程为30654 的一直占用着资源。

6、printf "%x" 30654 输出对应16进制的线程号：77be：

image.png

7、进入24244.log 找到对应线程的堆栈信息：

image.png

可以看到在该方法中，获取了一个Object对象锁(private static Object locka = new Object();)，而大量的其他线程则被阻塞等待锁的释放。

image.png

在找到应用中对应的代码，分析其合理性即可。

以上是简单的模拟线上可能出现的性能问题：主要是通过常用命令查看服务器相关指标，并通过dump进程相关堆栈信息来定位应用中可能出现性能问题的节点。文章有不对之处，诚邀斧正，你的批评是我前进的最大动力！