Method and apparatus for detecting abnormal use of lock resources

Abstract

Embodiments of the present application provide a method and device for detecting abnormal use of lock resources, wherein the method comprises: obtaining a lock branch tree of each thread in a target process, wherein each lock branch in the lock branch tree is used for recording an order in which the corresponding thread acquires lock resources in a historical time; determining whether the target process will form a lock loop according to the lock branch tree of each thread; and in the case of determining that the target process will form a lock loop, determining that a thread in the target process has a logic of causing a deadlock. Through the present application, the problem that the reliability of process running is not high due to the inability to predict whether there is a deadlock risk in the process in the related art is solved.

Description

Technical Field

[0001] The present invention relates to the field of software programming technology, and more specifically, to a method and apparatus for detecting abnormal use of lock resources. Background Technology

[0002] In software program bugs, the improper use of locks is a very serious and frequent problem. Improper lock usage can lead to deadlocks, which occur when two or more threads compete for resources and thus wait for each other. Without external intervention, they cannot proceed, and these threads that are perpetually waiting for each other are called deadlocked threads. If a program deadlock occurs, it will render the product unusable and irreversible, often requiring a restart to resolve.

[0003] In existing technologies, deadlock can only be detected when a program actually experiences a deadlock, and it is not possible to predict which program execution logic might be at risk of deadlock before a deadlock occurs.

[0004] There is currently no effective solution to the problem of low process reliability caused by the inability to predict whether there is a deadlock risk in the process in the relevant technology. Summary of the Invention

[0005] This invention provides a method and apparatus for detecting abnormal use of lock resources, thereby at least solving the problem in related technologies where the reliability of process operation is low due to the inability to predict whether there is a deadlock risk in the process.

[0006] According to an embodiment of the present invention, a method for detecting abnormal use of lock resources is provided, comprising: obtaining a locking branch tree of each thread in a target process, wherein each locking branch in the locking branch tree is used to record the order in which the corresponding thread acquires lock resources within a historical time; determining whether the target process will form a locking loop based on the locking branch tree of each thread; and determining that a locking loop will form if it is determined that there is deadlock logic in the threads of the target process.

[0007] In an exemplary embodiment, determining whether the target process will form a locking loop based on the locking branch tree of each thread includes: selecting a locking branch from the locking branch tree corresponding to each thread to form a locking branch set; constructing a corresponding locking path graph for the locking branch set, wherein the locking path graph includes a set of nodes, each node in the set of nodes corresponds to a different lock resource, two nodes in the set of nodes with a connection relationship are two nodes in the locking branch set with a connection relationship, the connection relationship indicating the order in which the two lock resources corresponding to the two nodes are acquired; if the locking loop exists in the locking path graph, determining that the target process will form the locking loop.

[0008] In an exemplary embodiment, constructing a corresponding locking path graph for the locking branch set includes: searching for nodes corresponding to the same lock resource in the locking branch set; and merging the multiple nodes corresponding to the same lock resource in the locking branch set to obtain the locking path graph.

[0009] In an exemplary embodiment, a lock acquisition report corresponding to a first thread in the target process is obtained, wherein the lock acquisition report is used to indicate that the first thread is preparing to acquire a first lock resource; if the first lock resource has been acquired by a second thread, and the second thread is a different thread from the first thread, it is determined whether a thread loop exists among the threads in the target process based on the lock resource usage information of each thread in the target process, wherein the lock resource that each thread in the thread loop is preparing to acquire is the lock resource that the next thread in the thread loop has already acquired, and the lock resource usage information of each thread is used to identify the lock resource that each thread is preparing to acquire and the lock resource that each thread has already acquired; if the existence of the thread loop is determined, it is determined that a deadlock has occurred in the threads of the target process.

[0010] In an exemplary embodiment, determining whether a thread loop exists among the threads of the target process based on the lock resource usage information of each thread in the target process includes:

[0011] Step 1: Determine whether the i-th thread is ready to acquire the lock resource. If the i-th thread is ready to acquire the lock resource, mark the lock resource that the i-th thread is ready to acquire as the i-th lock resource and execute Step 2. Otherwise, execute Step 5. Here, i is a positive integer greater than or equal to 1. When i = 1, the marked first thread is the second thread.

[0012] Step 2: Search for the thread that has acquired the i-th lock resource in each thread of the target process. If a thread that has acquired the i-th lock resource is found, mark the found thread that has acquired the i-th lock resource as the (i+1)-th thread and execute Step 3. If no thread that has acquired the i-th lock resource is found, execute Step 5.

[0013] Step 3: Determine whether the (i+1)th thread is a thread in the target thread set. If the (i+1)th thread is a thread in the target thread set, execute step 4, wherein the target thread set includes the marked threads 1 to 1 and the first thread; if the (i+1)th thread is not a thread in the target thread set, i = i+1, and execute step 1.

[0014] Step 4: Determine whether a thread loop exists in any of the threads within the target process;

[0015] Step 5: Determine that there is no thread loop in any of the threads in the target process.

[0016] In one exemplary embodiment, the method further includes: when the first lock resource is not acquired by the respective threads in the target process, marking the lock resource usage information of the first thread as ready to acquire the first lock resource; when the first lock resource has been acquired by the first thread, determining that a first abnormal usage event exists, wherein the first abnormal usage event indicates that the first thread repeatedly acquires the lock resource.

[0017] In an exemplary embodiment, after marking the lock resource usage information of the first thread as ready to acquire the first lock resource, the method further includes: acquiring a successful locking report corresponding to the first thread, wherein the successful locking report is used to indicate that the first thread has successfully acquired the first lock resource; marking the lock resource usage information of the first thread as the first thread has acquired the first lock resource, and updating the locking branch tree of the first thread, wherein each locking branch in the locking branch tree is used to record the order in which the first thread acquires the lock resource; determining, based on each locking branch in the updated locking branch tree of the first thread, whether the first thread and a thread in the target process different from the first thread will form the locking loop; if it is determined that the first thread and a thread in the target process different from the first thread will form the locking loop, determining that there is logic for deadlock in the threads of the target process.

[0018] In one exemplary embodiment, the method further includes: obtaining a proposed unlock report corresponding to a target thread in the target process, wherein the proposed unlock report is used to indicate that the target thread is ready to release the target lock resource; determining whether the target lock resource has been acquired by a thread in the target process; and if the target lock resource has not been acquired by a thread in the target process, determining that a second abnormal usage event exists, wherein the second abnormal usage event indicates that the unacquired lock resource is ready to be released.

[0019] In one exemplary embodiment, the method further includes: if the target lock resource has been acquired by a thread in the target process, and the thread is different from the target thread, determining that a third abnormal usage event exists, wherein the third abnormal usage event indicates that the lock resource not acquired by the target thread is ready to be released.

