CN106708710A - 用于识别线程卡顿的方法及装置 - Google Patents

Abstract

本申请提供了一种用于识别线程卡顿的方法及装置，其中，所述方法包括：监控线程与被监控线程通讯；判断预设的特定时长范围内是否接收到所述被监控线程针对所述通讯返回的响应；若特定时长范围内未接收到所述被监控线程针对所述通讯返回的响应，则确定所述被监控线程当前处于卡顿状态。本申请实现了程序自身识别处于卡顿状态的线程，降低识别成本且适用范围更广。

Description

用于识别线程卡顿的方法及装置

技术领域

本申请涉及计算机领域，尤其涉及一种用于识别线程卡顿的方法及装置。

背景技术

线程是程序执行流的最小单元，是进程中的一个实体，是被系统独立调度和分派的基本单位。线程包括就绪、卡顿(阻塞)和运行三种基本状态。就绪状态是指线程具备运行的所有条件，逻辑上可以运行，在等待处理机；运行状态是指线程占有处理机正在运行；卡顿状态是指线程在等待一个事件(如某个信号量)，逻辑上不可执行。线程处于卡顿状态将直接影响整个程序的运行效果，因此需识别出处于卡顿状态的线程，以便找出使线程处于卡顿状态的原因，从而解决卡顿问题。

目前，识别线程卡顿的方法为：通过专门工具度量的方式来识别。所述专门工具例如，iOS(苹果公司开发的移动操作系统)平台中集成在XCode(一种开发工具)中的instrument。该instrument通过度量线程用时/CPU耗时等来发现处于卡顿状态的线程，以及可能造成线程卡顿的代码段。使用instrument工具识别线程卡顿时，需要将安装有instrument工具的Mac电脑与安装程序的设备连接才可进行应用程序的线程卡顿识别。也就是，使用专门工具识别线程卡顿状态的方式需要在特定的开发环境或软件环境下才能执行，因此，现有技术不适用于大规模的收集或者更加灵活的识别程序执行过程中线程的卡顿，并且，针对每一开发环境或软件环境设计一款专门工具来识别线程卡顿，其成本较高。

因此，有必要发明一种新的适用范围更广的用于识别线程卡顿的方法，在降低成本的同时有效识别线程的卡顿现象。

发明内容

本申请解决的技术问题之一是提供一种用于识别线程卡顿的方法及装置，实现了程序自身识别处于卡顿状态的线程，降低识别成本且适用范围更广。

根据本申请一方面的一个实施例，提供了一种用于识别线程卡顿的方法，包括：

监控线程与被监控线程通讯；

判断预设的特定时长范围内是否接收到所述被监控线程针对所述通讯返回的响应；

若未接收到所述被监控线程针对所述通讯返回的响应，则确定所述被监控线程当前处于卡顿状态。

根据本申请另一方面的一个实施例，提供了一种终端，所述终端包括：监控线程运行单元和被监控线程运行单元；

所述监控线程运行单元包括：通讯单元，判断单元和识别单元；

所述通讯单元，用于与被监控线程运行单元通讯；

所述判断单元，用于判断预设的特定时长范围内是否接收到所述被监控线程运行单元针对所述通讯返回的响应；

所述识别单元，用于在所述判断单元判断在特定时长范围内未接收到所述被监控线程运行单元针对所述通讯返回的响应情况下，确定所述被监控线程当前处于卡顿状态。

本申请实施例通过监控线程与被监控线程通讯，根据接收被监控线程针对所述通讯返回的响应的情况来识别被监控线程是否卡顿。实现了程序自身识别处于卡顿状态的线程，适用于各种程序，其适用范围更广。由于无需依赖专门的识别(分析)工具，降低了识别成本，使得识别操作简单、易于实现。

本领域普通技术人员将了解，虽然下面的详细说明将参考图示实施例、附图进行，但本申请并不仅限于这些实施例。而是，本申请的范围是广泛的，且意在仅通过后附的权利要求限定本申请的范围。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是根据本申请一个实施例的用于识别线程卡顿的方法的流程图。

