一个针对高并发、低延迟应用设计的高性能 Java 性能监控和统计工具。

特性

高性能: 单线程支持每秒 1000 万次 响应时间的记录，每次记录只花费 73 纳秒

无侵入: 采用 JavaAgent 方式，对应用程序完全无侵入，无需修改应用代码

低内存: 采用内存复用的方式，整个生命周期只产生极少的临时对象，不影响应用程序的 GC

高精度: 采用纳秒来计算响应时间

高实时: 支持秒级监控，最低 1 秒

使用场景

在开发环境中快速定位 Java 应用程序的性能瓶颈

在生产环境中长期监控 Java 应用程序的性能指标

文档

English Doc

中文文档

监控指标

MyPerf4J 为每个应用收集数十个监控指标，所有的监控指标都是实时采集和展现的。

下面是 MyPerf4J 目前支持的监控指标列表:

Method Metrics

RPS，Count，Avg，Min，Max，StdDev，TP50, TP90, TP95, TP99, TP999, TP9999, TP99999, TP100

JVM Metrics

Thread，Memory，ByteBuff，GC，Class

想知道如何实现上述效果？请先按照快速启动的描述启动应用，再按照这里的描述进行安装配置即可。

快速启动

MyPerf4J 采用 JavaAgent 配置方式，透明化接入应用，对应用代码完全没有侵入。

打包

git clone git@github.com:LinShunKang/MyPerf4J.git

mvn clean package

把 MyPerf4J-ASM-${MyPerf4J-version}.jar 重命名为 MyPerf4J-ASM.jar

可以尝试直接下载 MyPerf4J-ASM.jar

配置

在 JVM 启动参数里加上以下两个参数

-javaagent:/your/path/to/MyPerf4J-ASM.jar

-DMyPerf4JPropFile=/your/path/to/myPerf4J.properties

形如：java -javaagent:/your/path/to/MyPerf4J-ASM.jar -DMyPerf4JPropFile=/your/path/to/myPerf4J.properties -jar yourJar.jar

注意：使用 Windows 的同学，请注意修改路径格式，包括 MyPerf4JPropFile 中的文件路径

其中，MyPerf4JPropFile的配置如下:

#应用名称

AppName=MyPerf4JTest

#MetricsProcessor类型，0:以标准格式化结构输出到stdout.log 1:以标准格式化结构输出到磁盘 2:以InfluxDB LineProtocol格式输出到磁盘

MetricsProcessorType=1

#配置各个Metrics日志的文件路径，可不配置

MethodMetricsFile=/data/logs/MyPerf4J/method_metrics.log

ClassMetricsFile=/data/logs/MyPerf4J/class_metrics.log

GCMetricsFile=/data/logs/MyPerf4J/gc_metrics.log

MemMetricsFile=/data/logs/MyPerf4J/memory_metrics.log

BufPoolMetricsFile=/data/logs/MyPerf4J/buf_pool_metrics

ThreadMetricsFile=/data/logs/MyPerf4J/thread_metrics.log

#配置Record模式，可配置为accurate/rough

RecorderMode=accurate

#配置时间片，单位为ms，最小1s，最大600s

MilliTimeSlice=10000

#需要监控的package，可配置多个，用英文';'分隔

IncludePackages=cn.perf4j.demo;cn.perf4j.demo1.[p1,p2,p3];cn.*.demo.*

#是否展示方法参数类型

ShowMethodParams=true

查看配置文件模板。想了解更多的配置？请看这里

运行

输出结果，输出到 /data/logs/MyPerf4J/method_metrics.log:

MyPerf4J Method Metrics [2019-03-03 17:27:50, 2019-03-03 17:28:00]

Method[5] Type RPS Avg(ms) Min(ms) Max(ms) StdDev Count TP50 TP90 TP95 TP99 TP999 TP9999 TP99999 TP100

DemoServiceImpl.getId1(long) General 51317 0.00 0 1 0.00 513178 0 1 1 1 1 1 1 1

DemoServiceImpl.getId2(long) General 168637 0.00 0 4 0.00 1686377 0 1 2 3 4 4 4 4

DemoServiceImplV2.getId1(long) General 357 0.00 0 0 0.00 3570 0 0 0 0 0 0 0 0

DemoServiceImplV2.getId3(long) General 713 0.51 0 5 0.08 7138 0 1 2 3 4 5 5 5

Dao.doQuery() DynamicProxy 1394 0.51 0 5 0.05 13944 0 1 2 3 4 5 5 5

整体架构

详情请参考 这里

数据采集

MyPerf4J 目前采用 ASM 字节码修改框架在 JVM 加载类时修改 Java 方法的字节码:

在方法的开头加入 long start = System.nanoTime();

在方法的结尾加入 ProfilingAspect.profiling(start, methodId);，其中 methodId 为类加载时为每一个方法分配的唯一 ID

想了解 ASM？请下载 ASM4使用指南.pdf

数据存储

MyPerf4J 采用 数组(timingArr) + Map(timingMap) 的方式存储方法的响应时间：

在 timingArr 中，数组下标代表方法的响应时间，而下标对应的元素值代表该响应时间出现的次数，例如从上图中可以看出，timingArr 中记录了 100次 0ms 的响应，0次 1ms 的响应，80次 2ms 的响应 和 20次 3ms 的响应

在 timingMap 中，Map 的 key 代表方法的响应时间，而 key 对应的 value 代表该响应时间出现的次数，例如，从上图中可以看出，timingMap 中记录了 120次 1010ms 的响应，102次 1025ms 的响应，95次 1041ms 的响应，1次 2094ms 的响应

MyPerf4J 内存占用分析：

假设你有 1024 个方法需要监控，并且 timingArr 长度为 3000，timingMap 大小为 128，Recorders 转盘的数量为 3

每个 timingArr 占用 3000 * 4B = 12KB 的空间

每个 timingMap 占用的空间为 128 * 64B = 8KB，其中，每个 Map.Node 占用 64B（32B + 16B + 16B） 综上所述，监控这 1024 个方法只需要占用 3 * 1024 * (12KB + 8KB) = 60MB，并且这 60MB 的对象常驻在内存中，除了 timingMap 扩容和缩容时会分配少量内存外，所有的对象在 MyPerf4J 的整个生命周期中只分配一次！

数据处理

为简化处理流程，以 timingArr 为例进行说明：

第一步，通过遍历一次 timingArr 可以计算出所有响应时间及其出现的次数，把这份数据存入 sortedRecords 中，在 sortedRecords 偶数下标代表响应时间，奇数下标代表次数，以上图为例，0ms 出现 100次，2ms 出现 80次，3ms 出现 20次

第二步，把 sortedRecords 按逻辑展开，即可快速计算出 TP50、TP90 和 TP99 等指标，以上图为例，把 sortedRecords 按逻辑展开，可以得到连续存放的 100 个 0、80 个 2 和 20 个 3，一共 200 个响应时间，那么 TP50 对应于下标为 200 * 50% = 100 的值，也就是 2ms