[0020] In an exemplary embodiment, the method further includes: determining a fourth abnormal usage event when the target lock resource has been acquired by the target thread and the target lock resource is not the last acquired lock resource in the target lock resource set, wherein the target lock resource set includes all lock resources acquired by the target thread but not yet released, and the fourth abnormal usage event indicates that the release of the target lock resource does not conform to a preset lock resource release logic, wherein the lock resource release logic indicates that the lock resource acquired later needs to be released first.

[0021] According to another embodiment of the present invention, a detection device for abnormal use of lock resources is also provided, comprising: an acquisition device, used to acquire the locking branch tree of each thread in a target process, wherein each locking branch in the locking branch tree is used to record the order in which the corresponding thread acquires lock resources within a historical time period;

[0022] A first determining device is used to determine whether the target process will form a locking loop based on the locking branch tree of each thread;

[0023] The second determining device, upon determining that the locking loop will be formed, determines that there is deadlock logic in the threads of the target process.

[0024] According to yet another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0025] According to yet another embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0026] This invention determines whether a locking loop will form by recording the locking action sequence of each thread in the target process during historical execution. This allows for the prediction of whether deadlock logic exists in the target process. If deadlock logic is predicted, developers can promptly identify the corresponding code as risky, providing a reference for code repair and eliminating security vulnerabilities. This solves the problem in related technologies where the inability to predict deadlock risks leads to low process reliability, thus improving the reliability of process operation. Attached Figure Description

[0027] Figure 1 This is a mobile terminal hardware structure block diagram of the lock resource abnormal usage detection method according to an embodiment of the present invention;

[0028] Figure 2 This is a flowchart of a method for detecting abnormal use of lock resources according to an embodiment of the present invention;

[0029] Figure 3 This is a schematic diagram of a locking branch tree corresponding to an optional thread according to an embodiment of the present invention;

[0030] Figure 4 This is a schematic diagram of a locking path according to an embodiment of the present invention;

[0031] Figure 5 This is a schematic diagram of constructing a locking path diagram according to an embodiment of the present invention;

[0032] Figure 6 This is a schematic diagram of the detected process report lock operation according to an embodiment of the present invention;

[0033] Figure 7 This is a schematic diagram illustrating the existence of a thread loop in the target process according to an embodiment of the present invention;

[0034] Figure 8 This is a schematic diagram illustrating the absence of thread loops in the target process according to an embodiment of the present invention;

[0035] Figure 9 This is a flowchart of detecting thread loops according to an embodiment of the present invention;

[0036] Figure 10 This is a schematic diagram illustrating the optional lock resource usage relationship between threads according to an embodiment of the present invention;

[0037] Figure 11 This is a flowchart illustrating the successful unlocking operation according to an embodiment of the present invention;

[0038] Figure 12 This is a schematic diagram of the proposed locking operation process according to a specific embodiment of the present invention;

[0039] Figure 13 This is a schematic diagram of a successful locking operation process according to a specific embodiment of the present invention;

[0040] Figure 14 This is a schematic diagram of the proposed unlocking operation process according to a specific embodiment of the present invention;

[0041] Figure 15 This is a structural block diagram of a detection device for abnormal use of lock resources according to an embodiment of the present invention. Detailed Implementation

[0042] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings and examples.

[0043] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0044] The methods and embodiments provided in this application can be executed on a mobile terminal, a computer terminal, or a similar computing device. Taking operation on a mobile terminal as an example. Figure 1 This is a mobile terminal hardware structure block diagram of the lock resource abnormal usage detection method according to an embodiment of the present invention, as shown below. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0045] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the lock resource abnormal usage detection method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal 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.

[0046] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0047] Multiple threads within the same process will share all system resources of that process, but each thread within the same process has its own call stack, register context, and thread-local storage.

[0048] In multithreaded programming, the operating system introduces a locking mechanism. All system resources in a process are divided into multiple lock resources. Through the locking mechanism, it can be ensured that in a multi-core, multithreaded environment, only one thread can enter the critical section code at any given time, thereby ensuring the consistency of the data operated on in the critical section.

[0049] A critical section is a segment of code that accesses a shared resource, which cannot be accessed by multiple threads simultaneously. When a thread enters the critical section, other threads or processes must wait for the shared resource to be released before they can access it.

[0050] This embodiment provides a method for detecting abnormal use of lock resources. Figure 2 This is a flowchart of a method for detecting abnormal use of lock resources according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:

[0051] Step S202: Obtain the locking branch tree of each thread in the target process, wherein each locking branch in the locking branch tree is used to record the order in which the corresponding thread acquires lock resources in a historical time period;

[0052] Step S204: Determine whether the target process will form a locking loop based on the locking branch tree of each thread;

[0053] Step S206: If it is determined that the locking loop will be formed, it is determined that there is deadlock logic in the thread of the target process.

[0054] In this embodiment, the main entity executing steps S202 to S204 is a lock operation monitoring process. This monitoring process is a third-party process used to monitor lock operations in the process being monitored (i.e., the target process). Without affecting the performance of the process being monitored, lock anomalies are automatically detected, and sufficiently detailed anomaly information is recorded so that developers can directly pinpoint the root cause of program problems.

[0055] The lock operation monitoring process constructs a lock branch tree for each thread in the target process involved in lock operations. A lock branch in the lock branch tree represents the sequence of locking actions performed by that thread during its historical execution. Figure 3 This is a schematic diagram of a locking branch tree corresponding to an optional thread according to an embodiment of the present invention, such as... Figure 3 As shown, thread T-1 has three locking logics during its historical execution:

[0056] (1) Lock L-1, that is, acquire lock resource L-1, enter the critical section of lock resource L-1, unlock L-1, and exit the critical section of lock resource L-1;

[0057] (2) Lock L-1, enter the critical section of lock resource L-1, lock L-2, enter the critical section of lock resource L-2, unlock L-2, exit the critical section of lock resource L-2, unlock L-1, and exit the critical section of lock resource L-1.

[0058] (3) Lock L-2, enter the critical section of lock resource L-2, then lock L-3, enter the critical section of lock resource L-3, then lock L-4, enter the critical section of lock resource L-4, then unlock L-4, exit the critical section of lock resource L-4, then unlock L-3, exit the critical section of lock resource L-3, and finally unlock L-2, exit the critical section of lock resource L-2.

[0059] The lock operation monitoring process records the locking logic of each thread in the target process throughout its historical execution process. It constructs a locking branch tree for each thread in the target process and determines whether the target process will form a locking loop based on the locking branch tree of each thread. If it is determined that a locking loop will form, then there is a deadlock logic in the threads of the target process.