图2是根据本申请一个实施例的用于识别线程卡顿的装置的结构示意图。

本领域普通技术人员将了解，虽然下面的详细说明将参考图示实施例、附图进行，但本申请并不仅限于这些实施例。而是，本申请的范围是广泛的，且意在仅通过后附的权利要求限定本申请的范围。

具体实施方式

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

所述计算机设备包括用户设备与网络设备。其中，所述用户设备包括但不限于电脑、智能手机、PDA等；所述网络设备包括但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(CloudComputing)的由大量计算机或网络服务器构成的云，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个超级虚拟计算机。其中，所述计算机设备可单独运行来实现本申请，也可接入网络并通过与网络中的其他计算机设备的交互操作来实现本申请。其中，所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、VPN网络等。

需要说明的是，所述用户设备、网络设备和网络等仅为举例，其他现有的或今后可能出现的计算机设备或网络如可适用于本申请，也应包含在本申请保护范围以内，并以引用方式包含于此。

后面所讨论的方法(其中一些通过流程图示出)可以通过硬件、软件、固件、中间件、微代码、硬件描述语言或者其任意组合来实施。当用软件、固件、中间件或微代码来实施时，用以实施必要任务的程序代码或代码段可以被存储在机器或计算机可读介质(比如存储介质)中。(一个或多个)处理器可以实施必要的任务。

这里所公开的具体结构和功能细节仅仅是代表性的，并且是用于描述本申请的示例性实施例的目的。但是本申请可以通过许多替换形式来具体实现，并且不应当被解释成仅仅受限于这里所阐述的实施例。

应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元，但是这些单元不应当受这些术语限制。使用这些术语仅仅是为了将一个单元与另一个单元进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一单元可以被称为第二单元，并且类似地第二单元可以被称为第一单元。这里所使用的术语“和/或”包括其中一个或更多所列出的相关联项目的任意和所有组合。

应当理解的是，当一个单元被称为“连接”或“耦合”到另一单元时，其可以直接连接或耦合到所述另一单元，或者可以存在中间单元。与此相对，当一个单元被称为“直接连接”或“直接耦合”到另一单元时，则不存在中间单元。应当按照类似的方式来解释被用于描述单元之间的关系的其他词语(例如“处于...之间”相比于“直接处于...之间”，“与...邻近”相比于“与...直接邻近”等等)。

这里所使用的术语仅仅是为了描述具体实施例而不意图限制示例性实施例。除非上下文明确地另有所指，否则这里所使用的单数形式“一个”、“一项”还意图包括复数。还应当理解的是，这里所使用的术语“包括”和/或“包含”规定所陈述的特征、整数、步骤、操作、单元和/或组件的存在，而不排除存在或添加一个或更多其他特征、整数、步骤、操作、单元、组件和/或其组合。

还应当提到的是，在一些替换实现方式中，所提到的功能/动作可以按照不同于附图中标示的顺序发生。举例来说，取决于所涉及的功能/动作，相继示出的两幅图实际上可以基本上同时执行或者有时可以按照相反的顺序来执行。

下面结合附图对本申请的技术方案作进一步详细描述。

图1是根据本申请一个实施例的用于识别线程卡顿的方法的流程图，该方法用于识别程序中处于卡顿状态的线程，以便于后续有针对性的优化程序。该方法主要包括如下步骤：

S110、监控线程与被监控线程通讯；

S120、判断预设的特定时长范围内是否接收到所述被监控线程针对所述通讯返回的响应；

S130、若特定时长范围内未接收到所述被监控线程针对所述通讯返回的响应，则确定所述被监控线程当前处于卡顿状态。

S140、若特定时长范围内接收到所述被监控线程针对所述通讯返回的响应，则确定所述被监控线程当前未处于卡顿状态。

下面对上述各步骤做进一步详细介绍。

首先，在介绍各步骤前，先介绍程序、进程与线程的关系。

