CN111831557B

CN111831557B - 死锁检测的方法及装置

Info

Publication number: CN111831557B
Application number: CN202010563932.2A
Authority: CN
Inventors: 王洋
Original assignee: Beijing H3C Technologies Co Ltd
Current assignee: Beijing H3C Technologies Co Ltd
Priority date: 2020-06-19
Filing date: 2020-06-19
Publication date: 2023-10-20
Anticipated expiration: 2040-06-19
Also published as: CN111831557A

Abstract

本申请提供一种死锁检测的方法及装置，所述方法应用于第一进程，所述方法包括：当处于所述第一进程内的线程获取锁时，所述第一进程获取所述第一进程的全局版本标识以及锁的版本标识；所述第一进程判断所述锁的版本标识与所述第一进程的全局版本标识是否相同；如果不相同，则所述第一进程获取所述锁的调用栈信息；所述第一进程显示所述调用栈信息，以提示存在所述锁存在死锁状态。

Description

死锁检测的方法及装置

技术领域

本申请涉及通信技术领域，尤其涉及一种死锁检测的方法及装置。

背景技术

派生、分支（fork）函数是Linux操作系统提供的一种功能函数，其用来生成一个调用进程的副本。调用fork函数的进程通常称为父进程，调用后产生的副本进程通常称为子进程。

父、子进程在fork后的瞬间，两者的内存空间是相同的。后续，如果父、子进程对内存空间进行修改，则各自互不影响。fork后的父、子进程的内存空间完全相同，为程序带来很多便利。例如，数据库可通过fork出的子进程去执行数据导出的操作，同时，不影响父进程处理其他业务。但上述特性也带来了一些缺陷，即程序很难预防死锁问题。

本质上，软件系统的锁（lock），是一块内存数据。通常是利用硬件系统提供的原子操作来读取、修改锁，达到获取锁、释放锁的功能。因此，fork后的父、子进程在fork后的瞬间也会出现死锁问题，尤其是在多线程环境下。如下述流程所示。

初始状态，父进程包括两个线程，即线程1和线程2。同时锁的状态是释放（Unlocked）。如图1所示。时刻1，线程2需要访问锁保护的互斥资源，于是线程2获取锁。此时，线程2访问互斥资源完毕后正常释放锁，不会出现死锁问题。如图2所示。时刻2，在线程2尚未释放锁时，线程1进行fork操作。fork后的子进程的锁没有机会释放。因为fork后子进程仅包括线程1，不包括线程2，而释放锁需要依靠线程2。如图3所示。时刻3，子进程的线程1再次尝试获取锁，由于锁尚未被释放，此时，发生了死锁，如图4所示。

为了解决上述死锁的问题，通常的做法是，在进程fork前，进程调用待fork的线程，例如，线程1。线程1将fork后可能访问的锁均获取，在fork后，子进程和父进程各自释放锁。如此，可确保不会产生死锁问题。如图5所示。

目前，检测fork死锁常采用代码静态分析或者黑盒测试。代码静态分析即是通过手工或自动对调用层次结构进行分析，推断进程fork时是否会有死锁的可能。但是，由于代码静态分析需要构建调用关系图，其非常耗时。其次，每次修改都要进行大量的分析，工作量大。而通过黑盒测试进行时，如前所述，由于线程获取锁的过程通常很短，fork的时机必须在获取锁的期间进行，在实验室的测试环境中很难碰到。通常仅在产品大规模发布后，在实际环境中才能暴露。

发明内容

有鉴于此，本申请提供了一种死锁检测的方法及装置，解决代码静态分析耗时长、工作量大的缺点，同时，提高在实验室环境中，采用黑盒测试fork死锁的暴露概率。

第一方面，本申请提供了一种死锁检测的方法，所述方法应用于第一进程，所述方法包括：

当处于所述第一进程内的线程获取锁时，所述第一进程获取所述第一进程的全局版本标识以及锁的版本标识；

