A deadlock detection method and apparatus

Abstract

The application discloses a deadlock detection method and device, the method comprises the following steps: collecting information of all classes in a project; acquiring all possible method call chains in the project; screening out method call chains with locks; establishing a method call chain set corresponding to each lock; comparing and analyzing all method call chains in the method call chain set corresponding to each lock, taking the lock corresponding to the method call chain set as one of the cross locks, and determining whether there is another cross lock; if there is a cross lock, the compared two method call chain information is handed over to the developer for confirmation. The deadlock detection method and device provided by the application can realize deadlock detection in the project development and compilation stage, effectively find the deadlock logic code in the project, avoid discovering the deadlock after the project runs and causing a major operation accident, has high accuracy in deadlock detection, and saves development resources and development time.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a deadlock detection method and apparatus. Background Technology

[0002] Deadlock refers to a situation where two or more threads are blocked during execution due to competition for resources. Taking Java projects as an example, there are currently two main methods for deadlock detection:

[0003] Method 1: After the project starts running, each running resource has an address in memory. When a thread locks a resource, it acquires the lock for that resource. The Java object header contains lock-related information such as the type pointer. Other threads that want to acquire the lock for that resource must wait for the lock to be released by the previous thread. This phenomenon of competing for the same resource address is used to detect deadlocks.

[0004] Method 2: After the project is running, build and manage information related to the duration and frequency of each thread's task execution. When the execution duration and frequency of a task are abnormal, it can be initially detected as a deadlock.

[0005] Method 1 commonly uses JDK's built-in detection tools, which are complex to code and currently only detect synchronized locks, not Locks. Method 2 detects deadlocks by analyzing thread execution duration and frequency, but requires high customization and may produce false results; if execution fails, it could indicate an infinite loop or a deadlock. Furthermore, both methods require deadlock detection and localization after the project is running. If a deadlock occurs after project launch, handling it consumes significant human and time resources and can cause serious damage to the system, compromising its security and stability. Summary of the Invention

[0006] The purpose of this invention is to provide a deadlock detection method and apparatus that can solve one or more of the problems in the prior art.

[0007] According to a first aspect of the present invention, a deadlock detection method is provided, comprising the following steps:

[0008] Collect information on all classes in the project;

[0009] Analyze the information of all classes collected to obtain the method call chain that may be executed in the project;

[0010] Analyze the lock information in the method call chain and filter out the method call chains with locks;

[0011] Analyze the method call chains with locks and establish a set of method call chains corresponding to each lock;

[0012] For each lock, perform pairwise comparison analysis of all method call chains in the method call chain set, and use the lock corresponding to the method call chain set as one of the cross locks to determine whether there is another cross lock;

[0013] If cross-locking exists, the information of the two method call chains being compared will be submitted to the developers for confirmation.

[0014] In one possible implementation, information about all classes in the project can be collected by building an annotation processor.

[0015] In a possible implementation, the information of all classes collected is analyzed to obtain all possible method call chains that may be executed in the project, including:

[0016] Based on the information of all classes collected, each method in each class is scanned and analyzed to obtain the analysis result object of each method. The analysis result object is encapsulated with the class name of the method, the method name, and the class name of the method parameters as identity strings.

[0017] Iterate through the analysis result objects of all methods and remove duplicate analysis result objects;

[0018] Iterate through the deduplicated analysis result objects, perform secondary analysis on each analysis result object, and obtain all possible method call chains that can be executed in the project.

[0019] In a possible implementation, a secondary analysis is performed on each analysis result object, including:

[0020] A method to determine whether there is an inheritance relationship among the objects in the analysis results;

[0021] If methods with inheritance relationships exist, the analysis result object is expanded into multiple method call chains through splitting;

[0022] If there are no methods with inheritance relationships, the analysis result object is directly used as a method call chain.

[0023] According to a second aspect of the present invention, a deadlock detection apparatus is provided for implementing any of the above-described deadlock detection methods, comprising:

[0024] The class information collection module is used to collect information about all classes in the project.

[0025] The method call chain generation module is used to analyze the information of all collected classes and obtain the method call chain that may be executed in the project.

[0026] The method call chain filtering module is used to analyze the lock information in the method call chain and filter out the method call chains with locks.

[0027] The module for establishing the method call chain set corresponding to a lock is used to analyze the method call chain of a lock and establish the method call chain set corresponding to each lock.

[0028] The cross lock determination module is used to perform pairwise comparison analysis on all method call chains in the method call chain set corresponding to each lock, and to determine whether there is another cross lock by taking the lock corresponding to the method call chain set as one of the cross locks.

[0029] The deadlock handling module is used to provide the developers with confirmation of the information of the two method call chains when cross locks exist.

[0030] In a possible implementation, the class information acquisition module includes an annotation processor for acquiring information about all classes in the project.

[0031] In a possible implementation, the method call chain generation module includes:

[0032] The analysis result object generation submodule is used to scan and analyze each method in each class based on the information of all classes collected, and obtain the analysis result object of each method. The analysis result object is encapsulated with the class name of the method, the method name, and the class name of the method parameters as identity strings.

[0033] The analysis result object deduplication submodule is used to traverse the analysis result objects of all methods and remove duplicate analysis result objects;

[0034] The method call chain determination submodule is used to traverse the deduplicated analysis result objects, perform secondary analysis on each analysis result object, and obtain the method call chain that can be executed in the project.

[0035] In a possible implementation, the method call chain determination submodule includes:

[0036] The method judgment unit is used to determine whether there are methods with inheritance relationships in the analysis result object. If there are no methods with inheritance relationships, the analysis result object is directly used as a method call chain.

[0037] The split extension unit is used to split and extend the analysis result object into multiple method call chains when there are methods with inheritance relationships in the analysis result object.

[0038] According to a third aspect of the present invention, an apparatus is provided, the apparatus comprising a processor and a memory, the memory storing at least one instruction, at least one program, a code set or an instruction set, wherein the at least one instruction, at least one program or instruction set is loaded and executed by the processor to implement any of the above deadlock detection methods.

[0039] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, wherein at least one instruction, at least one program, code set, or instruction set is stored therein, and the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the deadlock detection method of any of the above claims of the present invention.

[0040] The deadlock detection method and apparatus provided by this invention obtains class information in the project and analyzes all possible method call chains that can be executed in the project. By constructing a set of method call chains corresponding to locks, and comparing each pair of method call chains in the set, the method call chains are compared to determine whether cross locks exist. This enables deadlock detection during the project development and compilation phase, effectively discovering all deadlocks in the project and avoiding major operational accidents caused by discovering deadlocks only after the project has run. The deadlock detection accuracy is high, and it can detect locks related to Synchronized and Lock. At the same time, by acquiring and analyzing various information in the source code, the method can also detect project coding standards while detecting deadlocks, saving various development resources and time.

[0041] In addition, unless otherwise specified, all aspects of the technical solution of this invention can be implemented by conventional means in the field. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a flowchart illustrating the deadlock detection method provided in Embodiment 1 of the present invention.

[0044] Figure 2 This is a structural block diagram of the deadlock detection device provided in Embodiment 2 of the present invention.

[0045] Figure 3 This is a schematic diagram of the device for performing the deadlock detection method provided in Embodiment 3 of the present invention. Detailed Implementation

[0046] The terms "first," "second," etc., used in this specification and claims are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, systems, products, or devices.

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] The following examples use a JAVA-compiled project as an example to illustrate the technical solutions in the embodiments of the present invention.

[0049] Example 1:

[0050] Reference manual attached Figure 1 This invention provides a deadlock detection method, which includes the following steps:

[0051] S101: Collect information on all classes in the project.

[0052] In an alternative implementation, information about all classes in the project can be obtained by constructing an annotation processor that traverses all classes in the project.

[0053] Taking a Java-compiled project as an example, an annotation processor can be built using the following methods:

[0054] Create a Maven project;

[0055] Create an annotation processor class that inherits from javax.annotation.processing.AbstractProcessor and implement the init method;

[0056] Build the META-INF.services directory;

[0057] Specify the correct annotation processor classpath.

[0058] This enables the creation of an annotation processor. By implementing the corresponding detection logic in the process method, the annotation processor can be used to traverse all classes in the project and collect information about all classes in the project.

[0059] Specifically, after traversing all classes in the project, the collected information for all classes can include: the base class and interface information inherited by each class; reference information in each class; member attribute information in the class, including attribute variable names and the class information pointed to by the attribute types; all methods in the class; overloading and overriding information of methods in the class and the class pointed to by the return type of methods in the class; and declaration and definition information of Lock variables in the class, such as variable name, variable class, Lock type, etc. Therefore, by obtaining relevant information of all classes in the project, especially Lock-related information, the deadlock detection method of this application can simultaneously detect synchronized and Lock-related locks, improving the accuracy of deadlock detection, avoiding deadlocks after project execution due to the inability to detect Lock-related locks, improving detection efficiency, and saving operating costs.

[0060] It should be understood that the information on the classes listed above is for illustrative purposes only. In actual projects, information on classes other than those listed above may be involved.

[0061] In an optional embodiment, the collected member attribute information of the class can be encapsulated and saved using the class name and package name of the attribute as keys.

[0062] S102: Analyze the information of all classes collected to obtain the method call chain that may be executed in the project.

[0063] In an optional embodiment, the information of all classes collected is analyzed by an annotation processor to obtain the method call chain that may be executed in the project.

[0064] Specifically, the information of all collected classes is analyzed to obtain the method call chain that may be executed in the project, including:

[0065] S201: Based on the information of all classes collected, scan and analyze each method in each class to obtain the analysis result object of each method. The analysis result object is encapsulated with the class name of the method, the method name, and the class name of the method parameters as identity strings.

[0066] In an alternative embodiment, a task listener can be added to the annotation processor to enable scanning and analysis of each method in each class.

[0067] Specifically, scanning and analyzing each method in each class involves first converting each class into a JCTree syntax tree, then obtaining lock information on the methods and analyzing the method body code blocks. When analyzing the method body code blocks, the code can be analyzed line by line to obtain the necessary information within the analysis result object.

[0068] Specifically, each method in each class is scanned and analyzed, and the analysis results are encapsulated into an analysis result object. The analysis result object of each method takes itself as the main method. The information in the analysis result object corresponding to each method can include: the class of the formal parameters of the main method; the class of the variables in the main method; the lock information on or within the main method, such as what kind of lock it is and what content it locks; and the information of the classes of other methods called by the main method and other methods.

[0069] Specifically, when analyzing the code block of a method body, if the main method calls another static method, the information of the class to which that method belongs can be obtained directly. However, if the main method calls another object method, the information of the class to which that method belongs cannot generally be obtained directly from the code block; only the variable name corresponding to that method can be obtained. Since S101 can encapsulate the obtained member attribute information of the class, including the attribute variable name and the class information pointed to by the attribute type, using the class name and package name of the attribute as keys, the information of the class to which the method belongs can be located based on the obtained variable name of the called method.

[0070] Meanwhile, since S101 can encapsulate the class information pointed to by the attribute variable name and the attribute type using the class name and package name of the attribute as keys, the class to which the variable in the main method belongs can also be recorded in the analysis result object using the class name and package name of the attribute corresponding to the variable as identity markers.

[0071] In an optional embodiment, other methods called by the main method involved in the analysis result object are recorded in the analysis result object corresponding to the main method, using the address of the analysis result object corresponding to the called method.

[0072] Each method's analysis result object is uniquely identified by the class name of the main method, the method name of the main method, and the class names of the parameters of the main method. The class name (full package name) contains the package path, and the method name contains the parameters. The analysis result object can also include several lists; the addresses of multiple called analysis result objects can be stored in one list, and multiple lock information from the main method or within the main method can be stored in another list.

