CN1987796A - 检测多线程程序中的死锁的方法和装置 - Google Patents

Abstract

本发明提供了一种检测多线程程序中的死锁的方法。构建调用图，该调用图具有对应于以多线程程序的代码编写的、一个或多个函数的一个根和多个节点。根据在调用图的每个节点上起作用的、一个或多个资源集合，计算资源图。判断在资源图的两个或更多个节点之间是否存在循环。循环是多线程程序中死锁的指示。

Description

检测多线程程序中的死锁的方法和装置

技术领域

本发明一般涉及多线程程序，特别是涉及用于检测多线程程序中的死锁的技术。

背景技术

死锁是其中多个进程被禁止取得进展的一种恶性状况，因为各个进程都在等待某其他进程正在使用的、一个或多个资源。然而，由于死锁只在涉及例如正在执行的线程的交错或时序的特定条件下才可能发生，它是难以检测的。

在死锁的一简单示例中，操作系统包含两个文件，即文件1与文件2。两个并行运行的进程，即线程1与线程2，都需要文件1与文件2来成功完成。如果线程1打开了文件1且线程2打开了文件2，当线程1试图在关闭文件1之前打开文件2、而线程2试图在关闭文件2之前打开文件1时，可能导致死锁。这样，这两个进程可能永远等待下去。

有几位作者通过应用关于要求不同资源的并行运行线程的基本假设，已经提供了死锁的表征，例如，可参见W.W.Collier的“System Deadlocks”(Tech.Rep.TR-00.1756，IBM Systems Development Division，New York，1968)、J.W.Havender的“Avoiding Deadlock in Multitasking Systems”(IBM Syst.J.7，2(1968)，pp.74-84)、J.E.Murphy的“Resource Allocationwith Interlock Detection in a Multi-Task System(In Proc.FJCC，AEIPS(1968)，vol.33)以及A.Shoshani等人的“Prevention，Detection，andRecovery from System Deadlocks”(In Proceeding of the Fourth AnnualPrinceton Conference on Information Sciences and Systems(Mar.1970))。

关于并行运行的线程可做出的三个这种基本假设包括：

(1)互斥—线程要求对它们需要的资源拥有排他性控制；

(2)等待—线程保持已分配给它们的资源，并必须等待其他需要的资源；以及

(3)非抢占—直到将资源用到完成，不能从保持资源的线程强行移除资源。

在Java^TM语言(Sun Microsystems公司)的情境中，上述三个基本假设满足，且感兴趣的资源是锁(lock)。

当这些基本假设成立时，可用资源图对死锁进行表征，例如可参见W.W.Collier、J.W.Havender、J.E.Murphy和A.Shoshani等。图被定义为对(N，E)，其中N为节点的集合，E为边的集合。如果有n个不同的资源，则图中有n个节点，每个节点代表单个资源。每个边为(v，w)的形式，其中，v∈N，w∈N。如果存在一线程、该线程具有获得资源v接着又请求资源w的执行路径，则边(v，w)从节点v延伸到节点w。图中的路径是边的集合{(v_i，v_i+1)|i＝1，...n}，其中，n≥1。循环是这样的路径，其中，v₁，......，v_n全部不同，且v_n+1＝v₁。

假设线程没有请求其已经获得的资源，如果发生死锁，则资源图包含至少一个循环。在例如Java^TM等编程语言的情境中，图的使用可被称为锁循环策略，这是因为对于锁的获取和请求循环的搜索。

因此，希望在不执行多线程程序代码的情况下通过多线程程序的源代码和目标代码自动判断是否将发生死锁。

发明内容

在例如Java^TM等多线程语言中，为了正确地发挥程序功能，死锁是应当避免的严重状况。在Java^TM字节码中检测死锁的、本发明的实施例是自动的，且不需要字节码的任何注释。死锁的存在被准确地报告，且用户可检查输出，以便确定是否需要修改代码。因此，根据本发明的实施例，可使用静态分析技术。