[0060] For example, if thread T1 has a locking branch from locking L1 to locking L2, while thread T2 has a locking branch from locking L2 to locking L3, and thread T3 has a locking branch from locking L3 to locking L1, then these three locking branches of the three threads will form a locking loop, which could lead to a deadlock.

[0061] It's important to note that the existence of deadlock logic does not necessarily mean a deadlock has occurred. Two necessary conditions must be met for a deadlock to occur: first, the existence of deadlock logic; and second, the locking branches of threads involved in a locking loop must execute at the same time. The steps described above only determine whether deadlock logic exists, not whether they execute at the same time.

[0062] By following the steps above, the locking action sequence of each thread in the target process during historical execution is recorded to determine whether a locking loop will form. This helps predict whether deadlock logic exists in the target process. If deadlock logic is predicted, developers can promptly identify the corresponding code as risky, providing a reference for code repair and eliminating security vulnerabilities. This solves the problem in related technologies where the inability to predict deadlock risks leads to low process reliability, thus improving the reliability of process operation.

[0063] In an exemplary embodiment, a locking branch is selected from the locking branch tree corresponding to each thread to form a locking branch set; a corresponding locking path graph is constructed for the locking branch set, wherein the locking path graph includes a set of nodes, each node in the set of nodes corresponds to a different lock resource, and two nodes in the set of nodes that have a connection relationship are two nodes in the locking branch set that have a connection relationship, the connection relationship indicating the order in which the two lock resources corresponding to the two nodes are acquired; if the locking path graph contains a locking loop, it is determined that the target process will form the locking loop.

[0064] In this embodiment, a locking branch is selected from the locking branch tree of each thread in the target process to obtain multiple locking branches, forming a locking branch set; a locking path graph is constructed according to the order in which the locking branches in the locking branch set acquire lock resources; if a closed loop (i.e., a locking loop) appears in the locking path graph, it is determined that a thread loop will be formed in the target process.

[0065] Each node in the locking path graph corresponds to a different lock resource, and two nodes with a connection relationship indicate the acquisition order of the corresponding two lock resources.

[0066] For example, the target process includes three threads (Thread 1, Thread 2, and Thread 3). In Thread 1, the order of acquiring lock resources in the selected locking branch is: Lock resource LA → Lock resource LB → Lock resource LC → Lock resource LD; in Thread 2, the order is: Lock resource LC → Lock resource LE → Lock resource LF → Lock resource LG; and in Thread 3, the order is: Lock resource LF → Lock resource LH → Lock resource LB. A locking path graph is constructed based on these selected locking branches. Figure 4 This is a schematic diagram of the locking path diagram according to an embodiment of the present invention, such as... Figure 4 As shown, lock resources LB, LC, LE, LF, and LH form a closed loop. Therefore, if the locking path graph contains the locking loop, the target process will form the locking loop, and thus the threads in the target process may experience deadlock.

[0067] Repeat the above steps of selecting a locking branch from the locking branch tree corresponding to each thread to form a locking branch set; constructing a corresponding locking path graph for the locking branch set and determining whether there is a locking loop in the locking path graph, until the locking branch tree of each thread has been traversed, or it is determined that the target process will form the locking loop.

[0068] It should be noted that traversing the locking branch tree of each thread means traversing all possible sets of locking branches, that is, all possible sets of locking branches formed by arbitrarily selecting a locking branch in each locking branch tree. For example, if a process has two threads, each with two locking branches, the process can form four different sets of locking branches. Traversing the locking branch tree of each thread means traversing these four different sets of locking branches. If there are no locking loops in the locking path graph formed by all sets of locking branches, it is determined that the target process will not form a locking loop, and therefore, there is no logic for deadlock to occur in the threads of the target process.

[0069] In an exemplary embodiment, constructing a corresponding locking path graph for the locking branch set includes: searching for nodes corresponding to the same lock resource in the locking branch set; and merging the multiple nodes corresponding to the same lock resource in the locking branch set to obtain the locking path graph.

[0070] In this embodiment, when constructing the locking path graph, a locking path is formed by each locking branch in the locking branch set. Multiple nodes corresponding to the same lock resources in each locking branch are found and the corresponding nodes are merged into one, thus obtaining the above-mentioned locking path graph.

[0071] For example, in thread 1, the order of acquiring lock resources in the locking branch is: lock resource LA → lock resource LB → lock resource LC → lock resource LD; in thread 2, the order of acquiring lock resources in the locking branch is: lock resource LC → lock resource LE → lock resource LF → lock resource LG; and in thread 3, the order of acquiring lock resources in the locking branch is: lock resource LF → lock resource LH → lock resource LB. Figure 5 This is a schematic diagram of constructing a locking path graph according to an embodiment of the present invention, such as... Figure 5 As shown, the locking paths corresponding to the three locking branches are path 1, path 2, and path 3. Path 1 and path 2 share the same lock resource LC, path 2 and path 3 share the same lock resource LF, and path 1 and path 3 share the same lock resource LB. By merging the two nodes corresponding to the lock resource LC, the two nodes corresponding to the lock resource LF, and the two nodes corresponding to the lock resource LB, a locking mechanism is constructed. Figure 5 Locked path diagram in the middle.

[0072] Optionally, after constructing the locking path graph, the following method can be used to determine whether a locking loop exists in the locking path graph: starting from the node corresponding to the first lock resource of each locking branch, traverse each locking path. If the same node is not traversed, it is determined that there is no locking loop in the locking path graph. If the same node is traversed at least once, it is determined that there is a locking loop in the locking path graph.

[0073] In an exemplary embodiment, the method further includes: obtaining a lock-acquiring report corresponding to a first thread in the target process, wherein the lock-acquiring report is used to indicate that the first thread is preparing to acquire a first lock resource; if the first lock resource has been acquired by a second thread, and the second thread is a different thread from the first thread, determining whether a thread loop exists among the threads in the target process based on the lock resource usage information of each thread in the target process, wherein the lock resource that each thread in the thread loop is preparing to acquire is the lock resource that the next thread in the thread loop has already acquired, and the lock resource usage information of each thread is used to identify the lock resource that each thread is preparing to acquire and the lock resource that each thread has already acquired; if the existence of the thread loop is determined, determining that a deadlock has occurred in the threads of the target process.

