CN104346148A - 获取程序性能消耗信息的方法、装置及系统 - Google Patents

Abstract

本申请公开了获取程序性能消耗信息的方法、装置及系统，其中，所述方法包括：接收携带有待分析目标信息的分析指令，根据所述待分析目标信息，确定待分析方法；在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强；根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果。通过本申请，能够避免用户手动插入代码的操作过程，而且还可以控制进行字节码增强的范围，降低对实际的业务程序运行造成的影响。

Description

获取程序性能消耗信息的方法、装置及系统

技术领域

本申请涉及Java程序性能排查与分析技术领域，特别是涉及获取程序性能消耗信息的方法、装置及系统。

背景技术

在Java程序的性能问题排查和分析工作中，经常需要获取Java程序的执行路径以及路径上各节点性能消耗情况，也即需要获知Java程序中各个Java方法的执行时间，各个Java方法之间的调用关系，以及Java方法调用的其他方法的执行时间。为了达到该目的，一般的实现方式是在Java方法调用开头和结束处分别增加一段用于记录当前时间和方法标识的代码，并把该数据设置到线程变量中；这样，当最上层被调用的方法的结束处被调用时，刚好在线程变量中成对地产生了包含方法标识信息、方法调用开始时间、方法调用结束时间的信息，这就可以计算出每个方法执行的耗时时间。计算公式是：方法调用消耗时间=方法调用结束时间-方法调用开始时间。同时，由于方法调用的开始和结束都是成对出现的，通过所有方法调用的开始和结束时间的先后顺序，就可以得到方法之间的调用关系树。

现有技术中，为了向Java方法调用开头和结束处增加相关的代码，一种实现方式是由技术人员手工设置。也就是说，当java程序的问题排查人员想要知道某个Java方法消耗的执行时间以及方法内调用的其他方法的执行时间等信息时，可以手动地在各个需要关注的Java方法调用开头和结束处增加相关的代码。这样，当Java程序运行后，就可以得到这些Java方法消耗的执行时间。

但是，这种实现方式下需要技术人员手动地修改程序代码，而且修改之后需要重新部署应用来让这些代码生效。如果要新增一些关注点，则需要重新在这些关注点的调用开头及结束处添加代码并重新部署。所以，这种方式存在硬编码、代价大、需要了解应用程序的代码逻辑等缺点。

为此，现有技术中还提供了另一种实现方式，在这种实现方式中，将前述方式中在Java方法开头和结尾处手工增加相关代码的操作，修改为通过运行时动态操纵Java方法所在类的字节码的方式来实现，也就是说，可以通过字节码操纵框架（如ASM）实现自动增加代码的目的。具体实现时，需要在JVM（Java Virtual Machine，Java虚拟机）启动参数中以javaagent参数指定用于拦截类加载和修改类字节码的jar包，JVM启动后，javaagent参数指定的jar包拦截所有加载的Java类，并在各方法中增加获取方法执行时间的字节码。

相对而言，这种方式省去了手工添加排查代码的麻烦，但是仍然至少存在以下问题：这种方式对所有加载进JVM的Java方法都做了字节码修改，这在一定程度上会影响到被检查应用的代码执行效率。

发明内容

本申请提供了获取程序性能消耗信息的方法、装置及系统，能够避免用户手动插入代码的操作过程，而且还可以控制进行字节码增强的范围，降低对实际的业务程序运行造成的影响。

本申请提供了如下方案：

一种获取程序性能消耗信息的方法，包括：

接收携带有待分析目标信息的分析指令，所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

根据所述待分析目标信息，确定待分析方法；

在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果。

一种获取程序性能消耗信息的方法，包括：

接收用户提交的待分析目标信息；所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

向指定端口发送携带有所述待分析目标信息的分析指令；

触发所述待分析进程对应的Java虚拟机加载指定的代理模块，以便通过所述代理模块执行以下步骤：通过创建Server Socket类监听所述指定端口；通过所述指定端口监听到所述分析指令后，根据所述待分析目标信息，确定待分析方法；在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果，并保存到所述指定位置；从所述指定位置读取所述待分析方法的性能消耗分析结果并返回；

接收到所述代理模块返回的性能消耗分析结果之后进行展现。

一种获取程序性能消耗信息的装置，包括：

指令接收单元，用于接收携带有待分析目标信息的分析指令，所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

待分析方法确定单元，用于根据所述待分析目标信息，确定待分析方法；

