CN107391265A - 用于进程中检测死锁的方法和设备 - Google Patents

Abstract

本申请的目的是提供一种用于进程中检测死锁的方法和设备，通过基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，针对不同的锁采取不同的建边方式避免了误判，基于所述节点及所述节点之间的有向边生成逻辑图；当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图，大大减少了拷贝逻辑图的次数，从而降低了拷贝逻辑图时与正常服务的线程存在的竞争的影响，并判断所述逻辑图是否为有向无环图，若是则确定无死锁情况，否则确定有死锁情况。更加准确的判断死锁情况和缩短检测死锁的时间。

Description

用于进程中检测死锁的方法和设备

技术领域

本申请涉及计算机领域，尤其涉及一种用于进程中检测死锁的技术。

背景技术

随着技术的发展和用户的需求，分布式系统逐渐变的更加复杂化，而且在复杂后还需要修改来实现新的功能，为了提高系统的性能，采用了多线程的方式，因此导致在复杂的逻辑中进行修改后，容易出现死锁的问题。在死锁出现后，调查起来会比较容易，但是有很多场景在平时测试时并不能出现死锁，往往到了线上才出现死锁，就会影响集群的正常服务，导致线上故障。在某些分布式系统中，可以通过paxos来容忍失效转移(FailOver)的节点，可以通过将出现死锁的进程进行重启来规避线上运行过程中遇到死锁而影响服务的问题。

在Linux中已经有了检查是否出现死锁的机制：在启动后会创建一个线程来监测所有的线程，如果有哪个线程处于不可中断的睡眠状态(D状态)超过120s，那么认为线程被夯住(hang)了，会根据配置进行操作，默认情况下只输出日志(log)并不会做其它的事情。而这种检测死锁的方法检查周期长，如果真的出现死锁，也需要经过120s才能判断出现死锁；而且容易误报，如果有线程因为操作而需要超过120s的D状态，那么会被判定为死锁。

为了避免进程(线程)死锁对整个系统造成的重大危害，提高系统的稳定性，需要有一个有效的方法进行死锁的检测，以便及时发现进程(线程)死锁。

发明内容

本申请的目的是提供一种用于进程中检测死锁的方法与设备，以解决如何快速、准确检测进程中检测死锁的问题。

根据本申请的一个方面，提供了一种用于进程中检测死锁的方法，包括：

基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；

当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；

判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

进一步地，基于所述锁的种类及所述锁之间的获取顺序确定对应所述节点之间的有向边包括：

若所述锁为读锁，则判断是否有其他所述执行线程在等待写锁；若是，则建立前一所述锁对应所述节点到所述写锁对应所述节点的有向边；若否，则判断所述执行线程是否已获得所述读锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述读锁对应所述节点的有向边。

根据本申请的另一方面，还提供了一种用于进程中检测死锁的设备，包括：

生成装置，用于基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；

确定装置，用于当所述执行线程有状态为异常时，获取所述逻辑图；

判断装置，用于判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

进一步地，所述生成装置还包括：第三建边单元，用于若所述锁为可重入锁，则判断所述执行线程是否已获得所述可重入锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述可重入锁对应所述节点的有向边。

进一步地，所述生成装置还包括：第四建边单元，用于若所述锁为不可重入锁，则建立前一所述锁对应所述节点到所述不可重入锁对应所述节点的有向边。

此外，本申请还提供了一种用于进程中检测死锁的设备，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；

当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；

判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

与现有技术相比，根据本申请实施例的方法和设备，通过基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，针对不同的锁采取不同的建边方式避免了误判，基于所述节点及所述节点之间的有向边生成逻辑图；接着，当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图，大大减少了拷贝逻辑图的次数，从而降低了拷贝逻辑图时与正常服务的线程存在的竞争的影响，并判断所述逻辑图是否为有向无环图，若是则确定无死锁情况，否则确定有死锁情况，从而更加准确地判断死锁情况和缩短检测死锁的时间。

附图说明

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

图1示出根据本申请一个方面的一种用于进程中检测死锁的方法流程示意图；

图2示出根据本申请一个方面的一个优选实施例的步骤S11的方法流程示意图；

图3示出根据本申请一个方面的一个优选实施例的可重入锁建边的流程示意图；

图4示出根据本申请一个方面的一个优选实施例的不可重入锁建边的流程示意图；

图5示出根据本申请一个方面的一个优选实施例的不同锁建边的流程示意图；

图6示出根据本申请另一个方面的一种用于进程中检测死锁的设备的结构示意图；

图7示出根据本申请另一个方面的一个优选实施例的生成装置的结构示意图。

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