[0073] In S201, each analysis result object can be viewed as a method call chain. For example, consider an analysis result object T that analyzes method 'a' of class A. If method 'a' calls method 'b' of class B, and the analysis result object corresponding to method 'b' is U, since the analysis result object is uniquely encapsulated with the class name of the main method, the main method name, and the class names of the method parameters when analyzing various methods (whether the main method or other methods called by the main method), the analysis result object T of method 'a' holds the address of the analysis result object U corresponding to method 'b'. Therefore, the presence of analysis result object U in analysis result object T can be seen as T (method a) calling U (method b). Thus, analysis result object T represents a method call chain, i.e., method a calling method b. Therefore, each analysis result object is essentially a method call chain.

[0074] S202: Traverse the analysis result objects of all methods and remove duplicate analysis result objects;

[0075] Specifically, assuming there are three methods a, b, and c, where a calls b, and b calls c, there are three analysis result objects A, B, and C corresponding to these methods. The method call chain in analysis result object A is a->b->c, and in analysis result object B it is b->c. Since method c in object C does not call any other methods, its method call chain is simply the method c. Therefore, analysis result object B contains the method call chain of analysis result object C. Thus, for both analysis result objects B and C, only the method call chain of analysis result object B needs to be checked. Similarly, analysis result object A contains the method call chains of both analysis result objects B and C, so only analysis result object A needs to be checked. Analysis result objects B and C, being duplicates, can be removed. Therefore, by removing duplicate analysis result objects, detection time is effectively reduced, and detection efficiency is improved.

[0076] S203: Traverse the deduplicated analysis result objects, perform secondary analysis on each analysis result object, and obtain the method call chain that can be executed in the project.

[0077] In an optional embodiment, a secondary analysis is performed on each analysis result object, including:

[0078] A method to determine whether there is an inheritance relationship among the objects in the analysis results;

[0079] If methods with inheritance relationships exist, the analysis result object is expanded into multiple method call chains through splitting;

[0080] If there are no methods with inheritance relationships, the analysis result object is directly used as a method call chain.

[0081] Specifically, since the methods in the analysis result object exist in the form of the address of the analysis result object corresponding to the method, it is necessary to determine whether there are methods with inheritance relationships in the current analysis result object, that is, to determine whether there is an inheritance relationship between the method corresponding to the current analysis result object and the methods corresponding to other analysis result objects called by the current analysis result object.

[0082] For example, if there are two methods, a and b, and a calls b, then there are two analysis result objects, A and B, corresponding to methods a and b. In this case, the method call chain in analysis result object A is a->b. Assuming that method b is a parent class method with three corresponding subclass methods b1, b2, and b3, then we can judge the current analysis result object A. If there is an analysis result object B corresponding to the method b with inheritance relationship in analysis result object A, then the current analysis result object will be split into three method call chains, namely a->b1, a->b2, and a->b3.

[0083] The purpose of performing secondary analysis on the analysis results is to split and expand the methods with inheritance relationships to obtain all the method call chains that may be executed after the project runs. This provides more comprehensive and complete data information for subsequent cross-lock comparison of method call chains, improves the accuracy of deadlock detection, and avoids missed deadlocks.

[0084] In an optional embodiment, in S101 and S102, information on all classes and methods in the project can be obtained and analysis results generated by analyzing the compiled class files of the project's source code.

[0085] In an optional embodiment, in S101 and S102, the source code of the project can be analyzed using the PSI technology of the IDEA plugin to obtain information on all classes and methods in the project and generate analysis results. Therefore, analyzing classes and methods in the project using the PSI technology of the IDEA plugin enables alerts to be issued for cross-lock logic during the developer's real-time compilation process, and the location of cross-locks is indicated to the developer, improving detection efficiency.

[0086] S103: Analyze the lock information in the method call chain and filter out the method call chains with locks.