进程(Process)是程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。

线程是进程中的一个实体，是被系统独立调度和分派的基本单位，线程自己不拥有系统资源，只拥有一点儿在运行中必不可少的资源，但它可与同属一个进程的其它线程共享进程所拥有的全部资源。同一进程中的多个线程之间可以并发执行。线程是程序执行流的最小单元。一个标准的线程由线程ID，当前指令指针(PC)，寄存器集合和线程栈组成。一个线程可以创建和撤消另一个线程。每一个程序都至少有一个线程，若程序只有一个线程，那该线程就是程序本身。

步骤S110中所述被监控线程为需要识别是否处于卡顿状态的所有线程的统称，该被监控线程可以为任意程序的线程，且其可以为主线程也可以为子线程。例如被监控线程可以为UI(User Interface，用户界面)线程。在iOS平台的应用程序开发中，对UI的操作只能在主线程中进行，因此该场景下主线程即为被监控的UI线程。

所述的监控线程是为识别被监控线程是否处于卡顿状态而建立的线程。该监控线程可以在被监控线程执行前或执行过程中建立。且该监控线程可以由被监控线程建立，也可以由第三方建立，本实施例对此不做具体限制。

步骤S110中所述的监控线程与被监控线程通讯的操作可以按照预设时间间隔来执行，所述预设时间间隔可根据需要来设置及调整。例如，每间隔1s监控线程与被监控线程通讯。也就是本申请实施例中的监控线程可以按照预设时间间隔来主动与被监控线程通讯，以触发被监控线程针对所述通讯返回响应，从而根据被监控线程针对所述通讯返回的响应来识别被监控线程的状态。

所述监控线程与被监控线程通讯包括：监控线程向被监控线程发送需被监控线程针对所述通讯返回响应的消息。也就是监控线程向被监控线程发送一消息，需要该被监控线程在收到该消息后返回响应消息，从而可以根据该响应消息识别该被监控线程是否卡顿。该监控线程发送给被监控线程的消息内容本申请实施例不做具体限制，其可以为被监控线程可执行的一个命令，或触发被监控线程针对所述通讯返回响应的其他消息。例如，针对被监控线程为iOS平台的UI线程的情况，可以在监控线程中启动一个函数，要求该函数在被监控线程里面执行，并返回响应。

另外，需要说明的是，一个监控线程可以用于监控一个或多个被监控线程。针对多个被监控线程，其发送的需要返回响应的消息可以相同也可以不同。也就是可以针对多个被监控线程发送相同的消息，以触发该多个被监控线程针对所述消息返回响应。也可以针对该多个被监控线程发送不同的消息，以触发该多个被监控线程针对所述消息返回响应。

步骤S120中所述的特定时长可根据需要设置，在被监控线程正常(非卡顿状态)执行状态下，监控线程会在所述特定时长内接收被监控线程返回的响应。例如可设置为0.5s。其中，被监控线程的响应类型本申请实施例不做具体限制，在监控线程发送给被监控线程的消息为该被监控线程可执行的命令的情况下，该响应可以为被监控线程执行该命令的执行结果，当然本申请实施例并不局限于此。

其中，判断预设的特定时长范围内是否接收到所述被监控线程针对所述通讯返回的响应的方法包括如下任一种：

其一：从监控线程发送所述需被监控线程针对所述通讯返回响应的消息开始计时，判断特定时长范围内是否接收到被监控线程针对所述通讯返回的响应。

可以在监控线程发送所述需被监控线程针对所述通讯返回响应的消息后，启动计时器并监听被监控线程是否针对所述通讯返回响应，若在特定时长范围内接收到被监控线程针对所述通讯返回的响应，则停止计时，计时器清零；若在特定时长范围内未接收到被监控线程针对所述通讯返回的响应，则确定所述被监控线程当前处于卡顿状态；也就是在达到特定时长而未接收到被监控线程针对所述通讯返回的响应情况下，停止计时，计时器清零。例如，在0.5s内未接收到被监控线程针对所述消息返回的响应，则停止计时，不论在0.5s后是否接收到被监控线程针对所述消息返回的响应均确定所述被监控线程当前处于卡顿状态。

