Jprofiler JAVA of performance monitoring tools
https://www.jianshu.com/p/1287704d1803
First, the code quality assurance
When the current code quality, security, tools, test coverage has a corresponding metrics and mature, but the performance has been in a vacant stage, suggested that the performance of the front into the development or testing phase can solve most (forecast at 30 to 50%) performance problems (you can first practice in the summary).
Second, the current problems existing performance testing
Performance testing tool selection, and jvm tuning, program design non-essential, otherwise we will do a lot of wasted effort.
Three, the Java code that monitoring and analysis tools
3.1 jporfiler
Tools Description: J Profiler the Java development software performance testing tools to facilitate the development of performance test development software, to improve development efficiency, but also to ensure software performance.
advantage:
1, CPU, Thread, Memory function is especially powerful analysis
2, support for jdbc, slow Sql monitoring, jsp, servlet, socket were analyzed
3, analysis support multiple modes (offline and online)
4, support for IDEA, eclipse plug-in, if the identification code performance problems in the production process will be able to solve most performance problems. Conservative about 30 to 50%.
5, support cross-platform: windows, liunx, macos ...
Disadvantages:
1, in a high throughput when jprofiler tools themselves unable to respond, Bunsen will consume a certain performance. And under certain conditions also can not find a leak
2, jprofiler at startup more consumption of server resources, single-process cpu% at about 100.
3, when the interface in response to the same scene quickly without opening the open jprofler jprofiler cpu using phase 7 to 20%, about 20% memory usage.
4, jprofiler monitor itself will monitor data written to disk, 5s write once, request to be recorded when jprofile things more quickly can cause abnormal termination process monitoring service.
3.2 jvisualvm
Tool Description: the Jdk own monitoring tools jvm jvisualvm by detecting the JVM loads class and object information to help analyze the memory usage
advantage:
1 , no additional installation, only need to configure remote jmx connection.
Disadvantages: can not monitor slow sql.
3.3 MAT
Description tools: the Java memory overflow performance analysis tools
advantage:
2, single-line memory leak points to this feature more advantages
Disadvantages: single function
Fourth, the installation
Download: https://www.ej-technologies.com/download/jprofiler/version_92
Fifth, view instructions
5.1 Telemetries telemetry view
5.2 Live Memory- memory view
This view focuses on object memory allocation, the following tabs
All Objects
Real-time display of the object where heap: indicates a type (aggregation level may be a class, package, etc.) Number (Instance Count) object, shallow dimension (Shallow size) is calculated on the size of the shallow:
Calculation does not include the common reference object size, class variables, itself composed by a variable address, the basic types of memory occupied by other variables
Calculating the overall array is not divided into individual elements calculated size / number
Note that some objects although there is no reference, but it may not be recovered GC, you can manually Run GC
右击某一类型，可以转到Class Tracker或者Heaper Walker视图
Recorded Objects
显示已经进行记录的对象。与All Objects相比，可以查看对象分配调用树（Allocation Call
Tree）、分配热点（Allocation Hot Sports）点击工具栏：Start Memory，可以录制对象分配
Allocation Call Tree
显示选中的、已录制对象类型的分配调用数，分析调用栈的哪些栈帧比较消耗资源。从线程执行开始处，一直追溯到对象被创建的地方，显示对象占用内存的大小。
Allocation Hot Sports
显示选中的、已录制对象类型的分配热点：以创建对象的方法为根显示调用树，一般看 hot sports
Class Tracker
显示选中类型对象的实例个数的曲线图
5.3 Heap Walker –堆遍历视图
该视图用于静态分析堆快照，在生成快照之前，会进行一次Full GC。包含以下选项卡:
Classes
类似于Memory Views的All Objects，可以显示快照中所有对象的数量、大小。右击选择Use Selected Instances，则可以显示单种类型的数据。
Allocations
分析对象分配情况：包括4种显示方式：Cumulated Allocation Tree：累积调用树，显示对象分配调用树，包含对象sizeAllocation Tree：调用树，显示对象分配调用树，包含对象sizeAllocation
Tree Map：以Tree Map形式显示调用树Allocation
Hot spots：显示分配对象最多的方法
Biggest Objects
显示占用内存最多的对象
References
显示单种类型的引用情况包含4种显示方式：Incoming references：其它对象对每一个选中对象的引用Outcoming references：每一个选中对象对其它对象的引用。Cumulated Incoming
references：显示其它对象、字段对选中对象类型的总体引用统计Cumulated 。Outcoming references：显示选中对象类型对其它对象、字段的总体引用统计。
Time
分析对象分配的消耗时间。
Inspections
提供多种精细的对象分配分析方式。
Graph
图形化方式显示对象的引用图。
5.4 CPU Views –CPU视图
该视图用于分析方法的CPU占用时间，通过执行时间越长则占用CPU的资源则越多包括以下选项卡：
Call Tree
显示自顶而下的调用堆栈的树，树的根是线程开始处，树的分叉表示的不同的调用路径。暗红色显示当前节点及其子节点消耗的时间、高亮红色显示本级节点消耗的时间。
显示未过滤类对过滤类的直接调用，不显示深入的调用，在被过滤类的左上角显示红三角。main方法、线程的run方法总是显示，不予过滤。
通过Profiling
Settings可以选择CPU时间的度量方式：Elapsed
time/Estimated CPU time，前者为Wall clock time（物理世界真实时间），后者为占用CPU的时间。由于操作系统的固有限制，10ms以下的时间可能不具有统计学意义。
界面右上角的Thread Status用于选择参与分析的线程状态，通常选择Runnable来分析性能问题，有时可以结合Net I/O、Blocked。
工具栏Start Tracking，可以追踪某些任务在不同线程之间的传递（调用点/执行点Call site/Execution site）
Hot Spots
显示耗时最高的方法调用，显示消耗时间、平均消耗时间、调用次数等字段，以耗时方法为根，可以追溯到线程启动处Filtered Classes设置：选择被过滤类占用时间，可以单独列出，或者算在调用它的元素上（main、线程run不能过滤）每个方法可能被多个调用栈调用，百分比显示不同调用栈对此方法的固有时间的“贡献”不显示Total time，只显示Inherent Time
Call Graph
显示方法调用的序列，包括某个方法的调用与被调用情况
Method Stat
点击工具栏图标，可以录制方法的统计信息并进行分析
Call Tracer
点击工具栏图标，可以对方法调用进行跟踪
5.5 Thread –线程视图
该视图用于分析线程的状态和历史分析、检测死锁，并可以获取线程快照，包含以下选项卡：
Thread History
线程状态时间线，可以选择显示活着的或者死去的线程。
绿色：Runnable：表示线程可以接受CPU调度，但不一定正在占用CPU，和线程优先级、调度算法、系统负载有关
黄色：Waiting：表示线程正在睡眠（java.lang.Thread.Sleep），或者在监视器上等待（java.lang.Object.wait），前者不会放弃占有的监视器
红色：Blocked：表示线程被阻塞，正在积极尝试进入同步区
浅蓝色：Net
I/O：线程正在等待网络操作的完成，监听Socket或者读写Socket时产生此状态
Thread Monitor
显示线程的开始结束时间、父线程、状态等信息
Thread Dumps
获取线程快照，可以分析瞬时系统各线程的调用栈
5.6 Monitor Views-监视器视图
该视图用于锁状态检测，包含以下选项卡:
Current Locking Graph
当前锁状态图，显示监视器、以及在监视器上等待的线程。
黑色箭头表示当前拥有此监视器的线程
红色虚线表示被阻塞的线程（积极尝试获得锁）
黄色箭头表示在监视器上等待的线程（java.lang.Object.wait）
Current Monitors
显示当前活动的监视器，包括监视器状态、监视器类、等待线程、拥有者线程等信息
Locking History Graph
可以录制监视器锁定的历史
Monitor History
可以显示所有监视器的历史
Monitor Usage Stat
以监视器、线程等方式分组，显示监视器的使用统计，包括阻塞次数、阻塞持续时间、等待次数、等待持续时间等
5.7 Database-数据库视图
该视图用于查看jdbc连接及执行情况，包括以下选项
Time lineIdle
颜色：黄色,表示:空闲的
Statement execution:颜色:绿色，表示：语句执行
Perpared Statement execution：颜色：蓝色，表示：准备执行。
Batch execution：颜色：紫色，表示批量执行。
Connections
连接数，连接id,开始时间，结束时间，事件个数，事件执行持续时间
Call Tree
显示自顶而下的调用堆栈的树，树的根是线程开始处，树的分叉表示的不同的调用路径。暗红色显示当前节点及其子节点消耗的时间、高亮红色显示本级节点sql执行消耗的时间。
界面右上角的Thread Status用于选择参与分析的线程状态，通常选择Runnable来分析性能问题，有时可以结合Net I/O、Blocked。
Hot Spot
显示耗时最高的方法调用，显示消耗时间、平均消耗时间、调用次数等字段，以耗时方法为根，
Conection leacks
Telemetries执行时间分布图
events
连接事件
Trackes
工具栏Start Tracking，可以追踪某些任务在不同线程之间的传递（调用点/执行点Call site/Execution site）
5.8 JavaEE以及探针（JEE & Probes）
可以使用多种探针来检测不同的应用领域，包括：JDBC、JPA/Hibernate、JNDI、JMS、Servlet、RMI、Socket、WebServices、Files等。
六、性能测试分析
6.1 内存泄漏的现象
a. 在服务器中执行某些批量操作的时候，发现内存只升不降；就算gc后，内存也不能被完全释放；
b. 除非重启tomcat服务器，内存永远不会被释放，反复执行这些操作，会导致无可用内存，会导致进程被kill。
6.2 内存分析
系统的内存消耗过多往往有以下几种原因：
a、频繁创建Java对象，如：数据库查询时，没分页，导致查出表中所有记录；
b、存在大对象，如：读取文件时，不是边读边写而是先读到一个byte数组，这样如果读取的文件时50M则仅此一项操作就会占有JVM50M内存。
c、存在内存泄漏，导致已不被使用的对象不被GC回收，从而随着系统使用时间的增长，内存不断受到解压，最终OutOfMemory。
6.3 CPU 分析
a、CPU消耗的分布及时间(cpu时间或者运行时间); 方法的执行图; 方法的执行统计(最大，最小，平均运行时间等)
b、主要看hot spots看那个资源耗时时间，平均时长，及访问次数。
c、请求响应时时间越长越消耗CPU。
6.4 线程分析
线程的运行情况可以直接反应出系统的瓶颈所在，对线程一般有以下三个关注点：
a、Web容器的线程最大数管理，Web容器允许开启的线程数与系统要求的最大并发数有一定的对应关系，通常是Web容器运行的线程数略大于最大并发数，以Tomcat为例，在{$tomcat}/conf/server.xml文件的Connector选项里配置maxThreads，它的默认值时150；
b、线程阻塞；
c、线程死锁。
d、亮蓝色表示线程在 Net I/O操作，线程在等待 JAVA库的网络操作完成。在线程监听 socket连接或者等待读写数据到 socket中时，会产生这种状态
6.5 database分析
主要看 Hot Spots显示耗时最高的方法调用，显示消耗时间、平均消耗时间、调用次数等字段，以耗时方法为根。
a、sql执行较慢的需要优化sql。
b、执行次数较多也需要处理。
c、查看db最大线程数是多少，是否满足当前业务，如果不满足需要调整。
d. 在性能执行过程中若接口请求较快时需要添加一定的think time，这个根据项目而定，一般在100ms左右。