[0074] In this embodiment, the entity executing the above embodiments is a lock operation monitoring process, which is a third-party process used to monitor lock operations in the monitored process (i.e., the target process). The monitored process's operations on lock resources include four types: proposed locking operation, successful locking operation, proposed unlocking operation, and successful unlocking operation. A proposed locking operation means preparing to acquire a lock resource, i.e., locking a lock resource to prevent access to the corresponding shared resource by other threads; a successful locking operation means successfully acquiring a lock resource and entering the locking critical section; a proposed unlocking operation means preparing to release the corresponding lock resource, i.e., preparing to unlock a lock resource; and a successful unlocking operation means successfully releasing a lock resource and exiting the locking critical section.

[0075] Figure 6 This is a schematic diagram of the detected process report lock operation according to an embodiment of the present invention, as shown below. Figure 6 As shown, an encryption / unlock hook is embedded in the process being monitored. Through this hook, the monitored process sends reports to the lock operation monitoring process regarding the four types of lock resource operations described above. These reports provide real-time updates on the lock operations performed by the monitored process, including at least the process ID, thread ID, lock operation type, call stack, and lock object address. Specifically, when the monitored process attempts to acquire a lock, it sends a report to the lock operation monitoring process; when it successfully acquires a lock, it sends a report; and when it attempts to unlock, it sends a report.

[0076] After receiving a report from the monitored process, the lock operation monitoring process updates the lock resource usage information of each thread in the monitored process according to the report content. The lock resource usage information of each thread includes the lock resources that each thread has successfully acquired and the lock resources that it is preparing to acquire.

[0077] Figure 7 This is a schematic diagram illustrating the existence of a thread loop in the target process according to an embodiment of the present invention, such as... Figure 7 As shown, Figure 7 An arrow in a lock pointer indicates a thread that points from one thread to the next thread. For example, if thread A points to thread B, then thread A is the thread preceding thread B, and thread B is the thread following thread A. The relationship between a thread and its next thread is such that the lock resource that the current thread is about to acquire is a lock resource that the next thread has already acquired.

[0078] A thread loop occurs when any thread in a thread loop attempts to acquire a lock resource that has already been acquired by the thread immediately following it, and that thread immediately following it is also a thread in the loop. If arrows represent the lock resource usage relationships between threads, then the existence of a closed loop indicates the presence of a thread loop in the target process. Figure 7 The second thread, thread A, thread B, and thread C in the loop form a thread loop.

[0079] Figure 8 This is a schematic diagram illustrating the absence of thread loops in the target process according to an embodiment of the present invention, such as... Figure 8 As shown, Figure 8 There is no closed loop in the process, and it is determined that there is no thread loop in the target process.

[0080] A deadlock occurs when two or more threads are locked in a deadlock process due to contention for resources. Without external intervention, they cannot proceed. For example, thread T1 has acquired lock L1 and is preparing to acquire lock L2, while thread T2 has acquired lock L2 and is preparing to acquire lock L1. Threads T1 and T2 are locked in a deadlock: thread T1 waits for thread T2 to release lock L2, and thread T2 waits for thread T1 to release lock L1. Without external intervention, neither thread T1 nor thread T2 can proceed; this is known as a deadlock.

[0081] If a deadlock occurs in a thread within the target process, a thread loop will inevitably form. Therefore, the existence of a thread loop in the target process determines whether a deadlock has occurred. If a thread loop exists in the target process, a deadlock is confirmed to have occurred in the target process.

[0082] In the event of a deadlock in the target process, an exception alert is sent to the developers, and the exception event handling logic is invoked.

[0083] By using the lock resource usage information of each thread in the target process, it is determined whether there is a thread loop in each thread of the target process, and then it is determined whether a deadlock has occurred in the thread of the target process. This avoids relying on the duration of thread operations on lock resources to determine whether a deadlock has occurred in the process, solves the problem of inaccurate deadlock detection of threads in the process in related technologies, and improves the accuracy of deadlock detection of threads in the process.

[0084] In one exemplary embodiment, Figure 9 This is a flowchart of detecting thread loops according to an embodiment of the present invention, such as... Figure 9 As shown, determining whether a thread loop exists among the threads in the target process based on the lock resource usage information of each thread in the target process includes:

[0085] Step 1: Determine whether the i-th thread is ready to acquire the lock resource. If the i-th thread is ready to acquire the lock resource, mark the lock resource that the i-th thread is ready to acquire as the i-th lock resource and execute Step 2. Otherwise, execute Step 5. Here, i is a positive integer greater than or equal to 1. When i = 1, the marked first thread is the second thread.

[0086] In this case, if the i-th thread is not ready to acquire the lock resource, the i-th thread does not need to wait for the lock resource. That is, there will be no situation where the first thread and the i-th thread are waiting for each other to acquire the lock resource, i.e. there is no thread loop.

[0087] Step 2: Search for the thread that has acquired the i-th lock resource in each thread of the target process. If a thread that has acquired the i-th lock resource is found, mark the found thread that has acquired the i-th lock resource as the (i+1)-th thread and execute Step 3. If no thread that has acquired the i-th lock resource is found, execute Step 5.

[0088] In the case where no thread has been found to have acquired the i-th lock resource, meaning the i-th thread is preparing to acquire the i-th lock resource but it has not been acquired by any other thread, indicating that the i-th thread is not in a waiting state for the lock resource with other threads, there is no thread loop and no deadlock has occurred. Therefore, it is determined that there is no thread loop among the threads in the target process. If the i-th thread is acquiring the i-th lock resource but has not yet completed the acquisition operation, and the lock operation monitoring process has not yet received a report from the i-th thread that it has successfully acquired the i-th lock resource, then in the lock operation monitoring process, the i-th thread is still in the state of preparing to acquire the i-th lock resource, and the i-th lock resource is in a state where it has not been acquired by any other thread.

[0089] Step 3: Determine whether the (i+1)th thread is a thread in the target thread set. If the (i+1)th thread is a thread in the target thread set, proceed to step 4, wherein the target thread set includes the marked threads 1 to 1 and the first thread; if the (i+1)th thread is not a thread in the target thread set, i = i+1, and proceed to step 1.

[0090] In the case where the (i+1)th thread is a thread in the target thread set, the resource that the (i+1)th thread is preparing to acquire is acquired by a thread in the target thread set. There is a thread loop among the threads in the target process, and all threads in the target thread set are waiting for the lock resource, resulting in a deadlock in the target process.

[0091] If the (i+1)th thread is not a thread in the target thread set, let i = i+1 and execute step 1 again, that is, determine whether the (i+1)th thread is ready to acquire the lock resource.

[0092] Step 4: Determine whether a thread loop exists in any of the threads within the target process;

[0093] Step 5: Determine that there is no thread loop in any of the threads in the target process.