其二：记录监控线程发送所述需被监控线程针对所述通讯返回响应的消息的时间，以及接收被监控线程针对所述通讯返回的响应的时间，计算接收被监控线程针对所述通讯返回的响应的时间距离监控线程发送所述需被监控线程针对所述通讯返回响应的消息的时间的时长是否超过特定时长范围。

步骤S130为在特定时长范围内未接收到所述被监控线程针对所述通讯返回的响应情况下，确定所述被监控线程当前处于卡顿状态。由于所述特定时长为被监控线程正常执行状态下，监控线程应该接收被监控线程针对所述通讯返回响应的时长，若在该特定时长范围内未接收被监控线程针对所述通讯返回的响应，则说明被监控线程当前执行速度缓慢，处于卡顿状态。相反，若在该特定时长范围内接收到被监控线程针对所述通讯返回的响应，则确定被监控线程当前未处于卡顿状态。

识别出处于卡顿状态的线程的主要目的在于可以有针对性的对程序进行优化。因此，本申请实施例在确定被监控线程当前处于卡顿状态情况下，还可包括如下操作：

一种实施例为：获取所述被监控线程的当前线程栈；保存或上传获取的所述当前线程栈给服务器。

另一种实施例为：获取所述被监控线程所在进程中所有线程的当前线程栈；保存或上传获取的所述当前线程栈给服务器。该实施例是考虑到在同一个进程中的各个线程之间经常会有交互，获取处于卡顿状态的线程所在进程中所有线程的当前线程栈，能够更加方便的了解当前进程的运行情况，以便对后续程序优化过程定位问题提供更加丰富的信息。

上传获取的所述当前线程栈给服务器时，可上传被监控线程与获取的所述被监控线程的当前线程栈的对应关系以及获取的被监控线程所在进程中所有线程与各自的当前线程栈的对应关系给服务器。由于每个线程都有对应的线程ID，因此，在获取被监控线程的当前线程栈时，记录该当前线程栈对应的线程的线程ID，并将该线程ID与当前线程栈的对应关系上传给服务器，以便服务器可以准确快速的识别处于卡顿状态的线程的当前线程栈，从而有针对性的进行程序优化。

其中，获取被监控线程的当前线程栈的步骤可采用如下方式实现，例如根据各个平台上提供的API(Application Programming Interface，应用程序编程接口)来获取，本申请实施例对此不做具体限制。

步骤S140是在特定时长范围内接收到所述被监控线程针对所述通讯返回的响应情况下确定所述被监控线程当前未处于卡顿状态。开始下一轮识别操作，例如，在间隔固定时间后再次与该被监控线程通讯。

本申请实施例通过监控线程与被监控线程通讯，根据接收被监控线程针对所述通讯返回响应的情况来识别被监控线程是否卡顿。实现了程序自身识别处于卡顿状态的线程，适用于各种程序，其适用范围更广。由于无需依赖专门的识别(分析)工具，降低了识别成本，使得识别操作简单、易于实现。

本申请实施例还提供一种与上述用于识别线程卡顿的方法对应的终端，该终端结构示意图如图2中所示，该终端包括：监控线程运行单元21和被监控线程运行单元22；所述监控线程运行单元21包括：通讯单元210，判断单元211和识别单元212；

所述通讯单元210，用于与被监控线程运行单元22通讯；

判断单元211，用于判断预设的特定时长范围内是否接收到所述被监控线程运行单元22针对所述通讯返回的响应；所述的特定时长可根据需要设置，在被监控线程运行单元22正常(非卡顿状态)执行状态下，监控线程运行单元21会在所述特定时长内接收被监控线程运行单元22针对所述通讯返回的响应。例如所述特定时长可设置为0.5s。其中，被监控线程运行单元22的响应类型本申请实施例不做具体限制，在监控线程运行单元21发送给被监控线程运行单元22的消息为该被监控线程运行单元22可执行的命令的情况下，该响应可以为被监控线程运行单元22执行该命令的执行结果，当然本申请实施例并不局限于此。该判断单元211判断预设的特定时长范围内是否接收到所述被监控线程运行单元22针对所述通讯返回的响应的方法同上面实施例中所述，此处不再赘述。