下面结合附图对本申请作进一步详细描述。

图1示出根据本申请一个方面的一种用于进程中检测死锁的方法流程示意图。所述方法包括步骤S11、步骤S12和步骤S13，其中，在步骤S11中，基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；在步骤S12中，当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；在步骤S13中，判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

具体地，在步骤S11中，基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图。

在此，对于多线程的进程中，需要按照执行线程获取锁的顺序进行建立有向边进而构造逻辑图。例如，执行线程A、B、C获取锁时生成对应的节点为节点a、b、c，以节点a、b、c为顶点建边进而生成逻辑图；也可以是执行线程A依次获取锁a、b、c，生成对应的节点a、b、c。需要说明的是，执行线程A代表多线程中的某一线程并不特指，执行线程A获取锁生成对应节点可用a表示也可用b表示，并不只限于线程A只能获取锁a生成节点只能为a，以上举例仅为执行线程获取锁后生成节点的具体描述。对于不同种类的锁，如果采用同一建图方法，则可能在判断是否有死锁时出现误判，因此基于锁的种类及锁之间的获取顺序建立锁对应节点之间的有向边，进而依据所建的有向边生成逻辑图，其中，逻辑图中的顶点为锁对应的节点，有向边为前一锁对应的节点指向当前锁对应的节点所构成的有方向的边，例如，线程D获取了锁d，然后去获取锁e，则建一条有向边：d->e。所述锁的种类包括读写锁和非读写锁，其中，对于读写锁，可以同时获取读锁但是同时只能有一个线程获取写锁，并且没有其他的线程获取读锁。对于非读写锁，可分为可重入锁和不可重入锁，两种锁在同一时刻只能有一个线程获取，对于可重入锁来说，一个线程在获取可重入锁后，在没有释放锁的前提下，还可以再次获取这个锁；不可重入锁表示如果一个线程不能够多次获取同一个锁。

具体地，在步骤S12中，当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图。

在此，优选地，在步骤S12中，包括创建检测线程，利用所述检测线程定期检查所有所述执行线程的状态是否异常，当有所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图。在正常情况下可以采用一个线程定期的检查是否存在死锁，但是由于在检查死锁时，需要对获取锁过程中建立出来的逻辑图，所以不能够这样频繁的拷贝图，因拷贝图时会和正常服务的线程存在竞争关系。为了减少这种影响，采用创建检测线程以先检查所有其他的线程状态是否正常，只有当确定为异常时，才获取建立好的图，然后进行判断是否是死锁。

本领域技术人员应能理解，所述创建检测线程检测执行线程的状态是否异常的方法仅为举例，还可以在前端通过定期请求服务来判断服务是否正常，其他现有的或今后可能出现的检测执行线程的状态是否异常的方法如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

具体地，在步骤S13中，判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

在此，需要说明的是，有向无环图(Directed Acycling Graph，DAG)代表一个有向图无法从某个顶点出发经过若干条边回到该点，对基于节点及节点之间的有向边生成的逻辑图进行遍历，如果同一个节点被遍历两次，则说明所述逻辑图不是有向无环图，存在死锁的情况，否则不存在。如果判断没有死锁，那么将当时的状态输出，有可能是系统中有些操作在特殊情况下处理的时间过长，因此检查死锁的时机选择正确时能够在更短的时间更准确的检测死锁情况。例如，创建检测线程，每隔10s检测所有的执行线程的状态是否异常。与现有技术中用一线程监测所有的线程处于D状态的时间是否超过预设时间相比，本申请的检测线程仅用来判断线程是否出现异常状态，与检测D状态所用的时间相比，极大的缩短了检测时间。

本申请一实施例所述用于检测进程中死锁的方法，针对锁的种类建立有向边进而生成逻辑图，创建检测线程定期检查所有执行线程从而正确选择检测死锁的时机，基于检测线程和逻辑图在更短的时间内更准确的判断死锁情况。

优选地，步骤S11中基于所述锁的种类及所述锁之间的获取顺序确定对应所述节点之间的有向边包括：如图2示出根据本申请一个方面的一个优选实施例的步骤S11的方法流程示意图；所述步骤S11包括步骤S111、步骤S112和步骤S113，其中，在步骤S111中，若所述锁为读锁，则判断是否有其他所述执行线程在等待写锁；若是，则进行步骤S112，建立前一所述锁对应所述节点到所述写锁对应所述节点的有向边；若否，则进行步骤S113，判断所述执行线程是否已获得所述读锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述读锁对应所述节点的有向边。