[0094] Specifically, if it is determined that there is no thread loop among the threads in the target process, it means that when the first thread prepares to acquire the first lock resource, it will not cause a deadlock in the threads of the target process, and therefore the threads in the target process will run normally. If it is determined that there is a thread loop among the threads in the target process, it means that when the first thread prepares to acquire the first lock resource, it will cause a deadlock in the threads of the target process or a deadlock already exists in the threads of the target process. An exception alert will be sent to the developers, and the exception event handling logic will be entered.

[0095] In this embodiment, Figure 10 This is a schematic diagram illustrating the optional lock resource usage relationship between threads according to an embodiment of the present invention, for detection. Figure 10 Taking the existence of a thread loop as an example, the first thread prepares to acquire the first lock resource, the first lock resource is acquired by the second thread, and the first thread and the second thread are different threads. The above steps are executed repeatedly to determine whether there is a thread loop in each thread of the target process.

[0096] The second thread is marked as thread 1. It is determined whether thread 1 is ready to acquire the lock resource. If thread 1 is ready to acquire the first lock resource, then thread A (marked as thread 2) that has already acquired the first lock resource is searched among the threads in the target process. Thread 2 is not a thread in the target thread set (which includes thread 1 and thread 2 at this time). Let i = i + 1, and execute step 1, i.e., determine whether thread 2 is ready to acquire the lock resource. If thread 2 is ready to acquire the second lock resource, then thread B (marked as thread 3) that has already acquired the second lock resource is searched among the threads in the target process. If a thread is not in the target thread set (at this time, the target thread set includes the first thread, the 1st thread, and the 2nd thread), let i = i + 1, and execute step 1, that is, determine whether the 3rd thread is ready to acquire the lock resource. If the 3rd thread is ready to acquire the 3rd lock resource, search for thread A (marked as the 4th thread) that has already acquired the 3rd lock resource in each thread of the target process. The 4th thread is a thread in the target thread set. Since the 4th thread and the 2nd thread are both thread A (at this time, the target thread set includes the first thread, the 1st thread, the 2nd thread, and the 3rd thread), it is determined that there is a thread loop in each thread of the target process.

[0097] In an exemplary embodiment, the method further includes: when the first lock resource is not acquired by the respective threads in the target process, marking the lock resource usage information of the first thread as ready to acquire the first lock resource;

[0098] If the first lock resource has been acquired by the first thread, a first abnormal usage event is determined to exist, wherein the first abnormal usage event indicates that the first thread repeatedly acquires the lock resource.

[0099] In this embodiment, if the first thread's attempt to acquire the first lock resource has not been acquired by any other thread, the first thread's attempt to acquire the first lock resource will not cause a deadlock. The threads in the target process will run normally. In the lock operation monitoring process, the lock resource usage information of the first thread will be marked as ready to acquire the first lock resource. After the first thread successfully acquires the first lock resource, the lock operation monitoring process will receive the target process's successful locking report, mark the first thread's lock resource usage information as successfully acquired, and mark the time information of the successful acquisition of the first lock resource.

[0100] Besides thread deadlock, abnormal lock usage also includes the following abnormal usage events: 1. A thread that has acquired a lock resource and has not yet released it attempts to acquire the same lock resource again; 2. An attempt to unlock an unlocked lock resource, that is, an attempt to release a lock resource that has not been acquired by any thread; 3. The thread unlocking is different from the thread acquiring the lock; 4. Within the same thread, the principle of acquiring the lock before unlocking is not met.

[0101] When the lock operation monitoring process receives a report that the first thread is preparing to acquire the first lock resource, if it determines that the first lock resource has already been acquired by the first thread, that is, the first thread has acquired the first lock resource and has not yet released the first lock resource, and the first thread tries to acquire the first lock resource again, then the lock usage of the first thread is abnormal, and the existence of the first abnormal usage event is confirmed.

[0102] In an exemplary embodiment, after marking the lock resource usage information of the first thread as ready to acquire the first lock resource, the method further includes: acquiring a successful locking report corresponding to the first thread, wherein the successful locking report is used to indicate that the first thread has successfully acquired the first lock resource; marking the lock resource usage information of the first thread as the first thread has acquired the first lock resource, and updating the locking branch tree of the first thread, wherein each locking branch in the locking branch tree is used to record the order in which the first thread acquires the lock resource; determining, based on each locking branch in the updated locking branch tree of the first thread, whether the first thread and a thread in the target process different from the first thread will form the locking loop; if it is determined that the first thread and a thread in the target process different from the first thread will form the locking loop, determining that there is logic for deadlock in the thread of the target process.

[0103] In this embodiment, after a thread in the target process successfully acquires the lock resource, it sends a successful lock acquisition report to the lock operation monitoring process to indicate that the corresponding thread has successfully acquired the corresponding lock resource. After receiving the successful lock acquisition report, the lock operation monitoring process updates the lock resource usage information of the corresponding thread. For example, after receiving the successful lock acquisition report sent by the target process that the first thread has successfully acquired the first lock resource, the lock resource usage information of the first thread is marked as successfully acquiring the first lock resource.

[0104] The locking branch tree records the locking logic of the thread's historical execution process, that is, the order in which one or more lock resources are acquired during the thread's historical execution process. The locking logic during thread execution is the locking logic of a locking branch in the locking branch tree, or the locking logic that is different from all locking branches in the locking branch tree. Therefore, during thread execution, the locking branch tree is updated in real time after the thread successfully acquires the lock resource.

[0105] After updating the locking branch tree of the first thread, determine whether there is a locking loop between the first thread and other threads in the target process based on the updated locking branch tree of the first thread and the locking branch trees of other threads in the target process. If a locking loop occurs, determine that there is a deadlock logic in the threads of the target process.

[0106] This embodiment combines the locking logic of the target process running over a historical period with the real-time locking logic to further dynamically predict whether there will be deadlock logic in the target process, thereby improving the reliability of process operation.

[0107] In one exemplary embodiment, the method further includes: obtaining a proposed unlock report corresponding to a target thread in the target process, wherein the proposed unlock report is used to indicate that the target thread is ready to release the target lock resource; determining whether the target lock resource has been acquired by a thread in the target process; and if the target lock resource has not been acquired by a thread in the target process, determining that a second abnormal usage event exists, wherein the second abnormal usage event indicates that the unacquired lock resource is ready to be released.

[0108] In this embodiment, after receiving a report from the target thread that it intends to release the target lock resource, the lock operation monitoring process determines that the target lock resource has not been acquired by any thread in the target process, i.e., the target lock resource is in an idle state. However, if the target thread attempts to release the target lock resource, the target thread attempts to unlock an unlocked lock resource, i.e., attempts to release a lock resource that has not been acquired by any thread. The lock usage is abnormal, and a second abnormal usage event is determined to exist.