所述第一进程判断所述锁的版本标识与所述第一进程的全局版本标识是否相同；

如果不相同，则所述第一进程获取所述锁的调用栈信息；

所述第一进程显示所述调用栈信息，以提示存在所述锁存在死锁状态。

结合第一方面，在第一种可能的实现方式中，所述第一进程的全局版本标识的初始值为1，所述锁的版本标识的初始值为1。

结合第一方面，在第二种可能的实现方式中，所述第一进程的全局版本标识还用于所述锁初始化或者所述线程释放所述锁时，利用所述第一进程的全局版本标识更新所述锁的版本标识。

结合第一方面，在第三种可能的实现方式中，所述方法还包括：

所述第一进程调用fork函数，得到第二进程，所述第二进程的全局版本标识大于所述第一进程的全局版本标识。

结合第一方面，在第四种可能的实现方式中，所述方法还包括：

如果相同，则所述第一进程不获取所述锁的调用栈信息。

第二方面，本申请提供了一种死锁检测的装置，所述装置应用于第一进程，所述装置包括：

获取单元，用于当处于所述第一进程内的线程获取锁时，获取所述第一进程的全局版本标识以及锁的版本标识；

判断单元，用于所述第一进程判断所述锁的版本标识与所述第一进程的全局版本标识是否相同；

所述获取单元还用于，如果不相同，则所述第一进程获取所述锁的调用栈信息；

显示单元，用于显示所述调用栈信息，以提示存在所述锁存在死锁状态。

结合第二方面，在第一种可能的实现方式中，所述第一进程的全局版本标识的初始值为1，所述锁的版本标识的初始值为1。

结合第二方面，在第二种可能的实现方式中，所述第一进程的全局版本标识还用于所述锁初始化或者所述线程释放所述锁时，利用所述第一进程的全局版本标识更新所述锁的版本标识。

结合第二方面，在第三种可能的实现方式中，所述装置还包括：

调用单元，用于所述第一进程调用fork函数，得到第二进程，所述第二进程的全局版本标识大于所述第一进程的全局版本标识。

结合第二方面，在第四种可能的实现方式中，所述装置还包括：

处理单元，用于如果不同，则所述第一进程不获取所述锁的调用栈信息。

因此，通过应用本申请提供的一种死锁检测的方法及装置，第一进程获取到第一进程的全局版本标识以及锁的版本标识后，当处于第一进程内的线程获取锁时，第一进程判断锁的版本标识与第一进程的全局版本标识是否相同。如果不相同，则第一进程获取锁的调用栈信息。然后，第一进程显示调用栈信息，以提示存在锁存在死锁状态。

本申请通过增加进程的全局版本标识和每个锁的版本标识，判断出潜在的死锁。再者，即使fork后未出现真正死锁，通过本申请也可提早探测出来，避免在产品大规模上市后发现死锁；同时，本申请无需进行复杂的静态代码分析。

附图说明

图1为现有技术中提供的进程、线程、锁的初始状态示意图；

图2为现有技术中提供的线程2获取锁示意图；

图3为现有技术中提供的fork后子进程未释放锁示意图；

图4为现有技术中提供的出现死锁示意图；

图5为现有技术中提供的正常fork、获取、释放锁示意图；

图6为本申请实施例提供的一种死锁检测的方法的流程图；

图7为本申请实施例提供的进程的全局版本标识以及所得版本标识示意图；

图8为本申请实施例提供的一种进程调用fork函数后处理锁的流程示意图；

图9为本申请实施例提供的另一种进程调用fork函数后处理锁的流程示意图；

图10为本申请实施例提供的一种死锁检测的装置结构图。

实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施例并不代表与本申请相一致的所有实施例。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相对应的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