在此，当系统配置上写锁优先的情况下，一个线程重复获取读锁，而有另外线程要获取写锁时会导致死锁，在建立有向边时选择的方式是首先要判断锁是否为读锁，如果是则判断是否有其它线程在等待写锁，如果有，那么无条件建边，否则判断该线程是否已经获得了该锁，如果获得了，那么无需建边，否则建边。需要说明的是，读写锁具有两种状态：读锁状态和写锁状态，当进程(或线程)获取读写锁进行读操作时读写锁为读锁，当进行写操作时读写锁为写锁，读操作和写操作是互斥的。在一具体实施例中，若执行线程A已获取读写锁lock b以进行读操作，在获取锁lock a后获取读写锁lock b，这时发现执行线程B在等待读写锁lock b以进行写操作，则建立前一所述锁lock a对应节点a到作为写锁lock b对应节点b的有向边：a->b，因为获取锁lock a之前获取过作为读锁的lock b，因此前面已建过有向边b->a，此时，形成一个b->a->b的有向环，进行遍历该有向环时节点b被遍历两次，说明存在死锁，符合系统配置写锁优先的情况下获取读锁时另有线程需获取写锁造成的死锁的实际情况。若执行线程A获取完锁b再次遇到读锁lock b时，没有其他线程在等待写锁，则判断执行线程A是否已获取读锁lock b，若是，则无需建立有向边：b->b，否则建立前一所述锁lock b对应节点b到锁lock b之后获取到的下一读锁对应节点的有向边。

更优选地，在步骤S113中，判断所述执行线程是否已获得所述读锁包括：从所述读锁的记录信息中获取执行线程身份信息；基于执行线程身份信息，确定所述执行线程已获得所述读锁。

在此，锁的记录信息包括获取该锁的执行线程的身份信息id，当某一执行线程获得读锁后需要从锁的记录信息中获取到执行线程id，基于执行线程id确定执行线程已获得了该读锁。例如，从某一读锁lock n的记录信息中可获得获取lock n的执行线程为线程A还是线程B或其他线程，进而判断出该锁是否被同一执行线程多次获取。当建完边后需要更新获取锁的线程id，即更新锁的记录信息。

优选地，所述步骤S11还包括：若所述锁为可重入锁，则判断所述执行线程是否已获得所述可重入锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述可重入锁对应所述节点的有向边。

在此，更优选地，判断所述执行线程是否已获得所述可重入锁包括：从所述可重入锁的记录信息中获取执行线程身份信息；基于执行线程身份信息，确定所述执行线程已获得所述可重入锁。在一优选实施例中，如图3示出根据本申请一个方面的一个优选实施例的可重入锁建边的流程示意图；首先，执行线程A获取锁Lock a后，Lock a的记录信息中会记录获取该锁的执行线程id，记录为线程A；接着，按照获取锁的顺序会有线程获取锁Lock b，当Lock a和Lock b为同一锁时，说明此时的锁为可重入锁，进行判断获取该锁的执行线程是否为线程B，在此，线程B用于代表若干执行线程中除了线程A外的任一线程，不特指某一线程，若判断获取该锁的执行线程为线程B，则说明获取可重入锁的线程不是同一线程，则建立前一锁Lock a到可重入锁Lock b的有向边：a->b；若判断获取该锁的执行线程不是线程B，则说明获取可重入锁Lock b的线程为同一线程，都为线程A，则不需要建立有向边：a->a。最后，更新获取锁Lock b的线程id，即记录获取锁时的线程为线程A还是线程B，当继续获取锁时，以便根据之前的记录信息进行判断该锁是否再次被同一线程获取，以继续往下进行建立有向边进而生成逻辑图，从而达到根据逻辑图进行检测死锁的目的。

优选地，步骤S11还包括：若所述锁为不可重入锁，则建立前一所述锁对应所述节点到所述可重入锁对应所述节点的有向边。

在此，例如，在一优选实施例中，图4示出根据本申请一个方面的一个优选实施例的不可重入锁建边的流程示意图；在多线程的进程中，按照执行线程获取锁的顺序进行建立逻辑图，首先，对于锁Lock a，通过从锁的记录信息中获得获取Lock a的线程id，为线程A，当线程A获取Lock a后，继续去获取锁Lock b，因Lock a为不可重入锁，代表一个线程不能多次获取同一个锁，即线程A再获取锁Lock b对于Lock a来说是不同的锁，则进行建立一条有向边：a->b，最后更新获取锁Lock b的线程id，以便根据之前的记录信息进行判断该锁是否为不可重入锁，若是，则按照上述不可重入锁建边的方法继续往下进行建立有向边进而生成逻辑图，从而达到根据逻辑图进行检测死锁的目的。