例如，在本发明的一个方面中，提供了一种检测多线程程序中的死锁的方法。构建了调用图，其具有对应于以多线程程序代码编写的一个或多个函数的单个根和多个节点。根据在调用图的各个节点上起作用的一个或多个资源集合计算出资源图。判断资源图中两个或两个以上的节点之间是否存在循环。循环是多线程程序中死锁的指示。

另外，可通过按照在调用图各节点上起作用的资源集合构建节点和边的集合，来构建资源图。可通过后处理对资源图的定义进行精练，以生成额外的边。最后，可向用户报告任何循环以及所关联的路径信息。

本发明的方法包括既在过程间又在过程内的层面进行详细的报告，从而允许清楚地识别资源争用位置。该方法是普遍的，因为它通过涉及图而不涉及编程语言细节的、对程序的抽象描述，而对资源循环策略(resourcecycle strategy)进行工作。因此，本发明的实施例可应用于实现监视器(monitor)的任何语言，并可被伸缩以解决大型问题。

通过结合附图阅读下面对本发明的示例性实施例的详细介绍，可了解本发明的这些以及其他目标、特征和优点。

附图说明

图1为示出了根据本发明一实施例的死锁检测方法的流程图；

图2为示出了根据本发明一实施例的锁图计算方法的流程图；

图3为根据本发明一实施例的锁集合构建方法；

图4为用于一示例的Java^TM代码，该示例用于说明本发明的实施例；

图5为用于该示例的索引、程序计数器和源行号的表，访示例用于说明本发明的实施例；

图6为用于该示例的调用图的一部分，该示例用于说明本发明的实施例；

图7为用于该示例的锁图，该示例用于说明本发明的实施例；

图8为为该示例所产生的输出，该示例用于说明本发明的实施例；以及

图9为示出了计算系统的示例性硬件实现的框图，根据本发明的一实施例，根据该计算系统可实现本发明一个或多个组件/方法。

具体实施方式

如下面将详细示出的那样，本发明介绍了用于检测多线程程序中的死锁的技术。可以为任何实现了监视器的多线程程序实现本发明的实施例，然而，出于说明目的，这里它们被描述为应用于Java^TM程序。

既可以对源代码又可以对字节码利用本发明的实施例。在前一种情况下，对源代码进行编译，并将该方法应用于包含字节码的Java^TM档案(jar)文件。在后一种情况下，即使源代码不可用—这种情况可能经常发生，也可应用该方法。这些实施例是自动的，且不需要代码注释。将jar文件与某些配置数据一起输入到系统，并且输出为包括可能的死锁的概要的报告。

Java^TM语言利用了监视器，监视器通过确保代码体一次只被一个线程执行，来保护代码体。这是通过使用与每一Java^TM对象隐式地关联的锁来实现的。因此，如同上面所介绍的那样以及根据本发明实施例，资源图被称为锁图。为了开始构建锁图，提供一Java^TM程序，该程序由几组字节码组成。

最初参照图1，一流程图示出了根据本发明实施例的高级死锁检测方法。该方法开始于方框102，在该方框中，构建具有单个根或相关的入口点的调用图。在方框104中，通过考虑从根到源—在此资源被获得或被请求—的所有可能的执行路径，计算出锁图。出于报告目的，保留路径信息。在方框106中，判断结果得到的锁图是否具有任何循环。在方框108中，向用户报告任何循环以及相关联的路径信息。

在本发明的优选实施例中，利用了Java^TM字节码分析(JaBA)系统，该系统使用静态分析技术来为以Java^TM字节码编写的方法或函数构建调用图。JaBA还生成关于变量和锁的值的信息。该系统是对流敏感的，因为，每个方法的控制流图考虑了每个基本块中指令的执行顺序，并考虑到局部变量取消和对象引用的类型转换(casting)。该系统还是对上下文敏感的，因为调用图中的每个节点由其调用上下文—即方法、一组可能的接收者类型以及可能的参数类型—唯一地标识。