下面对本申请实施例提供的死锁检测的方法进行详细地说明。参见图6，图6为本申请实施例提供的一种死锁检测的方法的流程图。该方法应用于第一进程。该第一进程内可包括多个线程，例如，线程1、线程2等。本申请实施例提供的死锁检测的方法可包括如下所示步骤。

步骤610、当处于所述第一进程内的线程获取锁时，所述第一进程获取所述第一进程的全局版本标识以及锁的版本标识。

具体地，在本申请实施例中，在先为每个进程新增一全局变量，即G_version，该变量表示进程的全局版本标识。同时，为每个锁新增一字段，即锁的版本（version）标识。如图7所示，图7为本申请实施例提供的进程的全局版本标识以及所得版本标识示意图。

其中，进程的全局版本标识的初始值为1，需要说明的是，进程的全局版本标识还用于锁初始化时，利用进程的全局版本标识更新锁的版本标识，以使得在初始时，锁的版本标识与进程的全局版本标识相同。如此，锁的版本标识的初始值也为1。

当处于进程（例如，第一进程）内的线程（例如，第一线程）获取锁时，第一进程获取自身的全局版本标识以及锁的版本标识。

进一步地，在本申请实施例中，进程的全局版本标识与进程自身的角色关联。作为父进程的进程在调用fork函数后，得到子进程。对于子进程，子进程的全局版本标识大于父进程的全局版本标识。

例如，父进程的全局版本标识为1，父进程调用fork函数，得到子进程。子进程判断自身的角色。子进程确定自身为子进程，则子进程的全局版本标识为2，也即是在父进程的全局版本标识的基础上递增。

步骤620、所述第一进程判断所述锁的版本标识与所述第一进程的全局版本标识是否相同。

具体地，第一进程获取到自身的全局版本标识以及锁的版本标识后，第一进程判断锁的版本标识与第一进程的全局版本标识是否相同。

如果不相同，则第一进程执行步骤630。

步骤630、如果不相同，则所述第一进程获取所述锁的调用栈信息。

具体地，根据步骤620的判断，如果锁的版本标识与第一进程的全局版本标识不相同，例如，第一进程的全局版本为2，而锁的版本标识为1，则第一进程认为判断结果为不同。此时，第一进程确定在进程进行fork时，存在线程未在fork前释放锁，进而出现死锁的情况出现。第一进程获取锁的调用栈信息。该调用栈信息包括锁的获取、释放流程。管理人员可通过该调用栈信息，快速定位出现死锁的位置。

例如，调用栈信息为：

#0 0x00007f2d218e5a2f in strnlen () from /lib/libc.so.0

#1 0x00007f2d218e1243 in ？？ () from /lib/libc.so.0

#2 0x00007f2d218df01a in vscnprintf () from /lib/libc.so.0

#3 0x00007f2d218df058 in vscnprintf () from /lib/libc.so.0

进一步地，根据步骤620的判断，如果锁的版本标识与第一进程的全局版本标识相同，例如，第一进程的全局版本为2，而锁的版本标识也为2，则第一进程认为判断结果为相同。此时，第一进程不获取锁的调用栈信息。

步骤640、所述第一进程显示所述调用栈信息，以提示存在所述锁存在死锁状态。

具体地，第一进程获取到调用栈信息后，对该调用栈信息进行显示，以提示管理人员当前锁存在死锁状态。

因此，通过应用本申请提供的死锁检测的方法，第一进程获取到第一进程的全局版本标识以及锁的版本标识后，当处于第一进程内的线程获取锁时，第一进程判断锁的版本标识与第一进程的全局版本标识是否相同。如果不相同，则第一进程获取锁的调用栈信息。然后，第一进程显示调用栈信息，以提示存在锁存在死锁状态。

可选地，在本申请实施例中，第一进程的全局版本标识还用于线程（例如，第一线程）释放锁时，第一进程利用自身的全局版本标识更新锁的版本标识。