优选地，所述步骤S13中判断所述逻辑图是否为有向无环图包括：基于遍历算法对所述逻辑图进行遍历；若至少一个所述遍历路径存在至少一个所述节点被遍历至少两次，则确定所述逻辑图不是有向无环图，否则确定所述逻辑图是有向无环图。

在此，优选地，所述遍历算法包括采用深度优先搜索算法(Depth-First-Search，DFS)和广度优先搜索算法(Breadth-First-Search，BFS)对生成的逻辑图进行遍历，判断所遍历的逻辑图是否为DAG，采用DFS算法时判断的伪代码可用如下方式表示：

需要说明的是，上述伪代码表示对逻辑图中的顶点进行遍历时，如果顶点A被遍历过，则说明顶点A被第二次遍历，返回结果为逻辑图不是DAG图；若A没被遍历，则开始对A进行遍历并标记遍历过A，再根据节点深度进行下一个顶点的遍历，判断下一个顶点是否被遍历过，循环执行以上遍历步骤，直到再次遇到被遍历过的顶点，其中，IF dfs(x)为真代表对所有节点遍历时存在至少一个节点被两次遍历过，则返回结果为逻辑图不是DAG图，若所有节点只遍历过一次，则说明逻辑图为DAG图。而对逻辑图进行DFS遍历进而判断死锁的伪代码可如下表示：

需要说明的是，上述伪代码表示对逻辑图的节点依次进行遍历，当遍历一个节点时，首先判断该节点是否被遍历过，若没有遍历则对该节点进行遍历，其中，IF dfs(A)为真表示遍历节点A并标记遍历过A，再根据节点深度进行下一个节点的遍历，判断下一个节点是否被遍历过，循环执行以上遍历步骤，直到再次遇到被遍历过的节点，返回结果有死锁。

在此，对逻辑图进行DFS遍历进而判断死锁的伪代码是基于判断所遍历的逻辑图是否为DAG进行的，即判断逻辑图是否为DAG从而进行确认是否为死锁，可得出对于死锁必然不是DAG图的推断。

本领域技术人员应能理解，所述遍历算法中的DFS和BFS仅为举例，其他现有的或今后可能出现的遍历算法如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

图5示出根据本申请一个方面的一个优选实施例的不同锁建边的流程示意图；可重入锁、不可重入锁和读写锁的建立有向边的方式不同，如图5示出，若是不可重入锁，则建立前一锁对应的节点到不可重入锁对应节点的有向边。但此方法在建边过程中存在一个问题，如果锁是可重入的，那么这样的建边所生成的逻辑图在判断是否为死锁时有可能会导致误判，所以，对于普通的可重入锁，需要判断执行线程是否已获得可重入锁，若是，则不需要建边，若否，则建立前一锁对应的节点到可重入锁对应所述节点的有向边。而前述两种建边方法不能解决当系统配置上写锁优先的情况下有一个线程重复获取读锁，而有另外线程要获取写锁时而导致的死锁，因此，关于读写锁的建边，则首先判断锁为读锁时，进行判断是否有其他执行线程在等待写锁，若是，则建立前一所述锁对应所述节点到所述写锁对应所述节点的有向边；若否，则需要判断所述执行线程是否已获得所述读锁，若是，则不需要建边，若否，则建立前一所述锁对应所述节点到所述读锁对应所述节点的有向边。

通过针对不同种类的锁的建立有向边的方式不同能够有效地建立正确的有向边以生成逻辑图，从而判断死锁更加的准确且利用建立有向边以生成逻辑图进行检测死锁的方法能够在更短的时间内判断死锁的情况。

图6示出根据本申请另一个方面的一种用于进程中检测死锁的设备的结构示意图。所述设备1包括生成装置11、确定装置12和判断装置13，其中，所述生成装置11基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；所述确定装置12用于当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；所述判断装置13用于判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

在此，所述设备1包括但不限于用户设备、或用户设备与网络设备通过网络相集成所构成的设备。所述用户设备其包括但不限于任何一种可与用户通过触摸板进行人机交互的移动电子产品，例如智能手机、PDA等，所述移动电子产品可以采用任意操作系统，如android操作系统、iOS操作系统等。其中，所述网络设备包括一种能够按照事先设定或存储的指令，自动进行数值计算和信息处理的电子设备，其硬件包括但不限于微处理器、专用集成电路(ASIC)、可编程门阵列(FPGA)、数字处理器(DSP)、嵌入式设备等。所述网络包括但不限于互联网、广域网、城域网、局域网、VPN网络、无线自组织网络(Ad Hoc网络)等。优选地，设备1还可以是运行于所述用户设备、或用户设备与网络设备、触摸终端或网络设备与触摸终端通过网络相集成所构成的设备上的脚本程序。当然，本领域技术人员应能理解上述设备1仅为举例，其他现有的或今后可能出现的第一设备如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