字节码增强单元，用于在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

计算单元，用于根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果。

一种获取程序性能消耗信息的系统，包括客户端模块及代理模块，其中：

所述客户端模块包括：

信息接收单元，用于接收用户提交的待分析目标信息；所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

指令发送单元，用于向指定端口发送携带有所述待分析目标信息的分析指令；

触发单元，用于触发所述待分析进程对应的Java虚拟机加载指定的代理模块；

结果展现单元，用于接收到所述代理模块返回的性能消耗分析结果之后进行展现；

所述代理模块包括：

监听单元，用于通过创建Server Socket类监听所述指定端口；

待分析方法确定单元，用于通过所述指定端口监听到所述分析指令后，根据所述待分析目标信息，确定待分析方法；

字节码增强单元，用于在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

计算单元，用于根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果，并保存到所述指定位置；

返回单元，用于从所述指定位置读取所述待分析方法的性能消耗分析结果并返回。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以由用户指定需要分析的方法，并仅对这些需要分析的方法进行自动的字节码增强，以便能够在需要分析的方法被调用的过程中，获取到方法执行所耗费的时间，进而为排查和分析程序中可能存在的问题提供分析依据。在该方法中，不仅可以避免用户手动插入代码的操作过程，而且还可以控制进行字节码增强的范围，降低对实际的业务程序运行造成的影响，也避免了不必要的系统开销。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是调用关系树示意图；

图2是本申请实施例提供的方法性能消耗分析结果的示意图；

图3是本申请实施例提供的方法的流程图；

图4是本申请实施例提供的另一方法的流程图；

图5是本申请实施例提供的装置的示意图；

图6是本申请实施例提供的系统的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

为了能够在对java程序的性能问题进行排查和分析时，避免需要人为手动修改方法的代码，同时也避免所有方法的字节码都被增强导致被检查的应用受到影响，本申请实施例提供了新的获取程序性能消耗信息的方法。在该方法中，可以由分析人员指定需要分析的方法，然后自动实现对这些指定方法的字节码进行增强，进而获取到方法在执行过程中所需的时间等信息，供分析人员对可能存在的问题进行排查及分析。也就是说，本申请实施例提供的方法能够实现自动的对字节码进行增强，避免分析人员手动修改方法的代码，同时，可以实现仅对用户指定的部分方法的字节码进行增强，而不是全部方法，这样可以降低对被检查应用自身代码造成的影响。下面对具体的实现方式进行详细地介绍。

在具体的实现方案中，本申请实施例相当于提供了一种用于获取程序性能消耗信息的工具，从逻辑功能上来看，该工具可以包括两个模块，其中一个模块为客户端模块（client），另一个模块为代理模块（agent）。

client模块主要用于与用户进行交互，例如，可以向用户提供操作界面，用户可以在该操作界面上输入待分析目标信息，例如，待分析进程的信息、待分析方法的信息、待分析方法所属的类的信息，等等；在收到用户提交的待分析目标信息之后，还可以触发待分析进程对应的目标JVM实例（当一个Java程序启动时，对应的JVM实例就产生了，也就是说JVM实例对应了一个独立运行的Java程序，属于进程级别）加载指定的agent模块，与agent模块建立并保持通信，将待分析目标信息发送给agent模块，当agent模块返回待分析方法的性能消耗分析结果（包括方法执行所消耗的时间等）之后，再将其显示给用户。

其中，关于具体如何触发目标JVM实例加载指定的agent，可以有多种方式。例如，其中一种方式可以是将agent模块的地址写入到目标JVM实例的启动参数中，然后重新启动JVM实例，这样，JVM实例在重新启动之后就可以加载agent，之后再由client模块将用户输入的待分析目标信息发送给agent模块，由agent模块进行后续的字节码增强、信息收集计算等操作（关于与agent模块相关的内容，会在后文对agent模块的介绍中进行详细说明）。

当然，在利用上述这种方式来触发目标JVM实例加载agent模块时，需要重新启动目标JVM实例，也就是说，每次接收到用户发送的分析请求时，都需要重新启动JVM实例，这势必会对被检测程序的正常运行造成一定的影响。为了尽量降低这种影响，本申请实施例中还可以采用另一种方式来触发目标JVM实例加载指定的agent模块。也即，client模块可以通过Java的attach API来连接目标JVM实例，并通知目标JVM实例加载指定的agent模块，具体的，就是要根据待分析进程号attach到待分析进程，并指定agent模块的jar包（jar包是一种Java格式的文件，agent模块一般就是以jar包的方式提供）地址，这样目标JVM实例就会根据jar包地址去加载指定的agent模块。也就是说，通过这种方式通知目标JVM实例来加载agent模块，可以实现不必重新启动目标JVM，就能获取到所需的性能消耗分析结果。换言之，对于用户而言，可以在目标JVM实例正在运行的过程中，随时发出对指定的方法进行性能分析的请求，并不会造成JVM实例的重启。