调用图中的每个节点代表了一方法和一特定的上下文，并包含该方法的控制流图的基本块以及访问和释放锁的位置。调用图还具有过程间的边(A，B)，其代表从方法A的内部对方法B的调用。该边从A中的指令—在此发生该调用—延伸到B的控制流图的初始顶点。本发明的调用图允许双向遍历，即使图中的边是单向的。因此，从调用图中的任何节点n，可找到其前面的节点的集合和后面的节点的集合。

除调用图外，执行精度达到分配点(allocation site)的层面的数据流分析，其中，每个分配被唯一标识。由调用图建模的Java^TM程序中的对象的数量总是有限的。对象代码中存在有限数量的调用，数组和其他汇集(collection)中的元素被建模为单个元素。JaBA还产生这样的文件，该文件指示所有被检查的类以及它们的层级关系。

如上所述，锁图由(N，E)给出。N的每个元素是对应于Java^TM程序中的对象的一组锁。令v∈N以及w＝{w₁，w₂，...，w_m}∈N，则如果程序中存在这样的执行路径，对于该执行路径线程已经获得了至少锁集合v并请求集合w，那么，  (v，w₁)∈E，i＝1，......，m。

如果Java^TM程序有n个锁，则理论上存在2ⁿ个节点，对应于n个元素的所有可能的子集。然而，可以忽略孤立的节点，即没有边离开或进入的节点。在实践中，该图被递增地构建，随着锁集合和边在程序路径的遍历中出现而添加锁集合和边，且节点数量远远少于理论最大值。

现参照图2，一流程图示出了根据本发明实施例的锁图计算方法。这可以看作是图1中的方框104的详细描述。锁图的构建在两个阶段中进行。在方框202中，结合例如G.B.Leeman等人在“Detecting UnwantedSynchronization in Java Programs”(Tech.Rep.RC 22552，IBM ThomasJ.Watson Research Center，Yorktown Heights，New York，Sept.2002)中介绍的锁集合计算算法，构建节点和边的集合。如同下面将详细介绍的那样，锁图计算利用在调用图的每个节点上起作用以及在每个基本块中的、计算得到的锁集合来构建锁图中的节点和边的集合。在方框204中，被称为后处理的第二步骤对图的定义进行精练。

锁被定义为对(o，c)，其中，o为Java^TM程序中的对象，c，即计数器，是界限为固定常数Ω的正整数。锁集合是锁的汇集，其中，所有的对象o是不同的。在Java^TM程序的调用图模型中，Java^TM对象的总数量是有限的。因此，对于该程序，可能的不同锁集合的数量是有限的。

给定锁集合m，加法(+)—其对应于monitorenter—被定义如下：

●如果对于某些c，(o，c)∈m，则用(o，min(c+1，Ω))代替m中的(o，c)；

●否则，将(o，1)添加到m。

结果得到的集合为m+o。

对于集合m与锁(o，c)的并集(∪)，

●如果o没有出现在m的任何锁对象中，则将(o，c)添加到m；

●如果(o，d)∈m，d＜c，则在m中用(o，c)替代(o，d)；

●如果(o，d)∈m，d＝c，则m保持不变。

结果得到的集合为m∪(o，c)。

