转自：
https://www.cnblogs.com/zhongyehai/p/10325363.html
https://www.cnblogs.com/HEWU10/p/5580758.html
JProfiler的安装
1. 下载并安装JProfiler客户端
JProfiler软件下载地址 http://www.ej-technologies.com/
2. IDEA安装JProfiler插件
点击install安装该插件，安装完成后需要重启IDEA
左边插件是通过jprofiler启动tomat，并同时启动jprofiler监测。右边工具是将jprofiler直接绑定到一个活动的JVM中，即时进行监测。在通过profiler启动tomcat的过程中，会出现如图所示需要选择的界面，按照需求选择，我这里是进行java class的jvm性能测试，所以在Initial recording profile中选择 CPU recording ,其他按照默认配置即可。
选择完成后，profiler即进行JVM监控操作，这里可以大致的看到内存、GC垃圾回收、Class、线程、以及CPU加载情况的监控。
JProfiler使用说明
调用树——Call tree
调用树是“CPU视图”部分中的第一个视图，JProfiler构建了从起点到最细粒度的终点的方法调的自上而下的堆栈视图。JProfiler按照总时间对子项进行排序。
要正确解释调用树，了解调用树节点上显示的数字非常重要。对于任何节点有总时间和自我时间。自身时间是节点的总时间减去嵌套节点中的总时间。
用树中的百分比条显示总时间，但自我时间部分显示为不同的颜色。有多种方法可以在视图设置对话框中自定义调用树节点的显示。例如，您可能希望将自我时间或平均时间显示为文本。
在调用树的顶部有几个视图参数，用于更改显示的分析数据的类型和范围。默认情况下，累计所有线程。JProfiler基于每个线程维护CPU数据，您可以显示单线程或线程组。
在任何时候，每个线程都有一个关联的线程状态。如果线程已准备好处理字节码指令或当前正在CPU内核上执行它们，则线程状态称为“Runnable”。在寻找性能瓶颈时，该线程状态很有用，因此默认选择它。或者，线程可以通过在监视器上等待，例如通过调用Object.wait()或 Thread.sleep()在这种情况下线程状态被称为“等待”。
最后，JProfiler添加了一个合成的“Net I / O”状态，用于跟踪线程等待网络数据的时间。这对于分析服务器和数据库驱动程序很重要，因为该时间可能与性能分析相关，例如用于调查慢速SQL查询。
调用树过滤器
如果调用树中显示了所有类的方法，则树通常太深而无法管理。此问题的解决方案是将过滤器应用于调用树，以便仅记录某些类。作为一个积极的副作用，必须收集更少的数据，并且必须对更少的类进行检测，因此减少了开销。
当然这个列表是不完整的，所以你删除它并自己定义感兴趣的软件包要好得多。事实上，仪器和默认过滤器的组合是如此不可取，JProfiler建议在会话启动对话框中更改它。
在调用树中查找节点——Finding nodes in the call tree
有两种方法可以在调用树中搜索文本。首先，通过从菜单调用View-> Find或直接开始键入调用树来激活quicksearch选项。按下后将突出显示匹配项并提供搜索选项 PageDown。使用ArrowUp和ArrowDown键可以循环显示不同的匹配项。
搜索方法，类或包的另一种方法是使用调用树底部的视图过滤器。在这里，您可以输入以逗号分隔的过滤器表达式列表。以“ - ”开头的过滤表达式就像紧凑过滤器一样，否则就像分析过滤器一样。
热点——Hot spots
如果您的应用程序运行速度太慢，您希望找到大部分时间都占用的方法。使用调用树，有时可以直接找到这些方法，但通常不起作用，因为调用树可以包含大量叶节点。
在这种情况下，您需要调用树的反转：所有方法的列表按其总自身时间排序，后面跟踪显示方法的来自所有不同的调用堆栈的调用方式。
默认情况下，热点是从自身时间计算的。您也可以从总时间计算它们，但这对于分析性能瓶颈并不是很有用。
热点的概念不是绝对的。如果你根本没有调用树过滤器，那么最大的热点很可能总是JRE核心类中的方法，比如字符串操作，I / O例程或集合操作。这样的热点不是很有用，因为你不直接控制这些方法的调用，也无法加快它们的速度。
所以热点必须是您自己的类中的方法或您直接调用的库类中的方法。解决性能问题时，您可能希望消除库层，只查看自己的类。您可以通过在热点选项弹出窗口中选择添加到调用配置文件类单选按钮，快速切换到调用树中的该透视图 。
JProfiler使用案例
案例1
TOP：JAVA占的CPU最多
查看进程，是tomcat
使用jprofiler查看，很明显有个自己写的userToString方法占了19%
打开代码看那个方法：里面有使用Gson对json的转换
json转换组件：Gson、jackson、fastjson，三个组件各有优势，但是从从性能方面来说，Gson性能最差，所以直这个情况只能换组件，fastjson性能最好，建议使用fastjson。
案例2
使用jprofiler的方法耗时统计功能，可以统计出每个方法的耗时
50个并发，跑600秒，CPU不高
响应时间300多毫秒，有些慢了，需要优化，一般小于100毫秒，性能算是不错的了，100--500之间，算一般的，500以上，就是很差的。
由于没有经过Nginx，所以直接查看tomcat日志里面的响应时间，和jmeter统计出来的差不多，网络没什么问题。
重新压一下并且打开jprofiler，看看详细分析，doCalculator方法平均耗了200毫秒，应该优化这个方法。
还有一种情况也是需要优化，如doCalculator方法平均用20毫秒，但是调用次数确是其他方法的几倍，造成耗时多。
网友评论