agent模块是用于收集及计算具体的性能消耗分析结果的核心逻辑模块，其需要实现的功能包括：对用户指定的待分析方法进行字节码增强，使得目标JVM实例在运行过程中，能够根据增强后的字节码自动将待分析方法开始被调用时的当前时间以及方法返回时的当前时间记录下来，并保存到一个指定的位置处；最后，一次调用过程结束后，再分别计算此次调用过程涉及到的各个待分析方法在执行时分别消耗的时间，另外还可以获取到各个待分析方法之间的调用关系等等，并返回给client模块向用户进行展现。

具体实现时，在目标JVM实例加载了指定的agent模块之后，agent模块首先可以创建Server Socket类，同时在运行该语句的计算机的指定端口处建立一个监听服务，来接听client模块发送的信息。例如：

ServerSocket MyListener=new ServerSocket(600)；

这里指定提供监听服务的端口是600，一台计算机可以同时提供多个服务，这些不同的服务之间通过端口号来区别，不同的端口号上提供不同的服务。为了随时监听可能的Client请求，可以执行如下的语句：

Socket LinkSocket=MyListener．accept()

该语句调用了ServerSocket对象的accept()方法，这个方法的执行将使Server端的程序（对应于本申请实施例中的agent模块）处于等待状态，程序将一直阻塞直到捕捉到一个来自Client端的请求，并返回一个用于与该Client通信的Socket对象Link-Socket。此后Server程序只要向这个Socket对象读写数据，就可以实现向远端的Client读写数据。结束监听时，关闭ServerSocket对象：

Mylistener．close()

agent模块创建了Server Socket类之后，clien模块可以通过指定端口发送分析指令，相应的，agent模块就可以从相应的端口监听到clien模块发送的分析指令。该分析指令是由client模块根据用户提交的待分析目标信息（包括待分析进程的信息、待分析方法的信息、类的信息等）生成的。因此，相当于通过这种方式，将用户提交的待分析目标信息传递给agent模块。

接下来，agent模块就可以根据分析指令中携带的待分析目标信息确定出此次需要分析哪些方法，然后在目标JVM实例已经加载的类中找到这些待分析方法的字节码，对其进行字节码增强。需要说明的是，一般情况下，都是需要对多个方法的性能消耗情况进行分析，也就是说，用户在发起一个分析请求时，可能包括多个待分析方法。在实际应用中，为了能够让用户能够指定其需要关注的方法，可以有多种方式，并且根据该指定方式的不同，agent模块确定待分析方法的方式也会有所不同。

例如，在一种实现方式下，可以允许用户直接输入其需要关注的各个方法的名称等标识信息，也就是说，在client模块提供的用户界面上，用户可以直接输入待分析的进程号，或者输入各个待分析方法的名称等标识信息，或者输入各个待分析方法所属的类的名称等标识信息。这样，client模块发送给agent模块的分析指令中，相当于直接携带了各个待分析方法的名称以及各自所属的类名称，因此，agent模块可以直接根据类名称以及方法名称定为到待分析方法，进而进行后续的字节码增强等操作即可。

以上这种直接指定待分析方法的名称等标识信息的方式，一般适用于待分析方法的数目比较少的情况，但在实际应用中，可能存在需要对多个方法进行分析的情形，此时，如果仍然直接输入各个待分析方法的名称，则一方面需要耗费用户的时间，降低分析效率，另一方面需要用户对各个方法及其调用关系等非常了解，对用户的知识储备程度要求比较高。因此，在本申请实施例中还为用户提供了另一种指定待分析方法的方式。

在这种方式中，考虑到一次分析过程需要分析的多个方法之间可能存在调用关系，并且根据这种调用关系可以组成一棵调用关系树，因此，在指定这些待分析方法时，可以使用相对简化的方法。