[0087] Therefore, by filtering the method call chains and selecting the locked method call chains, the detection time can be effectively reduced, resources can be avoided, and detection efficiency can be improved.

[0088] S104: Analyze the method call chains with locks and establish a set of method call chains corresponding to each lock.

[0089] Specifically, a method call chain set is established according to the lock information, and each method call chain involving the lock is placed into the method call chain set corresponding to the lock.

[0090] S105: Perform pairwise comparison analysis on all method call chains in the method call chain set corresponding to each lock, and take the lock corresponding to the method call chain set as one of the cross locks to determine whether there is another cross lock.

[0091] In this invention, cross-locking refers to a situation where one method call chain holds lock 1 and waits for lock 2, while another method call chain holds lock 2 and waits for lock 1. Therefore, if cross-locking exists, a deadlock can be preliminarily determined.

[0092] For example, if the method call chain set corresponding to lock 1 contains three method call chains P, Q, and R, then compare and analyze P and Q, P and R, and R and Q respectively to determine whether there is another cross lock.

[0093] When determining whether a lock is cross-locked, regardless of whether the lock actually locks a class instance or the class itself, all locked content can be treated as the class itself, effectively downgrading a class instance to the class itself. This solves the problem that compile-time lock analysis can only reach the class level and not class instances, while also preventing missed deadlocks.

[0094] S106: If cross locks exist, the information of the two method call chains being compared will be submitted to the developers for confirmation.

[0095] In an optional implementation, when cross-locking exists, the comparison of the two method call chains is submitted to the developer for confirmation, including:

[0096] If a deadlock does exist, the two method call chains being compared will be marked as alarms, which can prompt developers to make modifications.

[0097] If no deadlock exists, the two method call chains being compared are ignored, thus allowing the cross lock to be ignored during subsequent checks, avoiding redundant checks and wasting resources.

[0098] When a deadlock does exist, since the method call chain itself is the call chain of runtime threads executing methods, developers can easily locate the method call relationship and find the lock block code, which facilitates the subsequent handling of the deadlock.

[0099] The deadlock detection method provided by this invention obtains class information from the project and analyzes all possible method call chains that can be executed in the project. By constructing a set of method call chains corresponding to locks, and comparing each pair of method call chains in the set, the method call chains are compared to determine whether cross locks exist. This enables deadlock detection during the project development and compilation phase, effectively discovering all deadlocks in the project and enabling rapid deadlock location, avoiding major operational accidents caused by discovering deadlocks only after the project has started running. The deadlock detection accuracy is high, and it can detect locks related to Synchronized and Lock. At the same time, by obtaining and analyzing various information in the source code, the method can also detect project coding standards while detecting deadlocks, saving various development resources and time.

[0100] Example 2:

[0101] In this embodiment, please refer to the appendix to the specification. Figure 2 A deadlock detection device is provided for implementing any deadlock detection method in the above method embodiments. The deadlock detection device includes at least:

[0102] Class information collection module 11 is used to collect information on all classes in the project.

[0103] The method call chain generation module 12 is used to analyze the information of all collected classes and obtain the method call chain that may be executed in the project.

[0104] The method call chain filtering module 13 is used to analyze the lock information in the method call chain and filter out the method call chains with locks.

[0105] The lock-corresponding method call chain set establishment module 14 is used to analyze the method call chain of the lock and establish the method call chain set corresponding to each lock;

[0106] The cross lock judgment module 15 is used to perform pairwise comparison analysis on all method call chains in the method call chain set corresponding to each lock, and to determine whether there is another cross lock by taking the lock corresponding to the method call chain set as one of the cross locks.

[0107] Deadlock handling module 16 is used to hand over the information of the two method call chains being compared to the developer for confirmation when cross locks exist.

[0108] In an optional embodiment, the class information acquisition module includes an annotation processor for acquiring information about all classes in the project.

[0109] In an optional embodiment, the method call chain generation module includes:

[0110] The analysis result object generation submodule is used to scan and analyze each method in each class based on the information of all classes collected, and obtain the analysis result object of each method. The analysis result object is encapsulated with the class name of the method, the method name, and the class name of the method parameters as identity strings.

[0111] The analysis result object deduplication submodule is used to traverse the analysis result objects of all methods and remove duplicate analysis result objects;

[0112] The method call chain determination submodule is used to traverse the deduplicated analysis result objects, perform secondary analysis on each analysis result object, and obtain the method call chain that can be executed in the project.

[0113] In an optional embodiment, the method call chain determination submodule includes:

[0114] The method judgment unit is used to determine whether there are methods with inheritance relationships in the analysis result object. If there are no methods with inheritance relationships, the analysis result object is directly used as a method call chain.

[0115] The split extension unit is used to split and extend the analysis result object into multiple method call chains when there are methods with inheritance relationships in the analysis result object.

[0116] In an optional embodiment, the deadlock handling module includes:

[0117] The alert flagging submodule is used to flag an alert for the two method call chains being compared when developers confirm that a deadlock has indeed occurred.

[0118] The Ignore Flags submodule is used to mark two compared method call chains as ignored when developers confirm that no deadlock exists.

[0119] In a possible implementation, the deadlock detection device provided by the present invention can be a project, in which the project to be detected is placed into the deadlock detection device and the deadlock detection device is run to perform the detection; or the deadlock detection device provided by the present invention can be placed into the project to be detected in the form of a jar package, and the deadlock detection device will automatically perform the detection during compilation.

[0120] The deadlock detection device provided by this invention uses a class information acquisition module to obtain class information in the project, a method call chain generation module to analyze and obtain all possible method call chains that can be executed in the project, and a method call chain filtering module to filter out locked method call chains. A lock-corresponding method call chain set establishment module constructs a set of method call chains corresponding to locks, and a cross-lock judgment module compares each pair of method call chains in the set to determine whether cross-locks exist. This enables deadlock detection during the project development and compilation phase, effectively identifying all deadlocks in the project and enabling rapid deadlock location, avoiding major operational accidents caused by discovering deadlocks only after the project has run. The deadlock detection accuracy is high, and it can detect both synchronized and lock-related locks. Simultaneously, by acquiring and analyzing various information in the source code, it can also detect project coding standards while detecting deadlocks, saving various development resources and time.

[0121] Example 3:

[0122] Figure 3 This is a schematic diagram of the device for executing the deadlock detection method provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the device includes:

[0123] One or more processors 310 and memory 320, Figure 3 Take the 310 processor as an example.

[0124] The device for performing the deadlock detection method may further include an input device 330 and an output device 340.

[0125] The memory 320, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the deadlock detection method in the embodiments of this application. The processor 310 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 320, thereby implementing the deadlock detection method of the above-described method embodiments.

[0126] The memory 320 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the deadlock detection device. Furthermore, the memory 320 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 320 may optionally include memory remotely located relative to the processor 310, and these remote memories may be connected to the deadlock detection device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0127] Input device 330 can receive input digital or character information, and generate signal inputs related to user settings and function control. Output device 340 may include display devices such as a display screen.

[0128] One or more modules are stored in memory 320 and, when executed by one or more processors 310, execute the deadlock detection method in any of the above method embodiments.

[0129] The above-described product can execute the method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in this embodiment can be found in the method provided in Embodiment 1 of this application.

[0130] Example 4:

[0131] Embodiment 4 of the present invention provides a computer-readable storage medium storing one or more programs including execution instructions. The execution instructions can be read and executed by a device (including but not limited to a computer, server, or network device) to perform the relevant steps in the above method embodiments.