通过为每个o∈m₂计算m₁(+或∪，将+和∪扩展到两个集合m₁和m₂上的操作。

实际上，计数器的使用很少在字节码中出现。因此，可设置Ω＝1的条件。

并集操作表示这样的事实，即调用图后继节点继承了其前驱的锁集合：如果节点i有锁集合m_i，i＝1，2，且节点2为节点1的后继，那么在计算中的某点上，将用m₁∪m₂来代替m₂。

现参照图3，提供了根据本发明实施例的锁集合构建方法。这可被看作图2中的方框202的详细描述。在该定点算法中，节点和边指调用图的部分。为Java^TM程序的每个线程执行该方法；开始节点是线程的start()方法，且首先用所有从其start()节点可到达的节点形成线程闭包集合(closure set)。

该方法最初的四个步骤为初始化。步骤1初始化空的锁集合和空的图。步骤2初始化用于具有同步的块的节点的所有结构，所述同步的块记录了哪些基本块包含monitorenters和monitorexits。步骤3基于同步的方法初始化所有锁集合，具体而言，基于同步的方法为节点和边计算锁集合的初始值。步骤4将开始值放入队列。“空”的锁图实际上有表示空锁集合的一个节点(节点0)。

主循环在该方法的步骤5至15中提供。在步骤7中计算当前锁集合，如果必要，更新锁图。无论何时请求了新的锁，可添加新的顶点和边。步骤8执行过程内分析，以便确定基本块和边的锁集合，参见例如G.B.Leeman等。再一次地，这一步骤可能使更新锁图成为必要。最后，步骤9至15执行过程间分析，以便为离开当前节点的各边计算锁集合，步骤10。如果后继节点的锁集合被改变，步骤11-14，则将后继节点添加到当前路径，并将它们放入队列，步骤15。出于报告目的，路径由锁图保持。

如图2中的方框204中描述的通过后处理对图的定义进行精练涉及对当前顶点集合进行检查，以生成额外的边。应记得，第一阶段在每个线程上运行，从而可能产生新的锁图节点和边。如果线程t产生边(p(t)，s(t))，那么，某些执行路径获得至少前驱集合p(t)中的锁，并请求后继集合s(t)中的锁。类似地，假设第二线程t′产生边(p(t′)，s(t′))。条件p(t)∩p(t′)≠φ表示不会发生的情况，因为Java^TM线程和锁满足互斥属性。然而，p(t)∩p(t′)＝φ，那么可创建可能感兴趣的额外边。也就是说，对于p(t)中的每个锁m，产生新的节点{m}(除非该节点已经存在)以及从{m}到s(t)的边(除非这一边已经存在)；为p(t′)进行类似的操作。因此，方框204包括线程的成对检查以及经由该过程的额外节点和边的创建。

经典的哲学家就餐问题可用于描述本发明的实施例，例如参见A.Silberschatz等人的“Operating System Concepts”(sixth ed.，JohnWiley & Sons，Inc.New York，New York，2002)。现参照图4，示出了用于经典的哲学家就餐问题的Java^TM代码，该问题有四位哲学家和五支筷子，其中，哲学家需要两支筷子(资源)来进餐，最终导致死锁。

图4中的Java^TM代码的行44-49创建了五个哲学家对象，三个参数分别表示哲学家名字、他左边的筷子以及他右边的筷子。筷子用行2-6中的字符串表示。每位哲学家也是一个线程(行1)，线程在行50-54开始，这使得运行方法(行15-39)被执行。该方法对每位哲学家的行为建模：他坐在分配给他的两支筷子之间(行16)，并然后进入思考-拿起-进餐的循环(行18-34)，其中，每个动作占用随机大小的时间。在该循环中，他思考(行19-20)，拿起他左边的筷子(行21-24)，拿起他右边的筷子(行25-28)，并进餐(行29-33)。Java^TM同步块反映了筷子的互斥、等待以及非抢占属性。当运行此程序时，迅速达到死锁。

根据本发明的实施例，通过JaBA，对象用以下形式的列表表示：

                      index type class

                          method

                   programCounter surceLine

例如，筷子1对象被表示为：

                  14 NewSite Philosopher

             Philosopher.main([java.lang.String])

                          PC 0 SL 2

索引是分配给每一对象的唯一号码。如果源代码不可用，源行条目为-1。就餐哲学家问题的重要对象全都具有同样的类型、类、类加载器以及方法。索引、程序计数器和源行号码在图5中的表中示出。另外，就餐哲学家示例的一部分调用图在图6中示出。所提供的示例具有11个锁(5位哲学家，5支筷子和Math锁)，但存在远远少于2¹¹个的节点，具体为22个节点和40个边。

可以为就餐哲学家示例跟踪第一阶段的进展。存在五个开始节点(行50-54)，其中，应用图3中的方法。注意，start()实际上是这样的形式：

                   public synchronized native

                     java.lang.Thread.start

因此，根据本发明实施例，对于每个开始节点，图3中的步骤7引起锁图中的节点16、1、19、7和12的创建，如图7中所示。这些整数对应于图5的表中的索引。另外，形成了五个边：

(0，1)，(0，7)，(0，12)，(0，16)，(0，19)

这意味着，线程获得至少没有锁(节点0)并请求单个锁，来运行开始方法。

start()的后继是run方法。图3中的步骤8执行的图4中行22的处理引起图7的锁图中新的锁图节点14、2、4、8和10的创建，它们对应于图5的表中的五个筷子对象。还存在新的边：

(16，14)，(1，2)，(19，4)，(7，8)，(12，10)，

特别是从行45(16，14)表示start()获得至少frege锁(16)并接着在行22请求chopstick1锁(14)。类似地，当分析行26时，创建新的锁集合和Java^TM锁图节点：

17＝{16，14}，3＝{1，2}，20＝{19，4}，9＝{7，8}，13＝{12，10}

接着创立边：

(17，2)，(3，4)，(20，8)，(9，10)，(13，14)，

例如，在获取至少frege和chopstick1锁{{16，14}，到17的集合}之后，请求chopstick2(2)，导致产生边(17，2)。

由于各种内建方法的签名，经常产生意料之外的节点。在我们的示例中，random方法(行41)调用initRNG，其具有签名：

                  private static synchronized

                 java.lang.Math.initRNG()V}