识别单元212，用于在所述判断单元211判断在特定时长范围内未接收到所述被监控线程运行单元22针对所述通讯返回的响应情况下，确定所述被监控线程运行单元22当前处于卡顿状态。

所述被监控线程运行单元22为需要识别是否处于卡顿状态的所有线程的统称，该被监控线程运行单元22可以为任意程序的线程，且其可以为主线程也可以为子线程。例如被监控线程运行单元22可以为UI(UserInterface，用户界面)线程。在iOS平台的应用程序开发中，对UI的操作只能在主线程中进行，因此该场景下主线程即为被监控的UI线程。

所述的监控线程运行单元21是为识别被监控线程运行单元22是否处于卡顿状态而建立的线程。该监控线程运行单元21可以在被监控线程运行单元22执行前或执行过程中建立。且该监控线程运行单元21可以由被监控线程运行单元22建立，也可以由第三方建立，本实施例对此不做具体限制。

所述通讯单元210可以被配置为：按照预设时间间隔与被监控线程运行单元22通讯。该预设时间间隔可根据需要来设置及调整。例如，每间隔1s与被监控线程运行单元22通讯。也就是本申请实施例中的通讯单元210可以按照预设时间间隔来主动与被监控线程运行单元22通讯，以触发被监控线程运行单元22针对所述通讯返回响应，从而根据被监控线程运行单元22针对所述通讯返回的响应来识别被监控线程运行单元22的状态。

所述通讯单元210被配置为：向被监控线程运行单元22发送需被监控线程运行单元22针对所述通讯返回响应的消息。也就是向被监控线程运行单元22发送一消息，需要该被监控线程运行单元22在收到该消息后返回响应，从而可以根据该响应识别该被监控线程运行单元22是否卡顿。该发送给被监控线程运行单元22的消息内容本申请实施例不做具体限制，其可以为被监控线程运行单元22可执行的一个命令，或触发被监控线程运行单元22针对所述通讯返回响应的其他消息。例如，针对被监控线程运行单元22为iOS平台的UI线程的情况，可以在监控线程运行单元21中启动一个函数，要求该函数在被监控线程运行单元22里面执行，并返回响应。

另外，需要说明的是，一个监控线程运行单元21可以用于监控一个或多个被监控线程运行单元22。针对多个被监控线程运行单元22，其发送的需要返回响应的消息可以相同也可以不同。也就是可以针对多个被监控线程运行单元22发送相同的消息，以触发该多个被监控线程运行单元22针对所述通讯返回响应。也可以针对该多个被监控线程运行单元22发送不同的消息，以触发该多个被监控线程运行单元22针对所述通讯返回响应。

由于所述特定时长为被监控线程运行单元22正常执行状态下，监控线程运行单元21应该接收被监控线程运行单元22针对所述通讯返回响应的时长，若在该特定时长范围内未接收被监控线程运行单元22针对所述通讯返回的响应，则说明被监控线程运行单元22当前执行速度缓慢，处于卡顿状态。相反，若在该特定时长范围内接收到被监控线程运行单元22针对所述通讯返回的响应，则确定被监控线程运行单元22当前未处于卡顿状态。

识别出处于卡顿状态的被监控线程运行单元22的主要目的在于可以有针对性的对程序进行优化。因此，本申请实施例所述装置还包括：

获取单元213，用于获取所述被监控线程运行单元22的当前线程栈；

上传单元214，用于上传获取的所述当前线程栈给服务器。

另一种实施例所述装置还包括：

获取单元215，用于获取所述被监控线程运行单元22所在进程中所有线程的当前线程栈；