[0132] The order of the embodiments described above is for descriptive purposes only and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0133] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0134] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0135] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A deadlock detection method, characterized in that, Includes the following steps: Information about all classes in the project is collected by building an annotation processor. Analyze the information of all classes collected to obtain the method call chain that may be executed in the project; Analyze the lock information in the method call chain and filter out the method call chains with locks; Analyze the method call chains with locks and establish a set of method call chains corresponding to each lock; For each lock, perform pairwise comparison analysis of all method call chains in the method call chain set. Take the lock corresponding to the method call chain set as one of the cross locks and determine whether there is another cross lock. When determining the cross lock, the class instance object is downgraded to the class itself. If cross locks exist, the information of the two method call chains being compared will be handed over to the developers for confirmation. The information of the class includes the base class inherited by each class, interface information, reference information, member attribute information, all methods in the class, method overloading and overriding information, the class pointed to by the method return type, and the declaration and definition information of Lock variables in the class; The analysis of all collected class information to obtain all possible method call chains executed in the project includes: Based on the collected information of all classes, each method in each class is scanned and analyzed to obtain an analysis result object for each method. The analysis result object is encapsulated with the class name, method name, and class name of the method parameters as identity strings. When scanning and analyzing each method in each class, each class is converted into a syntax tree (JCTree), the lock information on the method is obtained, and the method body code block is analyzed line by line. The information in the analysis result object corresponding to each method includes: the class of the formal parameters of the main method; the class of the variables in the main method; the lock information on or within the main method; and the information of the classes of other methods called by the main method and other methods called by the main method. The other methods called by the main method involved in the analysis result object are recorded in the analysis result object corresponding to the main method with the address of the analysis result object corresponding to the called method. Iterate through the analysis result objects of all methods and remove duplicate analysis result objects; Iterate through the deduplicated analysis result objects, perform secondary analysis on each analysis result object, and obtain all possible method call chains that can be executed in the project. The secondary analysis of each analysis result object includes: A method to determine whether there is an inheritance relationship among the objects in the analysis results; If methods with inheritance relationships exist, the analysis result object is expanded into multiple method call chains through splitting; If there are no methods with inheritance relationships, the analysis result object is directly used as a method call chain.

2. A deadlock detection device, used to implement any of the deadlock detection methods according to claim 1, characterized in that, include: The class information collection module is used to collect information about all classes in the project. The method call chain generation module is used to analyze the information of all collected classes and obtain the method call chain that may be executed in the project. The method call chain filtering module is used to analyze the lock information in the method call chain and filter out the method call chains with locks. The module for establishing the method call chain set corresponding to a lock is used to analyze the method call chain of a lock and establish the method call chain set corresponding to each lock. The cross lock determination module is used to perform pairwise comparison analysis on all method call chains in the method call chain set corresponding to each lock, and to determine whether there is another cross lock by taking the lock corresponding to the method call chain set as one of the cross locks. The deadlock handling module is used to provide the developers with confirmation of the information of the two method call chains when cross locks exist.

3. The deadlock detection device according to claim 2, characterized in that, The class information acquisition module includes an annotation processor, which is used to collect information about all classes in the project.

4. The deadlock detection device according to claim 2, characterized in that, The method call chain generation module includes: The analysis result object generation submodule is used to scan and analyze each method in each class based on the information of all classes collected, and obtain the analysis result object of each method. The analysis result object is encapsulated with the class name of the method, the method name, and the class name of the method parameters as identity strings. The analysis result object deduplication submodule is used to traverse the analysis result objects of all methods and remove duplicate analysis result objects; The method call chain determination submodule is used to traverse the deduplicated analysis result objects, perform secondary analysis on each analysis result object, and obtain the method call chain that can be executed in the project.

5. The deadlock detection device according to claim 4, characterized in that, The method call chain determination submodule includes: The method judgment unit is used to determine whether there are methods with inheritance relationships in the analysis result object. If there are no methods with inheritance relationships, the analysis result object is directly used as a method call chain. The split extension unit is used to split and extend the analysis result object into multiple method call chains when there are methods with inheritance relationships in the analysis result object.

6. A deadlock detection device, characterized in that, The deadlock detection device includes a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, or the instruction set is loaded and executed by the processor to implement the deadlock detection method as described in claim 1.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the deadlock detection method as described in claim 1.

Images