因此，存在新的锁，该锁由Math类的类对象组成，并生成具有三个元素(哲学家，筷子和Math锁)的锁集合，以及额外的节点和边。然而，由于它们不使人感兴趣，未对它们进行讨论。

图2中的方框204不创建任何新的顶点。然而，哲学家frege线程产生边(17，2)，哲学家hegel线程产生边(3，4)。集合17和3是不相交的，故方框402提出新的边({16}，2)、({14}，2)、({1}，4)和({2}，4)，这在我们的标记法中与(16，2)、(14，2)、(1，4)和(2，4)是一样的。边(1，4)已经存在，但其他三个是新的。不难判断，哲学家kant和mill产生新的边(4，8)、(7，10)、(8，10)，哲学家plato和任何其他哲学家对象产生两个新的边(10，14)和(12，14)。从具有三个元素的锁集合中还产生了更多的边，这些在本说明性示例中没有处理。

在就餐哲学家示例中，正好发现一个循环：

2→4→8→10→14→2

在图8中，提供了根据本发明实施例为就餐哲学家示例所产生的输出的示例。

当Java^TM锁图具有循环时，对信息进行报告，且用户可使用该信息判断是否存在死锁。由于静态分析经常产生假的肯定，必须检查每个输出汇集。当图中没有循环时，该状况是没有死锁的强烈证据。用户能够观察所分析的线程，以便查看死锁不存在。通常，静态分析不能遍历所有可能的程序执行，且在Java^TM中，例如反射(reflection)等动态特征使该问题更加恶化。

D.Lea在“Concurrent Programming in Java Design Principles andPatterns”(Addison-Wesley，Reading，MA，1997)中提供了两路(two-way)死锁的简单示例。也可参见C.Demartini等人的“A Deadlock DetectionTool for Concurrent java Programs”(Software-Practice and Experience29，7，June 1999，pp.577-603)。然而，这些参考文献提供了相对复杂的分析。本发明的实施例通过生成仅具有7个节点、10个边和1个循环的锁图，提供了特别简单的分析。正好两个节点v和w有这样的属性：(v，w)和(w，v)均为边，从而产生循环和死锁。尽管本发明的实施例已在分析Java^TM代码的情境中示出，它们可应用于支持监视器的任何语言。