[0109] In one exemplary embodiment, the method further includes: if the target lock resource has been acquired by a thread in the target process, and the thread is different from the target thread, determining that a third abnormal usage event exists, wherein the third abnormal usage event indicates that the lock resource not acquired by the target thread is ready to be released.

[0110] In this embodiment, after receiving a report from the target thread that it intends to release the target lock resource, if the lock operation monitoring process determines that the target lock resource has been acquired by a thread other than the target thread in the target process, that is, the thread that acquired the target lock resource is not the same thread as the target thread, and the target thread attempts to release the target lock resource, then the thread that unlocks the target lock resource is inconsistent with the thread that acquired it, the lock usage is abnormal, and a third abnormal usage event is determined to exist.

[0111] In an exemplary embodiment, the method further includes: if the target lock resource has been acquired by the target thread and the target lock resource is not the last lock resource acquired by the target thread, determining that a fourth abnormal usage event exists, wherein the fourth abnormal usage event indicates that the release of the target lock resource does not conform to a preset lock resource release logic, and the lock resource release logic indicates that the lock resource acquired later needs to be released first.

[0112] In this embodiment, within the same thread, the lock resource release logic is that the lock is acquired first and then unlocked. That is, the lock resource acquired first by the thread needs to be released later, and the lock resource acquired later needs to be released first. For example, if the order of acquiring lock resources is lock resource A → lock resource B, then the order of releasing locks should be lock resource B → lock resource A.

[0113] If the target thread is preparing to release the target lock resource, and the target lock resource has been acquired by the target thread, it is determined whether the target lock resource is the last lock resource acquired in the target lock resource set. If the target lock resource is the last lock resource acquired in the target lock resource set, it meets the preset lock resource release logic, and the target thread releases the target lock resource normally.

[0114] If the target lock resource is not the last lock resource acquired in the target lock resource set, then releasing the target lock resource does not conform to the preset lock resource release logic, the lock usage is abnormal, and a fourth abnormal usage event is determined to exist.

[0115] It should be noted that the target lock resource set includes all lock resources that the target thread has acquired but not yet released. The order in which lock resources are acquired is determined by the time they were acquired. After a target thread releases a lock resource, that lock resource is removed from the target lock resource set.

[0116] Figure 11 This is a flowchart illustrating a successful unlocking operation according to an embodiment of the present invention, as shown below. Figure 11 As shown, after the target thread successfully releases the target lock resource, the lock operation monitoring process receives the target process's successful unlock report, marks the target thread's lock resource usage information as having successfully released the target lock resource, and marks the time information of the successful release of the first lock resource.

[0117] Obviously, the embodiments described above are only some embodiments of the present invention, and not all embodiments.

[0118] The present invention will be specifically described below with reference to embodiments:

[0119] Figure 12 This is a schematic diagram of the proposed locking operation process according to a specific embodiment of the present invention, such as... Figure 12 As shown, it includes the following steps:

[0120] Step S1201: Receive a lock acquisition report. The lock acquisition report is used to indicate that the first thread is ready to acquire the first lock resource.

[0121] Step S1202: Determine whether the first lock resource has been acquired by a certain thread. If the first lock resource has been acquired by a certain thread, proceed to step S1203. If the first lock resource has not been acquired by a certain thread, proceed to step S1209.

[0122] Step S1203: Determine whether the thread that acquired the first lock resource is the first thread. If the thread that acquired the first lock resource is the first thread, execute step S1210. If the thread that acquired the first lock resource is not the first thread, mark the thread that acquired the first lock resource as the first thread and execute step S1204.

[0123] Step S1204: Determine whether the i-th thread is ready to acquire the lock resource. If the i-th thread is ready to acquire the lock resource, execute step S1205. If the i-th thread is not ready to acquire the lock resource, execute step S1209. When i is 1, the first thread becomes the second thread.

[0124] Step S1205: Locate the thread that has acquired the i-th lock resource among the threads in the target process;

[0125] Step S1206: Determine whether a thread that has acquired the i-th lock resource has been found. If a thread that has acquired the i-th lock resource has been found, mark the found thread that has acquired the i-th lock resource as thread i+1 and proceed to step S1207. If no thread that has acquired the i-th lock resource has been found, proceed to step S1209.

[0126] Step S1207: Determine whether the (i+1)th thread is a thread that has been traversed before; if yes, execute step S1208; if no, let i = i+1 and repeat step S1204.

[0127] Step S1208: Determine that a thread deadlock has occurred and proceed to the exception event handling logic;

[0128] Step S1209: Mark the lock resource usage information of the first thread as ready to acquire the first lock resource, and return normally;

[0129] Step S1210: Determine the existence of a first abnormal usage event and enter the abnormal event handling logic. The first abnormal usage event indicates that the first thread repeatedly acquires the lock resource.

[0130] Figure 13 This is a schematic diagram of the successful locking operation process according to a specific embodiment of the present invention, such as... Figure 13 As shown, it includes the following steps:

[0131] Step S1301: Receive a successful locking report. The successful locking report is used to indicate that the first thread has successfully acquired the first lock resource.

[0132] Step S1302: Mark the lock resource usage information of the first thread as the first thread having acquired the first lock resource;

[0133] Step S1303: Update the locking branch tree of the first thread;

[0134] Step S1304: Determine whether the first thread and a thread in the target process that is different from the first thread will form a thread loop; that is, determine whether there is a conflict between the locking branches of the threads, which is a necessary condition for forming a deadlock. If a thread loop will form, execute step S1305; if a thread loop will not form, execute step S1306.

[0135] Step S1305: There is logic that triggers deadlock; proceed to exception event handling logic.

[0136] Step S1306, return normally.

[0137] Figure 14 This is a schematic diagram of the proposed unlocking operation process according to a specific embodiment of the present invention, such as... Figure 14 As shown, it includes the following steps

[0138] Step S1401: Receive a proposed unlock report, which is used to instruct the target thread to prepare to release the target lock resource;

[0139] Step S1402: Determine whether the target lock resource has been acquired by a thread in the target process; if it has been acquired by a thread in the target process, proceed to step S1403; if it has not been acquired by a thread in the target process, proceed to step S1406.

[0140] Step S1403: Determine whether the thread acquiring the target lock resource is the target thread; if the thread acquiring the target lock resource is the target thread, proceed to step S1404; if the thread acquiring the target lock resource is not the target thread, proceed to step S1407.

[0141] Step S1404: Determine whether the target lock resource is the last lock resource acquired in the target lock resource set. If the target lock resource is the last lock resource acquired in the target lock resource set, proceed to step S1405. If the target lock resource is not the last lock resource acquired in the target lock resource set, proceed to step S1408.

[0142] Step S1405, normal return;

