一次简单的JAVA进程到线程资源使用率异常分析-京东云开发者社区

### 1 前言导读

开发&测试人员在应用运行&测试过程中会遇到以下常见问题

- 在测试&调试过程中，应用会出现卡顿或接口响应失败问题，不知如何入手？
- 开发&测试人员在排查响应失败问题时发现CPU&内存异常性飙高，究竟是哪个进程？哪个线程？
- 针对进程&线程的异常资源使用，是否有具体的方法定位至代码层面，节约测试&开发时间？

一般遇到此类资源使用异常类问题，很多人会采取重新部署或重启应用的方式解决，其实并没有解决当前应用的真实痛点，如果后面调用量持续增长，当前操作并不会从根本上解决当前问题。

以下就是通过对物流客服中某个应用出现的异常资源使用率的分析，作为具体的操作实例，按照进程->线程->异常堆栈->代码 的逻辑过程，为各位提供参考。

### 2 整体思路
针对分析过程，参考如下的重要节点的逻辑过程图
![](//img1.jcloudcs.com/developer.jdcloud.com/316b936a-2a72-4c8a-ad45-15b36208d0df20210726114054.png)

### 3 分析过程
#### 3.1 问题来源
开发在测试环境中调试代码时，发现应用basic-platform的CPU资源使用率一直处于700%左右，分析思路如下图所示

![](//img1.jcloudcs.com/developer.jdcloud.com/a9ae07b8-1c35-4e42-81b8-be7bcb43c2ba20210726114127.png)

#### 3.2 实例分析
##### 步骤一：定位至进程
![](//img1.jcloudcs.com/developer.jdcloud.com/4b016a73-cffe-43bd-9a72-e70409cd967920210726114148.png)

通过命令：top 查找出资源消耗异常的进程，如图所示，PID：21944
##### 步骤二：打印异常堆栈
![](//img1.jcloudcs.com/developer.jdcloud.com/9fe00579-bb25-4317-9140-e243c38679bf20210726114205.png)

通过命令：jstack 21944 >/home/admin/ps.txt 将该异常进程对应的错误堆栈信息输入到文件ps.txt中
##### 步骤三：定位至线程

![](//img1.jcloudcs.com/developer.jdcloud.com/5b1d6935-6743-414a-a402-b78dffe0100f20210726114247.png)

通过命令：ps -mp 21944 -o THREAD,tid,time 查看当前进程21944 对应的线程数资源使用情况，并找出CPU使用率较高的线程号，如图所示
##### 步骤四：异常堆栈日志搜索定位

![](//img1.jcloudcs.com/developer.jdcloud.com/44a7e904-4307-4703-8d42-3c6d1e4f649c20210726114309.png)

选取使用率异常的线程号，并将线程号10进制的转为16进制，比如：31098 转为 797a，ps.txt堆栈文件中搜索16进制线程号797a，以上截图即为当前线程运行过程中，对应的异常堆栈信息
##### 步骤五：通过异常信息定位代码

![](//img1.jcloudcs.com/developer.jdcloud.com/297f42f1-4c53-4575-acf0-c80827abe54620210726114330.png)

以上截图异常信息给开发或者自己有能力可以通过异常堆栈信息对应的代码行数来进行问题分析

通过步骤4中的前两行异常，可定位至代码文件中如下图所示处：递归中缺失if语句缺失对应的else导致

### 4 踩坑实录
#### 4.1 hsperfdata_${USER}文件说明
jvm运行时会生成一个目录hsperfdata_USER(USER(USER是启动java进程的用户),在linux中默认是/tmp,目录下会有些 pid文件,存放jvm进程信息,而jmap,jstack等工具会读取/tmp/hsperfdata_$USER下的pid文件获取连接信息.---jstack的数据来源

![](//img1.jcloudcs.com/developer.jdcloud.com/b3255b3c-055b-4fda-9b81-25251a5d467c20210726114403.png)

#### 4.2 使用Jstack过程遇到问题
- 命令行输入jps命令，出现process information unavailable

![](//img1.jcloudcs.com/developer.jdcloud.com/3b732bbe-f1fe-484a-bf38-198e3457954e20210726114441.png)

- 需要考虑原因两个

a. 监控的进程在/tmp/hsperfdata_${USER}目录下是否有对应的进程号
![](//img1.jcloudcs.com/developer.jdcloud.com/d5df527e-0a42-4b60-bc5f-dc46c2827cf620210726114501.png)

如图所示：
hsperfdata_root目录下文件为空
hsperfdata_admin目录下文件为当前进程21215

b.	解决方案：切换admin用户，然后执行jstack命令
c.	解决原因：当前进程号21215对应的Java进程，启动权限为admin用户，所以通过jstack监控的数据仅能在admin用户目录下看到
d. 也说明一个问题：通过Qone平台部署的Java应用，启动权限都为admin用户，在这里要注意手动启动权限与Qone保持一致

![](//img1.jcloudcs.com/developer.jdcloud.com/66282968-5c39-4e86-b233-964735e1e8dc20210726114521.png)

### 5 其他周边知识

![](//img1.jcloudcs.com/developer.jdcloud.com/011a3192-83ca-4a82-996a-25829cbcde4120210726114543.png)

借着本次问题定位的机会，对java中内存的模型进行了再次的查缺补漏。

------------

###### 自猿其说Tech-JDL京东物流技术发展部
###### 稿件来源：西安CS测试小分队 傅世嘉