上述各装置之间是持续不断工作的，在此，本领域技术人员应理解“持续”是指上述各装置分别实时地或者按照设定的或实时调整的工作模式要求，例如所述生成装置11持续基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；确定装置12当所述执行线程有状态为异常时，持续获取所述执行线程对应的逻辑图；判断装置13持续判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况，直至所述设备1完成确认请求用户身份工作或停止工作。

本申请一实施例所述设备1用于检测进程中死锁，针对锁的种类建立有向边进而生成逻辑图，创建检测线程定期检查所有执行线程从而正确选择检测死锁的时机，基于检测线程和逻辑图在更短的时间内更准确的判断死锁情况。

具体地，生成装置11基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图。

在此，对于多线程的进程中，需要按照执行线程获取锁的顺序进行建立有向边进而构造逻辑图。例如，执行线程A、B、C获取锁时生成对应的节点为节点a、b、c，以节点a、b、c为顶点建边进而生成逻辑图；也可以是执行线程A依次获取锁a、b、c，生成对应的节点a、b、c。需要说明的是，执行线程A代表多线程中的某一线程并不特指，执行线程A获取锁生成对应节点可用a表示也可用b表示，并不只限于线程A只能获取锁a生成节点只能为a，以上举例仅为执行线程获取锁后生成节点的具体描述。对于不同种类的锁，如果采用同一建图方法，则可能在判断是否有死锁时出现误判，因此基于锁的种类及锁之间的获取顺序建立锁对应节点之间的有向边，进而依据所建的有向边生成逻辑图，其中，逻辑图中的顶点为锁对应的节点，有向边为前一锁对应的节点指向当前锁对应的节点所构成的有方向的边，例如，线程D获取了锁d，然后去获取锁e，则建一条有向边：d->e。所述锁的种类包括读写锁和非读写锁，其中，对于读写锁，可以同时获取读锁但是同时只能有一个线程获取写锁，并且没有其他的线程获取读锁。对于非读写锁，可分为可重入锁和不可重入锁，两种锁在同一时刻只能有一个线程获取，对于可重入锁来说，一个线程在获取可重入锁后，在没有释放锁的前提下，还可以再次获取这个锁；不可重入锁表示如果一个线程不能够多次获取同一个锁。

具体地，确定装置12用于当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图。

在此，优选地，确定装置12包括创建单元(未示出)，用于创建检测线程，利用所述检测线程定期检查所有所述执行线程的状态是否异常，当有所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图。在正常情况下可以采用一个线程定期的检查是否存在死锁，但是由于在检查死锁时，需要对获取锁过程中建立出来的逻辑图，所以不能够这样频繁的拷贝图，因拷贝图时会和正常服务的线程存在竞争关系。为了减少这种影响，采用创建检测线程以先检查所有其他的线程状态是否正常，只有当确定为异常时，才获取建立好的逻辑图，然后进行判断是否是死锁。

本领域技术人员应能理解，所述创建检测线程检测执行线程的状态是否异常的方法仅为举例，还可以在前端通过定期请求服务来判断服务是否正常，其他现有的或今后可能出现的检测执行线程的状态是否异常的方法如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

具体地，判断装置13用于判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

在此，需要说明的是，有向无环图(Directed Acycling Graph，DAG)代表一个有向图无法从某个顶点出发经过若干条边回到该点，对基于节点及节点之间的有向边生成的逻辑图进行遍历，如果同一个节点被遍历两次，则说明所述逻辑图不是有向无环图，存在死锁的情况，否则不存在。如果判断没有死锁，那么将当时的状态输出，有可能是系统中有些操作在特殊情况下处理的时间过长，因此检查死锁的时机选择正确时能够在更短的时间更准确的检测死锁情况。例如，创建检测线程，每隔10s检测所有的执行线程的状态是否异常。与现有技术中用一线程监测所有的线程处于D状态的时间是否超过预设时间相比，本申请的检测线程仅用来判断线程是否出现异常状态，与检测D状态所用的时间相比，极大的缩短了检测时间。