[0143] Step S1406: It is determined that there is a second abnormal usage event. Enter the abnormal event handling logic. The second abnormal usage event indicates that the lock resource that has not been acquired is ready to be released.

[0144] Step S1407: It is determined that there is a third abnormal usage event, and the abnormal event handling logic is entered. The third abnormal usage event indicates that the lock resources not acquired by the target thread are ready to be released.

[0145] Step S1408: It is determined that there is a fourth abnormal usage event. Enter the abnormal event handling logic. The fourth abnormal usage event indicates that the release of the target lock resource does not conform to the preset lock resource release logic. The lock resource release logic indicates that the lock resource acquired later needs to be released first.

[0146] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0147] This embodiment also provides a detection device for abnormal use of lock resources. Figure 15 This is a structural block diagram of a detection device for abnormal use of lock resources according to an embodiment of the present invention, such as... Figure 15 As shown, the device includes:

[0148] The acquisition device 1502 is used to acquire the locking branch tree of each thread in the target process, wherein each locking branch in the locking branch tree is used to record the order in which the corresponding thread acquires lock resources in a historical time period;

[0149] The first determining device 1506 is used to determine whether the target process will form a locking loop based on the locking branch tree of each thread.

[0150] The second determining device 1508, upon determining that the locking loop will be formed, determines that there is a deadlock logic in the threads of the target process.

[0151] In an optional embodiment, the first determining module includes: a selection submodule, configured to select a locking branch from the locking branch tree corresponding to each thread to form a locking branch set; a construction submodule, configured to construct a corresponding locking path graph for the locking branch set, wherein the locking path graph includes a set of nodes, each node in the set of nodes corresponds to a different lock resource, two nodes in the set of nodes with a connection relationship are two nodes in the locking branch set with a connection relationship, the connection relationship indicating the order in which the two lock resources corresponding to the two nodes are acquired; and a first determining submodule, configured to determine that the target process will form the locking loop if the locking loop exists in the locking path graph.

[0152] In an optional embodiment, the above-mentioned construction submodule includes: a merging unit, configured to search for nodes corresponding to the same lock resource in the locking branch set, and, if multiple nodes corresponding to the same lock resource are found, merge the multiple nodes in the locking branch set to obtain the locking path graph.

[0153] In an optional embodiment, the above apparatus further includes: a first acquisition module, configured to acquire a proposed lock report corresponding to a first thread in the target process, wherein the proposed lock report is used to indicate that the first thread is preparing to acquire a first lock resource; a third determination module, configured to, when the first lock resource has been acquired by a second thread and the second thread is a different thread from the first thread, determine whether a thread loop exists among the threads in the target process based on the lock resource usage information of each thread in the target process, wherein the lock resource that each thread in the thread loop is preparing to acquire is the lock resource that the next thread in the thread loop has already acquired, and the lock resource usage information of each thread is used to identify the lock resource that each thread is preparing to acquire and the lock resource that each thread has already acquired; and a fourth determination module, configured to, if the existence of the thread loop is determined, determine that a deadlock has occurred in the threads of the target process.

[0154] In an optional embodiment, the third determining module determines whether a thread loop exists in each thread of the target process by performing the following steps:

[0155] Step 1: Determine whether the i-th thread is ready to acquire the lock resource. If the i-th thread is ready to acquire the lock resource, mark the lock resource that the i-th thread is ready to acquire as the i-th lock resource and execute Step 2. Otherwise, execute Step 5. Here, i is a positive integer greater than or equal to 1. When i = 1, the marked first thread is the second thread.

[0156] Step 2: Search for the thread that has acquired the i-th lock resource in each thread of the target process. If a thread that has acquired the i-th lock resource is found, mark the found thread that has acquired the i-th lock resource as the (i+1)-th thread and execute Step 3. If no thread that has acquired the i-th lock resource is found, execute Step 5.

[0157] Step 3: Determine whether the (i+1)th thread is a thread in the target thread set. If the (i+1)th thread is a thread in the target thread set, execute step 4, wherein the target thread set includes the marked threads 1 to 1 and the first thread; if the (i+1)th thread is not a thread in the target thread set, i = i+1, and execute step 1.

[0158] Step 4: Determine whether a thread loop exists in any of the threads within the target process;

[0159] Step 5: Determine that there is no thread loop in any of the threads in the target process.

[0160] In an optional embodiment, the apparatus is further configured to: mark the lock resource usage information of the first thread as ready to acquire the first lock resource when the first lock resource has not been acquired by the respective threads in the target process; and determine the existence of a first abnormal usage event when the first lock resource has been acquired by the first thread, wherein the first abnormal usage event indicates that the first thread repeatedly acquires the lock resource.

[0161] In an optional embodiment, the apparatus is further configured to: after marking the lock resource usage information of the first thread as ready to acquire the first lock resource, acquire a successful locking report corresponding to the first thread, wherein the successful locking report is used to indicate that the first thread has successfully acquired the first lock resource; mark the lock resource usage information of the first thread as the first thread has acquired the first lock resource, and update the locking branch tree of the first thread, wherein each locking branch in the locking branch tree is used to record the order in which the first thread acquires the lock resource; determine, based on each locking branch in the updated locking branch tree of the first thread, whether the first thread and a thread in the target process different from the first thread will form the locking loop; if it is determined that the first thread and a thread in the target process different from the first thread will form the locking loop, determine that there is deadlock logic in the thread of the target process.

[0162] In an optional embodiment, the apparatus is further configured to: obtain a proposed unlock report corresponding to a target thread in the target process, wherein the proposed unlock report is used to indicate that the target thread is ready to release the target lock resource; determine whether the target lock resource has been acquired by a thread in the target process; and if the target lock resource has not been acquired by a thread in the target process, determine that a second abnormal usage event exists, wherein the second abnormal usage event indicates that the unacquired lock resource is ready to be released.

[0163] In an optional embodiment, the apparatus is further configured to determine the existence of a third abnormal usage event when the target lock resource has been acquired by a thread in the target process and the thread is different from the target thread, wherein the third abnormal usage event indicates that the lock resource not acquired by the target thread is ready to be released.

[0164] In an optional embodiment, the apparatus is further configured to determine the existence of a fourth abnormal usage event when the target lock resource has been acquired by the target thread and the target lock resource is not the last lock resource acquired in the target lock resource set, wherein the target lock resource set includes all lock resources acquired by the target thread that have not yet been released, and the fourth abnormal usage event indicates that the release of the target lock resource does not conform to a preset lock resource release logic, wherein the lock resource release logic indicates that the lock resource acquired later needs to be released first.