现参照图9，框图示出了一计算系统的示例性硬件实现，根据本发明的一实施例的，可根据该计算系统实现本发明的一个或多个组件/方法(例如在图1-8的情境中介绍的组件/方法)。

如图所示，计算机系统可根据经由计算机总线918或其他连接装置耦合的处理器910、存储器912、I/O设备914以及网络接口916实现。

应当理解，这里所用的术语“处理器”旨在包括任何处理装置，比如，举例来说，包括CPU(中央处理单元)和/或其他处理电路的处理装置。还应理解，术语“处理器”可以指一个以上的处理装置，且与一处理装置相关联的各元素可以与其他处理装置共享。

这里所用的术语“存储器”旨在包括与处理器或CPU相关联的存储器，比如，举例来说，RAM、ROM、固定存储设备(例如硬盘驱动器)、可拆装存储设备(例如磁盘)、闪速存储器等。

另外，这里所用的短语“输入/输出设备”或“I/O设备”包括例如用于向处理单元输入数据的一个或多个输入设备(例如键盘、鼠标、扫描仪、摄像机等)，和/或用于呈现与处理单元相关联的结果的一个或多个输出设备(例如扬声器、显示器、打印机等)。

另外，这里所用的“网络接口”旨在包括例如一个或多个收发器，所述收发器允许计算机系统经由合适的通信协议与其他的计算机系统通信。

包括用于执行这里所介绍的方法的指令或代码的软件组件可存储在一个或多个关联的存储设备(例如ROM、固定存储器或可拆装存储器)中，且当准备使用时，部分或全部装载(例如装载到RAM)并由CPU执行。

这里介绍的本发明实施例提供了一种自动方法，该方法用于检测支持监视器概念以获得同步的语言中的死锁。它既为源代码也为字节码工作，因为前者可被编译为后者，而后者被分析。不需要代码注释。

尽管这里参照附图介绍了本发明的说明性实施例，可以理解，本发明不限于这些具体实施例，并且在不脱离本发明的范围或精神的情况下，本领域技术人员可进行各种各样的其他改变和更改。

Claims (27)

1.一种检测多线程程序中的死锁的方法，该方法包括以下步骤：

构建调用图，所述调用图具有对应于以所述多线程程序的代码编写的、一个或多个函数的一个根以及多个节点；

根据在所述调用图的每个节点上起作用的、一个或多个资源集合，计算资源图；以及

判断在所述资源图的两个或更多个节点之间是否存在循环，其中，循环是所述多线程程序中死锁的指示。

2.根据权利要求1的方法，其中，所述多线程程序包括Java^TM程序。

3.根据权利要求1的方法，其中，在所述构建调用图的步骤中，每个节点包括以所述多线程程序的代码编写的函数的控制流图的基本块，以及资源被访问和释放的位置。

4.根据权利要求1的方法，其中，在所述构建调用图的步骤中，每个连接两个节点的边对应于从以所述多线程程序的代码编写的一函数内部对以所述多线程程序的代码编写的另一函数的调用。

5.根据权利要求1的方法，其中，在所述构建调用图的步骤中，所述调用图允许节点之间的双向遍历，以便确定前驱节点和后继节点的集合。

6.根据权利要求1的方法，其中，所述构建调用图的步骤包括执行数据流分析的步骤。

7.根据权利要求1的方法，其中，在所述构建调用图的步骤中，所述调用图中的每个节点可由一调用上下文标识。

8.根据权利要求7的方法，其中，所述调用上下文包括目标函数、一组可能的接收者类型以及参数类型中的至少一个。

9.根据权利要求1的方法，其中，在所述计算资源图的步骤中，资源包括对象和计数器，且资源集合包括具有不同对象的资源。

10.根据权利要求1的方法，其中，所述计算资源图的步骤包括以下步骤：