优选地，如图7示出根据本申请另一个方面的一个优选实施例的生成装置11的结构示意图；所述生成装置11包括判断单元111、第一建边单元112和第二建边单元113，其中，判断单元111用于若所述锁为读锁，则判断是否有其他所述执行线程在等待写锁；若是，第一建边单元112建立前一所述锁对应所述节点到所述写锁对应所述节点的有向边；若否，第二建边单元113判断所述执行线程是否已获得所述读锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述读锁对应所述节点的有向边。

在此，当系统配置上写锁优先的情况下，一个线程重复获取读锁，而有另外线程要获取写锁时会导致死锁，在建立有向边时选择的方式是首先要判断锁是否为读锁，如果是则判断是否有其它线程在等待写锁，如果有，那么无条件建边，否则判断该线程是否已经获得了该锁，如果获得了，那么无需建边，否则建边。需要说明的是，读写锁具有两种状态：读锁状态和写锁状态，当进程(或线程)获取读写锁进行读操作时读写锁为读锁，当进行写操作时读写锁为写锁，读操作和写操作是互斥的。在一具体实施例中，若执行线程A已获取读写锁lock b以进行读操作，在获取锁lock a后获取读写锁lock b，这时发现执行线程B在等待读写锁lock b以进行写操作，则建立前一所述锁lock a对应节点a到作为写锁lock b对应节点b的有向边：a->b，因为获取锁lock a之前获取过作为读锁的lock b，因此前面建过有向边b->a，此时，形成一个b->a->b的有向环，进行遍历该有向环时节点b被遍历两次，说明存在死锁，符合系统配置写锁优先的情况下获取读锁时另有线程需获取写锁造成的死锁的实际情况。若执行线程A获取完锁b再次遇到读锁lock b时，没有其他线程在等待写锁，则判断执行线程A是否已获取读锁lock b，若是，则无需建立有向边：b->b，否则建立前一所述锁lock b对应节点b到锁lock b之后获取到的下一读锁对应节点的有向边。

更优选地，第二建边单元113包括：第一获取子单元(未示出)从所述读锁的记录信息中获取执行线程身份信息；第一确定子单元(未示出)基于执行线程身份信息，确定所述执行线程已获得所述读锁。

在此，锁的记录信息包括获取该锁的执行线程的身份信息id，当某一执行线程获得读锁后需要从锁的记录信息中获取到执行线程id，基于执行线程id确定执行线程已获得了该读锁。例如，从某一读锁lock n的记录信息中可获得获取lock n的执行线程为线程A还是线程B或其他线程，进而判断出该锁是否被同一执行线程多次获取。当建完边后需要更新获取锁的线程id，即更新锁的记录信息。

优选地，所述生成装置11还包括：第三建边单元(未示出)，用于若所述锁为可重入锁，则判断所述执行线程是否已获得所述可重入锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述可重入锁对应所述节点的有向边。

在此，更优选地，第三建边单元包括：第二获取子单元(未示出)从所述可重入锁的记录信息中获取执行线程身份信息；第二确定子单元(未示出)基于执行线程身份信息，确定所述执行线程已获得所述可重入锁。在一优选实施例中，如图3示出根据本申请一个方面的一个优选实施例的可重入锁建边的流程示意图；首先，执行线程A获取锁Lock a后，Locka的记录信息中会记录获取该锁的执行线程id，记录为线程A；接着，按照获取锁的顺序会有线程获取锁Lock b，当Lock a和Lock b为同一锁时，说明此时的锁为可重入锁，进行判断获取该锁的执行线程是否为线程B，在此，线程B用于代表若干执行线程中除了线程A外的任一线程，不特指某一线程，若判断获取该锁的执行线程为线程B，则说明获取可重入锁的线程不是同一线程，则建立前一锁Lock a到可重入锁Lock b的有向边：a->b；若判断获取该锁的执行线程不是线程B，则说明获取可重入锁Lock b的线程为同一线程，都为线程A，则不需要建立有向边：a->a。最后，更新获取锁Lock b的线程id，即记录获取锁时的线程为线程A还是线程B，当继续获取锁时，以便根据之前的记录信息进行判断该锁是否再次被同一线程获取，以继续往下进行建立有向边进而生成逻辑图，从而达到根据逻辑图进行检测死锁的目的。

优选地，生成装置11还包括：第四建边单元(未示出)，用于若所述锁为不可重入锁，则建立前一所述锁对应所述节点到所述可重入锁对应所述节点的有向边。

