如何在windows下查找java应用占用CPU太高
最近在测试一个用Java语言实现的数据采集接口时发现，接口一旦运行起来，CPU利用率瞬间飙升到85%-95%，一旦中止就恢复到40%如下，这让我不得不面对之前从未关注过的程序性能问题。java
在硬着头皮查找资料定位错误修正bug的过程当中参考了下面两篇文章：windows
windows下揪出java程序占用cpu很高的线程 并找到问题代码 死循环线程代码：http://blog.csdn.net/hexin373/article/details/8846919性能优化
java程序cpu占用太高问题分析：http://www.tuicool.com/articles/ZRzmAvZ（这篇文章中的图片显示不了）工具
最初想经过java自带的jconsole和jvisualvm来调试，但发现jconsole只能知道应用总体状况，不能定位问题，而jvisualvm最多查找到类，性能
若是所示，但不能更详细的进行定位。因而参考了上面两篇文章一步步实现了最终目的。学习
1、查找进程
查找问题进程比较简单，由于问题集中在CPU资源占用太高，那么咱们查找进程时只需关注CPU。方法有两种：测试
一、查看Windows任务管理器优化
打开Windows任务管理器，查看——>选择列，勾选PID，而后查看进程项，并让其按照CPU列排序如图，找到 javaw.exe进程，其PID是9272。ui
二、利用jvisualvm工具spa
打开工具，而后启动应用，在Applications面板中便可看到应用所在进程的PID9272。
须要注意的是该工具并不能定位到线程。
查找到进程之后，将该进程的信息保存到本地，在cmd命令窗口中执行命令：jstack 9272 > C:\test\cdf.log，该命令的做用是将PID为9272的进程信息保存在本地C:\test\cdf.log文件中。
2、查找线程
根据进程查找线程，也有两种方法。
一、使用window自带命令pslist
首先确认系统是否安装了pslist命令程序，若是命令不识别即没有安装，则上微软官方网址http://technet.microsoft.com/en-us/sysinternals/bb896682.aspx下载，下载完将其解压到C:\Windows\System32路径下便可使用。
在cmd命令窗口中执行命令：pslist -dmx 9272，该命令的做用是罗列属于9272进程的线程信息。
经过该命令能够看到TID为9368和12484的线程占用资源最多。这样就基本肯定了线程。
二、利用微软提供的Process Explorer工具
通常在windows下只能查看进程的CPU占用率，想要查看线程的CPU占用率能够经过该工具。下载地址是：http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
下载后运行起来，找到PID为9272的进程
右键点击Properties...选项，看到以下信息：
能够看到占用CPU最多的也是TID为9368和12484的两个线程。
3、问题定位
问题定位须要如下步骤：
一、将线程TID转换为十六进制
由于经过jstack工具导出的信息中线程TID是十六进制的，因此咱们首先转换进制，这里经过系统自带的计算器进行转换。
记录下2498这个数字。
二、在jstack工具导出的cdf.log中查找“2498”
经过Notepad++工具打开该文档，搜索到以下信息，能够看到问题定位到了MQStart.java:174。
去程序中需找该代码：
同理，对于TID=12484的线程也如同以上步骤进行查找，找到了170行代码。
由此基本可判断问题就出在了该段代码上。
4、修复bug
一、查找缘由
经过以上步骤已经定位到了代码片断，可是这段代码看上去没什么错误，查找资料说不少状况是进入死循环了，可是这里肯定不会死循环。思路彷佛进入了死胡同。
无奈之下我将170行的if内的代码段全注释掉了，发现CPU依然飙高，这说明并非这几行代码的错误，而后我if内作了一个输出操做，发现程序快速的不间断的进行输出。
====》
看到这个结果我忽然醒悟，这段代码虽然没有进入死循环，可是循环内的代码并不复杂，并且不必如此频繁的进行检查操做，这中间应该停歇一下。
二、修改方法
根据以上分析，我修改了这段代码：
再次运行测试发现CPU维持在50%之内。
O了，大功告成！
另： 学习java性能调优书籍