根据在所述调用图的每个节点上起作用的资源集合，构建节点和边的集合；以及

通过后处理，对所述资源图的定义进行精练。

11.根据权利要求10的方法，其中，所述构建节点和边的集合的步骤包括以下步骤：

由所述调用图计算第一资源集合；

随着资源被请求，添加边；

为离开所述第一资源集合的节点的每个边计算资源集合；

在每一步骤后根据需要更新所述资源图；以及

为每一新创建的资源集合重复所述计算第一资源集合、添加边、计算资源集合以及更新所述资源图的步骤。

12.根据权利要求10的方法，其中，对所述锁图的定义进行精练的所述步骤包括检查当前的顶点集合以生成额外的边的步骤。

13.根据权利要求1的方法，还包括报告任何循环以及所关联的路径信息的步骤。

14.一种用于检测多线程程序中的死锁的装置，包括：

存储器；以及

至少一个处理器，该处理器耦合到所述存储器并可运行以执行以下操作：(i)构建调用图，所述调用图具有对应于以所述多线程程序的代码编写的、一个或多个函数的一个根以及多个节点；(ii)根据在所述调用图的每个节点上起作用的、一个或多个资源集合，计算资源图；以及(iii)判断在所述资源图的两个或更多个节点之间是否存在循环，其中，循环是所述多线程程序中死锁的指示。

15.根据权利要求14的装置，其中，所述多线程程序包括Java^TM程序。

16.根据权利要求14的装置，其中，在所述构建调用图的操作中，每个节点包括以所述多线程程序的代码编写的函数的控制流图的基本块，以及资源被访问和释放的位置。

17.根据权利要求14的装置，其中，在所述构建调用图的操作中，每个连接两个节点的边对应于从以所述多线程程序的代码编写的一函数内部对以所述多线程程序的代码编写的另一函数的调用。

18.根据权利要求14的装置，其中，在所述构建调用图的操作中，所述调用图允许节点之间的双向遍历，以便确定前驱节点和后继节点的集合。

19.根据权利要求14的装置，其中，所述构建调用图的操作包括执行数据流分析的步骤。

20.根据权利要求14的装置，其中，在所述构建调用图的操作中，所述调用图中的每个节点可用调用上下文标识。

21.根据权利要求20的方法，其中，所述调用上下文包括目标函数、一组可能的接收者类型以及参数类型中的至少一个。

22.根据权利要求14的装置，其中，在所述计算资源图的操作中，资源包括对象和计数器，且资源集合包括具有不同对象的资源。

23.根据权利要求14的装置，其中，所述计算资源图的操作包括以下步骤：

根据在所述调用图的每个节点上起作用的所述资源集合，构建节点和边的集合；以及

通过后处理，对所述资源图的定义进行精练。

24.根据权利要求23的装置，其中，所述构建节点和边的集合的步骤包括以下步骤：

由所述调用图计算第一资源集合；

随着资源被请求，添加边；

为离开所述第一资源集合的节点的每个边计算资源集合；

在每个步骤后根据需要更新所述资源图；以及

为每一新创建的资源集合重复所述计算第一资源集合、添加边、计算资源集合以及更新所述资源图的步骤。

25.根据权利要求24的装置，其中，对所述锁图的定义进行精练的所述步骤包括对当前的顶点集合进行检查以产生额外的边的步骤。

26.根据权利要求14的装置，还包括报告任何循环以及所关联的路径信息的操作。

27.一种用于检测多线程程序中的死锁的制造物品，该制造物品包括机器可读的介质，该机器可读的介质包含有一个或多个程序，所述程序在被执行时实现以下步骤：

构建调用图，所述调用图具有对应于以所述多线程程序的代码编写的、一个或多个函数的一个根以及多个节点；

根据在所述调用图的每个节点上起作用的一个或多个资源集合，计算资源图；以及

判断在所述资源图的两个或更多个节点之间是否存在循环，其中，循环是所述多线程程序中死锁的指示。

Images