为了便于理解，下面首先对调用关系树的相关概念进行简单的介绍。在一棵调用关系树中，处于根节点上的方法相当于是树的入口，树的第二层节点是根节点依赖的方法，第三层节点是第二层节点依赖的方法，以此类推。例如，参见图1，假设其为一个调用关系树，箭头表示方法之间的调用关系，其中，各个节点对应不同的方法，方法A位于根节点，方法A依赖方法B及方法C，方法B依赖方法D，方法C依赖方法E。也就是说，如果某线程需要调用方法A，则在方法A执行的过程中，需要先调用方法B及方法C，在方法B被调用后，还会调用方法D，方法D执行完毕返回之后，方法B才会返回；在另一分支上，方法C被调用后，还需要调用方法E，方法E被调用完毕返回之后，方法C才会返回，方法B及方法C都返回之后，方法A才会返回。

如果在某次分析需求中，用户恰好是需要对图1中的方法A、B、C、D、E进行排查分析，则相当于是对图1所示的调用关系树上的各个节点进行分析，而这些节点其实可以通过根节点以及树的层次来表示。例如，在已知该调用关系树的结构的前提下，如果又已知根节点为方法A，则第一层节点就是方法A，第二层节点是方法B及方法C，第三层是方法D及方法E。因此，对于这种情况，用户在指定待分析方法的信息时，可以只输入该调用关系树的入口方法的名称以及需分析的层次深度。例如，假设需要对方法A、B、C、D、E进行排查分析，则用户可以指定入口方法为方法A，需要分析的层次深度为3层，则agent模块就可以获知，是需要对以方法A为根节点的调用关系树中的前三层节点进行分析。因此，对于agent模块而言，只要再获知到以A为根节点的调用关系树，就可以获知具体是需要对哪些方法进行分析。

而在具体实现时，agent模块是可以获取到方法之间的调用关系信息的。具体的，agent模块在接收到client模块发送的分析指令后，可以从中提取出入口方法的标识信息（以名称为例），以及该入口方法所属的类的名称，因此，可以首先从目标JVM实例已加载的类中找到该类，并从内存中获取到该类的字节码，接下来就可以采用字节码分析的方式，对该类中的各个方法进行静态的调用关系分析。

其中，所谓静态的调用关系是相对于动态的调用关系而言的。动态的调用关系是指在程序运行过程中各个方法实际被调用时所体现出的关系。而静态的调用关系与具体的程序运行过程无关，即，不运行相关程序的前提下分析出的调用关系。总之，通过静态的调用关系分析，就可以得到以用户提交的入口方法为根节点时，调用关系树的结构，并且可以确定出各个节点上对应的方法，进而再根据用户提交的需要分析的层次深度，就可以获取到从根节点到该层次深度的各层节点对应的方法，将这些方法确定为待分析方法即可。

例如，假设用户提交的待分析目标信息中包括某个Java类的名称以及该类下的某个方法A的名称，则具体进行静态的调用关系分析时，可以首先根据这个Java类和方法A，从目标JVM实例中获取已加载的这个类的字节码，对这些字节码中的内容进行解析。通过分析这个类中该方法A的字节码，可以获得这个方法A中依赖的类和方法列表。再根据这次分析出来的类和方法列表，遍历列表中的每一项进行同样的分析，对每一个类和方法都分析出方法内部的依赖，每一次分析，都能在用户提交的根节点上更深入一层，直到分析层次达到分析指令中指定的分析层次深度，将之前每一层上分析出的方法均确定为待分析方法。

其中，具体在分析字节码时可以使用ASM框架（ASM是一个Java字节码操纵框架，它可以直接以二进制形式动态地生成stub类或其他代理类，或者在装载时动态地修改类），通过实现MethodVisitor类的子类来访问被分析类的字节码，继承MethodVisitor类的visitMethodInsn方法，访问分析代码中对其他类和方法的调用事件。对如下的调用方法的操作：INVOKEDYNAMIC、INVOKEINTERFACE、INVOKESPECIAL、INVOKESTATIC、INVOKEVIRTUAL进行过滤，并把这些操作码的两个操作数：类名和方法名，记录下来，最终达到静态的调用关系分析的目的。