在一个例子中，第一进程的全局版本标识为2。当前，第一线程获取锁，锁的版本标识为1。在第一线程释放锁时，第一进程利用自身的全局版本标识更新锁的版本标识，也即是第一进程将锁的版本标识更新为2。

可选地，在本申请实施例中，还包括下述流程：

具体地，第一进程调用fork函数，得到第二进程。此时，第一进程为父进程，第二进程为子进程。对于子进程，第二进程的全局版本标识大于第一进程的全局版本标识。

例如，第一进程的全局版本标识为1，第一进程调用fork函数，得到第二进程。第二进程判断自身的角色。第二进程确定自身为子进程，则第二进程的全局版本标识为2。

下面通过图8、图9对本申请实施例提供的死锁检测的方法进行详细地说明。图8为本申请实施例提供的一种进程调用fork函数后处理锁的流程示意图。图9为本申请实施例提供的另一种进程调用fork函数后处理锁的流程示意图。

如图8所示，初始状态，父进程的全局版本标识为1，锁A以及锁B的版本标识也为1，与父进程的全局版本标识相同。父进程包括两个线程，即线程1和线程2。线程1需要访问多个锁保护的互斥资源，于是线程1获取锁A以及锁B。锁A以及锁B的状态是获取（Locked）。

线程1调用fork函数，得到子进程。子进程的全局版本标识为2。子进程包括一个线程，即线程1’。此时，无论线程1或线程1’，由于线程1或线程1’还未释放锁A以及锁B。锁A以及锁B的版本标识仍为1。

针对子进程，若线程1’释放锁A以及锁B，则子进程利用自身的全局版本标识更新锁A以及锁B的版本标识，也即是，子进程将锁A以及锁B的版本标识更新为2。

针对父进程，若线程1释放锁A以及锁B，则父进程利用自身的全局版本标识更新锁A以及锁B的版本标识，在本例中，由于父进程自身的全局版本标识与锁A以及锁B的版本标识相同，因此，父进程可不对锁A以及锁B的版本标识进行更新。

针对子进程，后续线程1’再次获取锁A或锁B时，子进程判断锁A或锁B的版本标识与子进程自身的全局版本标识相同，则此时，子进程确定当前未出现死锁状态。

如图9所示，初始状态，父进程的全局版本标识为1，锁A以及锁B的版本标识也为1，与父进程的全局版本标识相同。父进程包括两个线程，即线程1和线程2。线程1需要访问锁A保护的互斥资源，于是线程1获取锁A。锁A的状态是获取（Locked），锁B的状态是释放（Unlocked）。

线程1调用fork函数，得到子进程。子进程的全局版本标识为2。子进程包括一个线程，即线程1’。此时，无论线程1或线程1’，由于线程1或线程1’还未释放锁A，锁A的状态仍为获取（Locked），锁A的版本标识仍为1。

针对子进程，若线程1’释放锁A，则子进程利用自身的全局版本标识更新锁A的版本标识，也即是，子进程将锁A的版本标识更新为2。需要注意的是，由于锁B在先未被线程1获取（Locked），线程1调用fork函数后，锁B的状态未改变，即仍为释放（Unlocked），子进程不会对所B的版本标识进行更新，锁B的版本标识仍为1。

针对父进程，若线程1释放锁A，则父进程利用自身的全局版本标识更新锁A的版本标识，在本例中，由于父进程自身的全局版本标识与锁A的版本标识相同，因此，父进程可不对锁A的版本标识进行更新。需要注意的是，由于锁B在先未被线程1获取（Locked），锁B的状态未改变，即仍为释放（Unlocked），父进程也不会对所B的版本标识进行更新，锁B的版本标识仍为1。后续线程1再次获取锁A或锁B时，父进程判断锁A或锁B的版本标识与父进程自身的全局版本标识相同，则此时，父进程确定当前未出现死锁状态。