在此，例如，在一优选实施例中，图4示出根据本申请一个方面的一个优选实施例的不可重入锁建边的流程示意图；在多线程的进程中，按照执行线程获取锁的顺序进行建立逻辑图，首先，对于锁Lock a，通过从锁的记录信息中获得获取Lock a的线程id，为线程A，当线程A获取Lock a后，继续去获取锁Lock b，因Lock a为不可重入锁，代表一个线程不能多次获取同一个锁，即线程A再获取锁Lock b对于Lock a来说是不同的锁，则进行建立一条有向边：a->b，最后更新获取锁Lock b的线程id，以便根据之前的记录信息进行判断该锁是否为不可重入锁，若是，则按照上述不可重入锁建边的方法继续往下进行建立有向边进而生成逻辑图，从而达到根据逻辑图进行检测死锁的目的。

优选地，所述判断装置13包括：遍历单元(未示出)基于遍历算法对所述逻辑图进行遍历；确定单元(未示出)用于若至少一个所述遍历路径存在至少一个所述节点被遍历至少两次，则确定所述逻辑图不是有向无环图，否则确定所述逻辑图是有向无环图。

在此，优选，所述遍历算法包括深度优先搜索算法(Depth-First-Search，DFS)和广度优先搜索算法(Breadth-First-Search，BFS)对生成的逻辑图进行遍历，判断所遍历的逻辑图是否为DAG，采用DFS算法时判断的伪代码可用如下方式表示：

需要说明的是，上述伪代码表示对逻辑图中的顶点进行遍历时，如果顶点A被遍历过，则说明顶点A被第二次遍历，返回结果为逻辑图不是DAG图；若A没被遍历，则开始对A进行遍历并标记遍历过A，再根据节点深度进行下一个顶点的遍历，判断下一个顶点是否被遍历过，循环执行以上遍历步骤，直到再次遇到被遍历过的顶点，其中，IF dfs(x)为真代表对所有节点遍历时存在至少一个节点被两次遍历过，则返回结果为逻辑图不是DAG图，若所有节点只遍历过一次，则说明逻辑图为DAG图。而对逻辑图进行DFS遍历进而判断死锁的伪代码可如下表示：

需要说明的是，上述伪代码表示对逻辑图的节点依次进行遍历，当遍历一个节点时，首先判断该节点是否被遍历过，若没有遍历则对该节点进行遍历，其中，IF dfs(A)为真表示遍历节点A并标记遍历过A，再根据节点深度进行下一个节点的遍历，判断下一个节点是否被遍历过，循环执行以上遍历步骤，直到再次遇到被遍历过的节点，返回结果有死锁。

在此，对逻辑图进行DFS遍历进而判断死锁的伪代码是基于判断所遍历的逻辑图是否为DAG进行的，即判断逻辑图是否为DAG从而进行确认是否为死锁，可得出对于死锁必然不是DAG图的推断。

本领域技术人员应能理解，所述遍历算法中的DFS和BFS仅为举例，其他现有的或今后可能出现的遍历算法如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

图5示出根据本申请一个方面的一个优选实施例的不同锁建边的流程示意图；可重入锁、不可重入锁和读写锁的建立有向边的方式不同，如图5示出，若是不可重入锁，则建立前一锁对应的节点到不可重入锁对应节点的有向边。但此方法在建边过程中存在一个问题，如果锁是可重入的，那么这样的建边所生成的逻辑图在判断是否为死锁时有可能会导致误判，所以，对于普通的可重入锁，需要判断执行线程是否已获得可重入锁，若是，则不需要建边，若否，则建立前一锁对应的节点到可重入锁对应所述节点的有向边。而前述两种建边方法不能解决当系统配置上写锁优先的情况下有一个线程重复获取读锁，而有另外线程要获取写锁时而导致的死锁，因此，关于读写锁的建边，则首先判断锁为读锁时，进行判断是否有其他执行线程在等待写锁，若是，则建立前一所述锁对应所述节点到所述写锁对应所述节点的有向边；若否，则需要判断所述执行线程是否已获得所述读锁，若是，则不需要建边，若否，则建立前一所述锁对应所述节点到所述读锁对应所述节点的有向边。

通过针对不同种类的锁的建立有向边的方式不同能够有效地建立正确的有向边以生成逻辑图，从而判断死锁更加的准确且利用建立有向边以生成逻辑图进行检测死锁的方法能够在更短的时间内判断死锁的情况。

此外，本申请还提供了一种用于进程中检测死锁的设备，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；

当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；

判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

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

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

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

Claims (17)

1.一种用于进程中检测死锁的方法，其中，所述方法包括：

基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；

当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；

判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