需要说明的是，在实际应用中，一个方法作为根节点时，其调用关系树的各个层次上可能均包括多个节点，用户可能确实是需要对其中前N层节点进行分析，但是可能并不是前N层的所有节点都需要关注，也即可能只需要关注前N层节点中的一部分。此时，如果这一部分节点之间能够体现出一些共性，也可以允许用户通过指定这些共性来进一步限制待分析方法的范围。这样可以使得进行字节码增强的范围进一步缩小。例如，用户只需要对前N层节点中某个包中的方法进行关注，则可以在client模块的用户界面中输入入口方法的名称、需要关注的层次深度N的同时，还输入该需要关注的包的名称；这样，agent模块在通过字节码分析获知待分析方法时，在分析出各层上的方法之后，还需要判断各个方法的路径中是否包含该目标包的名称，如果包含，则作为待分析方法，后续会进行字节码增强，否则，不会作为待分析方法，后续也不会再对其进行字节码增强。

例如，假设用户在client模块提供的命令行中输入如下的命令：

sudo -u admin -H triton -E mCallTree 29375com.taobao.mitem.sc.service.impl.ScItemMapServiceImplgetItemMapByScItemId5^com\.taobao\..*$

其中，mCallTree指定分析的类型为代码调用时间树，29375为待分析的进程id，com.taobao.mitem.sc.service.impl.ScItemMapServiceImpl为待分析的java类名，getItemMapByScItemId为待分析的java方法名，5是需要分析的层次深度，也即表示需要分析getItemMapByScItemId方法内部调用5层次以内的方法调用，^com\.taobao\..*$是一个正则表达式，指示选定的包名，也即只需要对路径中包含有该包名的方法进行分析。

总之，在具体实现时，各个待分析方法的名称要么是由用户直接输入的，要么可以由agent模块通过字节码分析获知。在获知了需要对哪些方法进行分析之后，agent模块就可以在已加载的类中找到各个方法的字节码，进行字节码增强。其中，具体进行字节码增强时可以采用与已有技术中相同的方式来实现。例如，agent模块根据字节码分析得到待分析方法的调用关系树后，接着就可以针对调用路径列表中的所有方法进行字节码增强。在这些类的这些方法都增加下面的逻辑：在方法开头处记录当前时间并设置当前时间和当前方法名到指定位置（例如，当前线程的缓存），在方法返回处记录当前时间并设置当前时间和当前方法名到该指定位置。总之，通过字节码增强，可以达到与手动地在待分析方法的开头及结尾处插入代码相同的效果，即可以获取到待分析方法被调用时以及返回时的时间，供后续的分析使用。也就是说，对应每个待分析方法而言，都会成对地记录下两个时间点，这两个时间点之间的时间差即可作为该待分析方法在运行时所消耗的时间长度。

需要说明的是，在待分析进程运行的过程中，实际上由具体的线程进行具体的方法调用操作，其中，线程对应具体的业务逻辑。换言之，一个待分析进程中可能需要实现多个业务逻辑，每个业务逻辑需要通过各自的线程来实现，每个线程在执行具体的业务逻辑时，都可能需要调用具体的方法。当然，对于相互之间存在依赖关系的方法而言，会在同一个线程中被调用。例如，线程I调用了方法A，其中方法A依赖方法B，方法B还依赖方法C，则在线程I中，方法A、B、C都会被调用。因此，对于前述对某调用关系树下指定层次深度的方法进行分析的情况下，如果该调用关系树的根节点上的入口方法在某线程中被调用，则该调用关系树上其他节点的方法也会在该线程中被调用。各个待分析方法被调用及返回时，都可以将记录下的调用时间以及返回时间记录到该线程缓存中。当然，由于一次调用过程中会涉及到多个待分析方法，为了避免混淆，在记录时间点信息的同时，还需要记录下对应的待分析方法的名称等标识信息，这样才可以区分出各个待分析方法分别在何时被调用、何时返回。

以上提到了“一次调用过程”的概念，该概念在本申请实施例中主要是指对于入口方法的一次调用过程。也即对于一个入口方法而言，从该方法被调用，到该方法返回，就相当于经历了一次调用过程。当然，根据前文所述的调用关系树中各个方法之间的关系可知，在该入口方法返回之前还有其他的待分析方法被调用之后又返回。也就是说，入口方法的一次调用过程中可能会涉及到对其他待分析方法的一次或多次调用，但无论是入口方法还是其他待分析方法，在每次调用时都可以记录下被调用时间及返回时间。