[0165] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0166] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0167] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0168] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0169] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0170] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0171] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0172] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for detecting abnormal use of lock resources, characterized in that, include: Obtain the locking branch tree of each thread in the target process, wherein each locking branch in the locking branch tree is used to record the order in which the corresponding thread acquires lock resources within a historical time period; Based on the locking branch tree of each thread, determine whether the target process will form a locking loop; If it is determined that the locking loop will be formed, it is determined that there is deadlock logic in the threads of the target process; The method further includes: obtaining a lock acquisition report corresponding to a first thread in the target process, wherein the lock acquisition report is used to indicate that the first thread is preparing to acquire a first lock resource; if the first lock resource has been acquired by a second thread, and the second thread is a different thread from the first thread, determining whether a thread loop exists among the threads in the target process based on the lock resource usage information of each thread in the target process, wherein the lock resource that each thread in the thread loop is preparing to acquire is the lock resource that the next thread in the thread loop has already acquired, and the lock resource usage information of each thread is used to identify the lock resource that each thread is preparing to acquire and the lock resource that each thread has already acquired; if the existence of the thread loop is determined, determining that a deadlock has occurred in the threads of the target process.

2. The method according to claim 1, characterized in that, Determining whether the target process will form a locking loop based on the locking branch tree of each thread includes: Select one locking branch from the locking branch tree corresponding to each thread to form a locking branch set; Construct a corresponding locking path graph for the locking branch set, wherein the locking path graph includes a set of nodes, each node in the set of nodes corresponds to a different lock resource, and two nodes in the set of nodes that have a connection relationship are two nodes in the locking branch set that have a connection relationship, and the connection relationship indicates the order in which the two lock resources corresponding to the two nodes are acquired; If the locking loop exists in the locking path graph, it is determined that the target process will form the locking loop.

3. The method according to claim 2, characterized in that, The construction of the corresponding locking path graph for the set of locked branches includes: In the locking branch set, nodes corresponding to the same lock resource are searched. If multiple nodes corresponding to the same lock resource are found, the multiple nodes in the locking branch set are merged to obtain the locking path graph.

4. The method according to claim 1, characterized in that, The step of determining whether a thread loop exists among the threads in the target process based on the lock resource usage information of each thread in the target process includes: Step 1: Determine whether the i-th thread is ready to acquire the lock resource. If the i-th thread is ready to acquire the lock resource, mark the lock resource that the i-th thread is ready to acquire as the i-th lock resource and execute Step 2. Otherwise, execute Step 5. Here, i is a positive integer greater than or equal to 1. When i=1, the marked first thread is the second thread. Step 2: Search for the thread that has acquired the i-th lock resource in each thread of the target process. If a thread that has acquired the i-th lock resource is found, mark the found thread that has acquired the i-th lock resource as the (i+1)-th thread and execute Step 3. If no thread that has acquired the i-th lock resource is found, execute Step 5. Step 3: Determine whether the (i+1)th thread is a thread in the target thread set. If the (i+1)th thread is a thread in the target thread set, execute Step 4, wherein the target thread set includes the marked 1st thread to the i-th thread and the first thread; if the (i+1)th thread is not a thread in the target thread set, i = i+1, and execute Step 1. Step 4: Determine whether a thread loop exists in any of the threads within the target process; Step 5: Determine that there is no thread loop in any of the threads in the target process.

5. The method according to claim 1, characterized in that, The method further includes: If the first lock resource is not acquired by any of the threads in the target process, the lock resource usage information of the first thread is marked as ready to acquire the first lock resource; If the first lock resource has been acquired by the first thread, a first abnormal usage event is determined to exist, wherein the first abnormal usage event indicates that the first thread repeatedly acquires the lock resource.

6. The method according to claim 5, characterized in that, After marking the lock resource usage information of the first thread as ready to acquire the first lock resource, the method further includes: Obtain the successful lock acquisition report corresponding to the first thread, wherein the successful lock acquisition report is used to indicate that the first thread has successfully acquired the first lock resource; The lock resource usage information of the first thread is marked as the first thread has acquired the first lock resource, and the locking branch tree of the first thread is updated, wherein each locking branch in the locking branch tree is used to record the order in which the first thread acquires the lock resource; Based on each locking branch in the updated locking branch tree of the first thread, determine whether the first thread and a thread in the target process that is different from the first thread will form the locking loop; If it is determined that the first thread and a thread in the target process that is different from the first thread will form the locking loop, it is determined that there is a deadlock logic in the thread of the target process.

7. The method according to claim 1, characterized in that, The method further includes: Obtain the proposed unlock report corresponding to the target thread in the target process, wherein the proposed unlock report is used to indicate that the target thread is ready to release the target lock resource; Determine whether the target lock resource has been acquired by a thread in the target process; If the target lock resource is not acquired by a thread in the target process, a second abnormal usage event is determined to exist, wherein the second abnormal usage event indicates that the unacquired lock resource is ready to be released.

8. The method according to claim 7, characterized in that, The method further includes: If the target lock resource has been acquired by a thread in the target process, and the thread is different from the target thread, a third abnormal usage event is determined to exist, wherein the third abnormal usage event indicates that the lock resource not acquired by the target thread is about to be released.

9. The method according to claim 7, characterized in that, The method further includes: If the target lock resource has been acquired by the target thread and the target lock resource is not the last lock resource acquired in the target lock resource set, a fourth abnormal usage event is determined to exist. The target lock resource set includes all lock resources that the target thread has acquired but has not yet released. The fourth abnormal usage event indicates that the release of the target lock resource does not conform to the preset lock resource release logic, which states that lock resources acquired later need to be released first.

10. A detection device for abnormal use of lock resources, characterized in that, include: An acquisition device is used to acquire the locking branch tree of each thread in a target process, wherein each locking branch in the locking branch tree is used to record the order in which the corresponding thread acquires lock resources within a historical time period; A first determining device is used to determine whether the target process will form a locking loop based on the locking branch tree of each thread; The second determining device, upon determining that the locking loop will be formed, determines that there is deadlock logic in the threads of the target process; The apparatus is further configured to: acquire a lock-acquiring report corresponding to a first thread in the target process, wherein the lock-acquiring report is used to indicate that the first thread is preparing to acquire a first lock resource; if the first lock resource has been acquired by a second thread, and the second thread is a different thread from the first thread, determine whether a thread loop exists among the threads in the target process based on the lock resource usage information of each thread in the target process, wherein the lock resource that each thread in the thread loop is preparing to acquire is the lock resource that the next thread in the thread loop has already acquired, and the lock resource usage information of each thread is used to identify the lock resource that each thread is preparing to acquire and the lock resource that each thread has already acquired; if the existence of the thread loop is determined, determine that a deadlock has occurred in the threads of the target process.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 9.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 9.

Images