2.根据权利要求1所述的方法，其中，所述基于所述锁的种类及所述锁之间的获取顺序确定对应所述节点之间的有向边包括：

若所述锁为读锁，则判断是否有其他所述执行线程在等待写锁；

若是，则建立前一所述锁对应所述节点到所述写锁对应所述节点的有向边；

若否，则判断所述执行线程是否已获得所述读锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述读锁对应所述节点的有向边。

3.根据权利要求2所述的方法，其中，判断所述执行线程是否已获得所述读锁包括：

从所述读锁的记录信息中获取执行线程身份信息；

基于执行线程身份信息，确定所述执行线程已获得所述读锁。

4.根据权利要求1所述的方法，其中，所述基于所述锁的种类及所述锁之间的获取顺序确定对应所述节点之间的有向边包括：

若所述锁为可重入锁，则判断所述执行线程是否已获得所述可重入锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述可重入锁对应所述节点的有向边。

5.根据权利要求4所述的方法，其中，判断所述执行线程是否已获得所述可重入锁包括：

从所述可重入锁的记录信息中获取执行线程身份信息；

基于执行线程身份信息，确定所述执行线程已获得所述可重入锁。

6.根据权利要求1所述的方法，其中，所述基于所述锁的种类及所述锁之间的获取顺序确定对应所述节点之间的有向边还包括：

若所述锁为不可重入锁，则建立前一所述锁对应所述节点到所述不可重入锁对应所述节点的有向边。

7.根据权利要求1所述的方法，其中，所述当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图包括：

创建检测线程，利用所述检测线程定期检查所有所述执行线程的状态是否异常，当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图。

8.根据权利要求1所述的方法，其中，所述判断所述逻辑图是否为有向无环图包括：

基于遍历算法对所述逻辑图进行遍历；

若至少一个所述遍历路径存在至少一个所述节点被遍历至少两次，则确定所述逻辑图不是有向无环图，否则确定所述逻辑图是有向无环图。

9.一种用于进程中检测死锁的设备，其中，所述设备包括：

生成装置，用于基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；

确定装置，用于当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；

判断装置，用于判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。

10.根据权利要求9所述的设备，其中，所述生成装置包括：

判断单元，用于若所述锁为读锁，则判断是否有其他所述执行线程在等待写锁；

第一建边单元，用于若有其他所述执行线程在等待写锁，则建立前一所述锁对应所述节点到所述写锁对应所述节点的有向边；

第二建边单元，用于若没有其他所述执行线程在等待写锁，则判断所述执行线程是否已获得所述读锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述读锁对应所述节点的有向边。

11.根据权利要求10所述的设备，其中，所述第二建边单元包括：

第一获取子单元，用于从所述读锁的记录信息中获取执行线程身份信息；第一确定子单元，用于基于执行线程身份信息，确定所述执行线程已获得所述读锁。

12.根据权利要求9所述的设备，其中，所述生成装置还包括：

第三建边单元，用于若所述锁为可重入锁，则判断所述执行线程是否已获得所述可重入锁，若是则无需建立所述有向边，否则建立前一所述锁对应所述节点到所述可重入锁对应所述节点的有向边。

13.根据权利要求12所述的设备，其中，所述第三建边单元包括：

第二获取子单元，用于从所述可重入锁的记录信息中获取执行线程身份信息；

第二确定子单元，用于基于执行线程身份信息，确定所述执行线程已获得所述可重入锁。

14.根据权利要求9所述的设备，其中，所述生成装置还包括：

第四建边单元，用于若所述锁为不可重入锁，则建立前一所述锁对应所述节点到所述不可重入锁对应所述节点的有向边。

15.根据权利要求9所述的设备，其中，所述确定装置包括：

创建单元，用于创建检测线程，利用所述检测线程定期检查所有所述执行线程的状态是否异常，当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图。

16.根据权利要求9所述的设备，其中，所述判断装置包括：

遍历单元，用于基于遍历算法对所述逻辑图进行遍历；

确定单元，用于若至少一个所述遍历路径存在至少一个所述节点被遍历至少两次，则确定所述逻辑图不是有向无环图，否则确定所述逻辑图是有向无环图。

17.一种用于进程中检测死锁的设备，其中，包括：

处理器；

以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器：

基于若干执行线程所获取的锁生成对应所述节点，基于所述锁的种类及所述锁之间的获取顺序建立所述锁对应所述节点之间的有向边，基于所述节点及所述节点之间的有向边生成逻辑图；

当所述执行线程有状态为异常时，获取所述执行线程对应的逻辑图；

判断所述逻辑图是否为有向无环图，若否，则确定有死锁情况。