相应的，agent模块可以识别入口方法的调用和返回，以此判断一次调用过程是否结束，如果是，则触发agent的算法程序收集和分析调用时间数据。具体进行判断时，可以通过线程缓存中维护的当前线程中最早被调用并输出调用时间的方法的标识来实现的。也即，在线程缓存中出现第一个方法标识及其对应的调用时间信息时，就可以将该方法确定为入口方法；之后，每次一个方法返回时，都可以判断当前返回的方法是否为这个入口方法，如果是则说明一次从根节点开始的调用过程已经结束，agent模块就可以收集线程缓存中的数据进行计算和整理，将整理后的数据返回给client模块之后，可以清空线程缓存。

需要说明的是，在本申请实施例中，在向用户展示性能消耗分析结果时，是分别对每次调用过程中获取到的分析结果进行展现，也就是说，在一个线程中，某方法可能会被调用多次，但是在本申请实施例中，每调用一次，都可以展现出这次调用过程中各个待分析方法的执行耗时等信息，而不会对同一方法在不同调用过程中的耗时进行累加。

另外需要说明的是，在本申请实施例中，除了可以向用户返回各个待分析方法的执行耗时信息之外，还可以根据返回各个待分析方法之间的调用关系信息，使得用户在获知各个方法在执行中所消耗的时间之外，还可以获知各个方法之间具有怎样的调用关系，为其具体的排查分析可能存在的问题提供了更多的依据。例如，某次分析过程返回的分析结果如图2所示，其中每一行对应一个方法，不仅显示有各个方法的执行耗时，还通过每一行之间的层次体现出方法之间的调用关系。

总之，在本申请实施例中，可以由用户指定需要分析的方法，并仅对这些需要分析的方法进行自动的字节码增强，以便能够在需要分析的方法被调用的过程中，获取到方法执行所耗费的时间，进而为排查和分析程序中可能存在的问题提供分析依据。在该方法中，不仅可以避免用户手动插入代码的操作过程，而且还可以控制进行字节码增强的范围，降低对实际的业务程序运行造成的影响，也避免了不必要的系统开销。

综上所述，从前述的agent模块角度而言，本申请实施例首先提供了一种获取程序性能消耗信息的方法，参见图3，该方法可以包括：

S301：接收携带有待分析目标信息的分析指令，所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

S302：根据所述待分析目标信息，确定待分析方法；

S303：在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

S304：根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果。

在计算得到性能消耗分析结果之后可以保存到所述指定位置，之后可以从所述指定位置读取所述待分析方法的性能消耗分析结果并返回。

其中，在一次分析需求中，待分析方法可能是一个或多个，用户输入的待分析目标信息中，待分析方法的信息可以直接是各个待分析方法的名称等标识信息，这样，agent模块可以直接根据各个待分析方法的标识信息，确定出需要分析的是哪些方法。

其中，如果各个待分析方法根据调用关系可组成调用关系树，则用户在输入待分析方法的信息时，可以仅输入入口方法的标识信息，以及所需分析的层次深度；其中，入口方法就是调用关系树的根节点对应的待分析方法；这样，agent模块具体在确定待分析方法时，可以首先在待分析进程加载的类中查找入口方法对应的类的字节码；然后基于字节码进行静态的调用层次分析，确定从入口方法开始每一层上的方法分别依赖的方法及其对应的类，直到分析到所述层次深度；然后，根据各层上确定出的方法确定待分析方法。

其中，具体在根据各层上确定出的方法确定待分析方法时，可以直接将各个层上确定出的方法全部确定为所述待分析方法。

或者用户在输入待分析目标信息时，还可以对目标包的名称进行限制，此时，具体在根据各层上确定出的方法确定待分析方法时，可以将各个层上确定出的所述方法中，路径中包含所述目标包的名称信息的方法确定为所述待分析方法。这样可以进一步减少字节码增强的操作范围。

在本申请实施例中，可以在每完成一次调用过程之后，对此次调用过程中涉及到的各个待分析方法的性能消耗情况进行计算统计，因此，agent模块还需要能够判断出是否完成一次调用过程。具体实现时，可以在每次有待分析方法的返回时间被记录到所述指定位置时，判断该返回的方法是否为所述入口方法；如果是，则确定一次调用过程结束，并对此次调用过程中涉及的各个待分析方法的性能消耗分析结果进行计算。

具体在从指定位置读取待分析方法的性能消耗分析结果并返回时，可以是从所述指定位置读取所述待分析方法分别在每次调用过程中的性能消耗分析结果并返回。也即，最终返回给用户的是每次调用过程中各个方法在执行时耗费的时间。这样可以更好的为排查分析程序问题提供依据。