针对子进程，后续线程1’再次获取锁B时，子进程判断锁B的版本标识与子进程自身的全局版本标识不同，则此时，子进程确定当前出现死锁状态。子进程获取锁B的调用栈信息，并对该调用栈信息进行显示，以提示管理人员当前锁存在死锁状态。

因此，利用fork后进程身份的不同以及进程的全局版本标识，对锁的版本标识进行更新，判断出潜在的死锁。再者，即使fork后未出现真正死锁，通过本申请也可提早探测出来，避免在产品大规模上市后发现死锁；同时，本申请无需进行复杂的静态代码分析。

基于同一发明构思，本申请实施例还提供了与上述死锁检测的方法对应的死锁检测的装置。参见图10，图10为本申请实施例提供的一种死锁检测的装置结构图，该装置应用于第一进程，该装置包括：

获取单元1010，用于当处于所述第一进程内的线程获取锁时，获取所述第一进程的全局版本标识以及锁的版本标识；

判断单元1020，用于所述第一进程判断所述锁的版本标识与所述第一进程的全局版本标识是否相同；

所述获取单元1010还用于，如果不相同，则所述第一进程获取所述锁的调用栈信息；

显示单元1030，用于显示所述调用栈信息，以提示存在所述锁存在死锁状态。

可选地，所述第一进程的全局版本标识的初始值为1，所述锁的版本标识的初始值为1。

可选地，所述第一进程的全局版本标识还用于所述锁初始化或者所述线程释放所述锁时，利用所述第一进程的全局版本标识更新所述锁的版本标识。

可选地，所述装置还包括：调用单元（图中未示出），用于所述第一进程调用fork函数，得到第二进程，所述第二进程的全局版本标识大于所述第一进程的全局版本标识。

可选地，所述装置还包括：处理单元（图中未示出），用于如果相同，则所述第一进程不获取所述锁的调用栈信息。

因此，通过应用本申请提供的一种死锁检测的装置，该装置获取到第一进程的全局版本标识以及锁的版本标识后，当处于第一进程内的线程获取锁时，该装置判断锁的版本标识与第一进程的全局版本标识是否相同。如果不相同，则该装置获取锁的调用栈信息。然后，该装置显示调用栈信息，以提示存在锁存在死锁状态。

另外，本申请实施例提供了一种机器可读存储介质，机器可读存储介质存储有机器可执行指令，在被处理器调用和执行时，机器可执行指令促使处理器自身以及调用收发器执行前述本申请实施例描述的死锁检测的方法。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

对于死锁检测的装置以及机器可读存储介质实施例而言，由于其涉及的方法内容基本相似于前述的方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims

1.一种死锁检测的方法，其特征在于，所述方法应用于第一进程，所述方法包括：

如果不相同，则所述第一进程获取所述锁的调用栈信息；

所述第一进程显示所述调用栈信息，以提示存在所述锁存在死锁状态；

其中，所述第一进程的全局版本标识的初始值为1，所述锁的版本标识的初始值为1；以及所述第一进程的全局版本标识还用于所述线程释放所述锁时，利用所述第一进程的全局版本标识更新所述锁的版本标识；

所述方法还包括：

2.根据权利要求1所述的方法，其特征在于，所述第一进程的全局版本标识还用于所述锁初始化时，利用所述第一进程的全局版本标识更新所述锁的版本标识。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

如果相同，则所述第一进程不获取所述锁的调用栈信息。

4.一种死锁检测的装置，其特征在于，所述装置应用于第一进程，所述装置包括：

显示单元，用于显示所述调用栈信息，以提示存在所述锁存在死锁状态；

所述装置还包括：

5.根据权利要求4所述的装置，其特征在于，所述第一进程的全局版本标识还用于所述锁初始化时，利用所述第一进程的全局版本标识更新所述锁的版本标识。

6.根据权利要求4所述的装置，其特征在于，所述装置还包括：

处理单元，用于如果相同，则所述第一进程不获取所述锁的调用栈信息。