上传单元216，用于上传获取的所述当前线程栈给服务器。

其中，所述上传单元216被配置为：上传获取的所述当前线程栈与线程的对应关系给服务器。也就是该上传单元216上传获取的所述当前线程栈给服务器时，可上传被监控线程运行单元22与获取的所述被监控线程运行单元的当前线程栈的对应关系以及获取的被监控线程运行单元22所在进程中所有线程与各自的当前线程栈的对应关系给服务器。由于每个线程都有对应的线程ID，因此，在获取单元213获取被监控线程运行单元的当前线程栈时，记录该当前线程栈对应的线程的线程ID，并由上传单元216将该线程ID与当前线程栈的对应关系上传给服务器，以便服务器可以准确快速的识别处于卡顿状态的线程的当前线程栈，从而有针对性的进行程序优化。

本申请实施例通过监控线程与被监控线程通讯，根据接收被监控线程针对所述通讯返回响应的情况来识别被监控线程是否卡顿。实现了程序自身识别处于卡顿状态的线程，适用于各种程序，其适用范围更广。由于无需依赖专门的识别(分析)工具，降低了识别成本，使得识别操作简单、易于实现。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (12)

1.一种用于识别线程卡顿的方法，其特征在于，包括：

监控线程与被监控线程通讯；

判断预设的特定时长范围内是否接收到所述被监控线程针对所述通讯返回的响应；

若特定时长范围内未接收到所述被监控线程针对所述通讯返回的响应，则确定所述被监控线程当前处于卡顿状态。

2.如权利要求1所述的方法，其特征在于，监控线程与被监控线程通讯包括：

监控线程按预设时间间隔与被监控线程通讯。

3.如权利要求1所述的方法，其特征在于，所述监控线程与被监控线程通讯包括：

监控线程向被监控线程发送需被监控线程针对所述通讯返回响应的消息。

4.如权利要求1所述的方法，其特征在于，确定所述被监控线程当前处于卡顿状态后，所述方法还包括：

获取所述被监控线程的当前线程栈；

上传获取的所述当前线程栈给服务器。

5.如权利要求1所述的方法，其特征在于，确定所述被监控线程当前处于卡顿状态后，所述方法还包括：

获取所述被监控线程所在进程中所有线程的当前线程栈；

上传获取的所述当前线程栈给服务器。

6.如权利要求4或5所述的方法，其特征在于，所述上传获取的所述当前线程栈给服务器包括：

上传获取的所述当前线程栈与线程的对应关系给服务器。

7.一种终端，其特征在于，所述终端包括：监控线程运行单元和被监控线程运行单元；

所述监控线程运行单元包括：通讯单元，判断单元和识别单元；

所述通讯单元，用于与被监控线程运行单元通讯；

所述判断单元，用于判断预设的特定时长范围内是否接收到所述被监控线程运行单元针对所述通讯返回的响应；

所述识别单元，用于在所述判断单元判断在特定时长范围内未接收到所述被监控线程运行单元针对所述通讯返回的响应情况下，确定所述被监控线程当前处于卡顿状态。

8.如权利要求7所述的装置，其特征在于，所述通讯单元被配置为：

按预设时间间隔与被监控线程通讯。

9.如权利要求7所述的装置，其特征在于，所述通讯单元被配置为：

向被监控线程运行单元发送需被监控线程运行单元针对所述通讯返回响应的消息。

10.如权利要求7所述的装置，其特征在于，所述装置还包括：

获取单元，用于获取所述被监控线程运行单元的当前线程栈；

上传单元，用于上传获取的所述当前线程栈给服务器。

11.如权利要求7所述的装置，其特征在于，所述装置还包括：

获取单元，用于获取所述被监控线程运行单元所在进程中所有线程的当前线程栈；

上传单元，用于上传获取的所述当前线程栈给服务器。

12.如权利要求10或11所述的装置，其特征在于，所述上传单元被配置为：

上传获取的所述当前线程栈与线程的对应关系给服务器。