另外，从client模块的角度，本申请实施例还提供了一种获取程序性能消耗信息的方法，参见图4，该方法可以包括：

S401：接收用户提交的待分析目标信息；所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

S402：向指定端口发送携带有所述待分析目标信息的分析指令；

S403：触发所述待分析进程对应的Java虚拟机加载指定的代理模块（其中，可以通过attach的方式连接到待分析进程对应的JVM，并通知该JVM加载指定的代理模块），以便通过所述代理模块执行以下步骤：通过创建ServerSocket类监听所述指定端口；通过所述指定端口监听到所述分析指令后，根据所述待分析目标信息，确定待分析方法；在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果，并保存到所述指定位置；从所述指定位置读取所述待分析方法的性能消耗分析结果并返回；

S404：接收到所述代理模块返回的性能消耗分析结果之后进行展现。

与本申请实施例提供的前述agent模块角度的获取程序性能消耗信息的方法相对应，本申请实施例还提供了一种获取程序性能消耗信息的装置，参见图5，该装置可以包括：

指令接收单元501，用于接收携带有待分析目标信息的分析指令，所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

待分析方法确定单元502，用于根据所述待分析目标信息，确定待分析方法；

字节码增强单元503，用于在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

计算单元504，用于根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果。

其中，在一次分析需求中，待分析方法可能是一个或多个，用户输入的待分析目标信息中，待分析方法的信息可以直接是各个待分析方法的名称等标识信息，这样，agent模块可以直接根据各个待分析方法的标识信息，确定出需要分析的是哪些方法。

其中，如果各个待分析方法根据调用关系可组成调用关系树，则用户在输入待分析方法的信息时，可以仅输入入口方法的标识信息，以及所需分析的层次深度；其中，入口方法就是调用关系树的根节点对应的待分析方法；这样，agent模块具体在确定待分析方法时，可以首先在待分析进程加载的类中查找入口方法对应的类的字节码；然后基于字节码进行静态的调用层次分析，确定从入口方法开始每一层上的方法分别依赖的方法及其对应的类，直到分析到所述层次深度；然后，根据各层上确定出的方法确定待分析方法。

其中，具体在根据各层上确定出的方法确定待分析方法时，可以直接将各个层上确定出的方法全部确定为所述待分析方法。

或者用户在输入待分析目标信息时，还可以对目标包的名称进行限制，此时，具体在根据各层上确定出的方法确定待分析方法时，可以将各个层上确定出的所述方法中，路径中包含所述目标包的名称信息的方法确定为所述待分析方法。这样可以进一步减少字节码增强的操作范围。

在本申请实施例中，可以在每完成一次调用过程之后，对此次调用过程中涉及到的各个待分析方法的性能消耗情况进行计算统计，因此，agent模块还需要能够判断出是否完成一次调用过程。具体实现时，可以在每次有待分析方法的返回时间被记录到所述指定位置时，判断该返回的方法是否为所述入口方法；如果是，则确定一次调用过程结束，并对此次调用过程中涉及的各个待分析方法的性能消耗分析结果进行计算。

具体在从指定位置读取待分析方法的性能消耗分析结果并返回时，可以是从所述指定位置读取所述待分析方法分别在每次调用过程中的性能消耗分析结果并返回。也即，最终返回给用户的是每次调用过程中各个方法在执行时耗费的时间。这样可以更好的为排查分析程序问题提供依据

另外，本申请实施例还提供了一种获取程序性能消耗信息的系统，参见图6，该系统可以包括客户端模块601及代理模块602，其中：

所述客户端模块601可以包括：

信息接收单元6011，用于接收用户提交的待分析目标信息；所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

指令发送单元6012，用于向指定端口发送携带有所述待分析目标信息的分析指令；

触发单元6013，用于触发所述待分析进程对应的Java虚拟机加载指定的代理模块；

结果展现单元6014，用于接收到所述代理模块返回的性能消耗分析结果之后进行展现；

所述代理模块602包括：

监听单元6021，用于通过创建Server Socket类监听所述指定端口；

待分析方法确定单元6022，用于通过所述指定端口监听到所述分析指令后，根据所述待分析目标信息，确定待分析方法；

字节码增强单元6023，用于在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

计算单元6024，用于根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果，并保存到所述指定位置；

返回单元6025，用于从所述指定位置读取所述待分析方法的性能消耗分析结果并返回。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的获取程序性能消耗信息的方法、装置及系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种获取程序性能消耗信息的方法，其特征在于，包括：

接收携带有待分析目标信息的分析指令，所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

根据所述待分析目标信息，确定待分析方法；

在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果。

2.根据权利要求1所述的方法，其特征在于，所述待分析方法为一个或多个，所述待分析方法的信息包括各个待分析方法的标识信息；

所述根据所述待分析目标信息，确定待分析方法包括：

根据所述各个待分析方法的标识信息，确定待分析方法。

3.根据权利要求1所述的方法，其特征在于，所述待分析方法为多个方法，且各个待分析方法根据调用关系可组成调用关系树，所述待分析方法的信息包括入口方法的标识信息，以及所需分析的层次深度；所述入口方法为所述调用关系树的根节点对应的待分析方法；

所述根据所述待分析目标信息，确定待分析方法包括：

在所述待分析进程加载的类中查找所述入口方法对应的类的字节码；

基于字节码进行静态的调用层次分析，确定从所述入口方法开始每一层上的方法分别依赖的方法及其对应的类，直到分析到所述层次深度；

根据各层上确定出的方法确定所述待分析方法。

4.根据权利要求3所述的方法，其特征在于，所述根据各层上确定出的方法确定所述待分析方法包括：

将各个层上确定出的方法全部确定为所述待分析方法。

5.根据权利要求3所述的方法，其特征在于，所述待分析方法的信息还包括目标包的名称信息，所述根据各层上确定出的方法确定所述待分析方法包括：

将各个层上确定出的所述方法中，路径中包含所述目标包的名称信息的方法确定为所述待分析方法。

6.根据权利要求3所述的方法，其特征在于，所述根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果，包括：

每次有待分析方法的返回时间被记录到所述指定位置时，判断该返回的方法是否为所述入口方法；

如果是，则确定一次调用过程结束，并对此次调用过程中涉及的各个待分析方法的性能消耗分析结果进行计算。

7.根据权利要求1至6任一项所述的方法，其特征在于，还包括：

从所述指定位置读取所述待分析方法分别在每次调用过程中的性能消耗分析结果并返回。

8.一种获取程序性能消耗信息的方法，其特征在于，包括：

接收用户提交的待分析目标信息；所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

向指定端口发送携带有所述待分析目标信息的分析指令；

触发所述待分析进程对应的Java虚拟机加载指定的代理模块，以便通过所述代理模块执行以下步骤：通过创建Server Socket类监听所述指定端口；通过所述指定端口监听到所述分析指令后，根据所述待分析目标信息，确定待分析方法；在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果，并保存到所述指定位置；从所述指定位置读取所述待分析方法的性能消耗分析结果并返回；

接收到所述代理模块返回的性能消耗分析结果之后进行展现。

9.一种获取程序性能消耗信息的装置，其特征在于，包括：

指令接收单元，用于接收携带有待分析目标信息的分析指令，所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

待分析方法确定单元，用于根据所述待分析目标信息，确定待分析方法；

字节码增强单元，用于在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

计算单元，用于根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果。

10.一种获取程序性能消耗信息的系统，其特征在于，包括客户端模块及代理模块，其中：

所述客户端模块包括：

信息接收单元，用于接收用户提交的待分析目标信息；所述待分析目标信息包括待分析进程、待分析方法以及所述待分析方法所属的类的信息；

指令发送单元，用于向指定端口发送携带有所述待分析目标信息的分析指令；

触发单元，用于触发所述待分析进程对应的Java虚拟机加载指定的代理模块；

结果展现单元，用于接收到所述代理模块返回的性能消耗分析结果之后进行展现；

所述代理模块包括：

监听单元，用于通过创建Server Socket类监听所述指定端口；

待分析方法确定单元，用于通过所述指定端口监听到所述分析指令后，根据所述待分析目标信息，确定待分析方法；

字节码增强单元，用于在所述待分析进程已加载的类中查找待分析方法的字节码，通过字节码操纵框架对所述待分析方法进行字节码增强，以便在待分析方法开始被调用时记录方法开始时间，将方法开始时间及方法标识信息保存到指定位置，在待分析方法返回时记录方法返回时间，将方法返回时间及方法标识信息保存到所述指定位置；

计算单元，用于根据所述指定位置记录的信息，计算每次调用过程中涉及的各个待分析方法的性能消耗分析结果，并保存到所述指定位置；

返回单元，用于从所述指定位置读取所述待分析方法的性能消耗分析结果并返回。