Thread deadlock detection method, device, equipment, medium and computer program product

Abstract

The present application relates to a thread deadlock detection method, device, equipment, medium and computer program product. The method comprises: obtaining an operation instruction of a target thread for a target lock, and when the operation instruction is to apply for a target lock, calling a preset target program to apply for the target lock according to the operation instruction, and obtaining an application result indicating whether the target lock is successfully applied for; calling the target program to determine the deadlock result of the target thread according to the application result. Without manual intervention, it is possible to detect in real time whether a deadlock occurs when the target thread applies for a target lock, and a preset target program common to multiple programming languages ​​is used to implement deadlock detection, which solves the problem of poor versatility, and does not require changes to the program code, thereby reducing security risks. The present method takes into account real-time, versatility and security.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a thread deadlock detection method, apparatus, device, medium and computer program product. Background Art

[0002] In the process of computer system operation, threads may be blocked due to competition for resources or communication with each other. Without external force, they will not be able to move forward. At this time, the system is called deadlock or the system has deadlocked. These processes that are always waiting for each other are called deadlock processes.

[0003] The prior art can detect deadlock by modifying the Pthreads library method, combining pstack with gdp and a Java-specific thread deadlock detection mechanism to determine whether a deadlock state occurs during the operation of a Linux system.

[0004] However, the current thread deadlock detection method has the problem of not being able to take into account the real-time, security and versatility of the detection. Summary of the invention

[0005] Based on this, it is necessary to provide a thread deadlock detection method, device, equipment, medium and computer program product that can take into account the real-time, security and versatility of detection in order to address the above technical problems.

[0006] In a first aspect, the present application provides a thread deadlock detection method. The method comprises:

[0007] Get the target thread's operation instruction on the target lock;

[0008] In the case where the operation instruction is to apply for a target lock, the preset target program is called to apply for the target lock according to the operation instruction to obtain an application result; the application result is used to indicate whether the target lock is successfully applied;

[0009] The target program is called to determine the deadlock result of the target thread according to the application result.

[0010] In one embodiment, calling a preset target program to apply for a target lock according to an operation instruction and obtaining an application result includes:

[0011] According to the operation instruction, the preset target program is called to search the thread holding state of the target lock in the thread graph;

[0012] According to the thread holding state of the target lock, the application result of the target thread applying for the target lock is determined.

[0013] In one embodiment, determining the application result of the target thread applying for the target lock according to the thread holding state of the target lock includes:

[0014] If the target lock is already held by an existing thread, the application result is application failure;

[0015] If the target lock is not held by any existing thread, the application result is successful.

[0016] In one embodiment, determining the deadlock result of the target thread according to the application result includes:

[0017] If the application result is successful, the deadlock result of the target thread is determined to be no deadlock, and the corresponding relationship between the target thread and the target lock is updated in the thread graph;

[0018] If the application result is failure, then check whether there is a directed cycle graph in the thread graph and obtain the test result;

[0019] The deadlock result of the target thread is determined according to the detection result.

[0020] In one embodiment, determining the deadlock result of the target thread according to the detection result includes:

[0021] If the detection result is that there is a directed cycle graph in the thread graph, the deadlock result is determined to be a deadlock;

[0022] If the detection result is that there is no directed cycle graph in the thread graph, the deadlock result is determined to be no deadlock.

[0023] In one embodiment, the operation instruction indicates releasing the target lock; the method further includes:

[0024] According to the operation instruction, the preset target program is called to delete the corresponding relationship between the target thread and the target lock in the thread graph.

[0025] In a second aspect, the present application also provides a thread deadlock detection device. The device comprises:

[0026] An acquisition module is used to obtain the operation instruction of the target thread on the target lock;

[0027] The first calling module is used to call a preset target program to apply for the target lock according to the operation instruction when the operation instruction is to apply for the target lock, and obtain the application result; the application result is used to indicate whether the target lock is successfully applied;

[0028] The second calling module is used to call the target program to determine the deadlock result of the target thread according to the application result.

[0029] In a third aspect, the present application further provides a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the steps of the method in any one of the embodiments of the first aspect are implemented.

[0030] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the method in any one of the embodiments of the first aspect when executed by a processor.

[0031] In a fifth aspect, the present application further provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the method in any one of the embodiments of the first aspect are implemented.

[0032] The above-mentioned thread deadlock detection method, device, equipment, medium and computer program product obtain the target thread's operation instruction for the target lock. When the operation instruction is to apply for the target lock, the preset target program is called to apply for the target lock according to the operation instruction, and an application result indicating whether the target lock is successfully applied is obtained; the target program is called to determine the deadlock result of the target thread according to the application result. Without manual intervention, it is possible to detect in real time whether there is a deadlock when the target thread applies for the target lock, and a preset target program common to multiple programming languages ​​is used to implement deadlock detection, which solves the problem of poor versatility, and does not require changes to the program code, reducing security risks. This method takes into account real-time, versatility and security. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A schematic diagram of a process flow of a thread deadlock method in one embodiment;

[0034] Figure 2 A schematic diagram of a process flow of a thread deadlock method in one embodiment;

[0035] Figure 3 is a flowchart of a thread deadlock method in another embodiment;

[0036] Figure 4 A schematic diagram of thread deadlock in one embodiment;

[0037] Figure 5 A schematic diagram of thread deadlock-free in one embodiment;

[0038] Figure 6 is a flowchart of a thread deadlock method in another embodiment;

[0039] Figure 7 is a structural block diagram of a thread deadlock detection device in one embodiment;

[0040] Figure 8 is a structural block diagram of a thread deadlock detection device in one embodiment;

[0041] Fig. 9FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0043] During the operation of a computer system, threads may be blocked due to competition for resources or communication with each other. Without external force, they will not be able to move forward. At this time, the system is said to be in a deadlock state or the system has a deadlock. Therefore, it is necessary to detect thread deadlock. In the prior art, there are several ways to detect whether a deadlock state occurs during the operation of a Linux system. The first is to modify the Pthreads library method: modify the Pthreads library used by the C program in the Linux operating system, add a new synchronization mutex function, compile and generate a new Pthreads library, modify the system header file related to the original synchronization mutex function in the Linux operating system, use macro definition to point the original synchronization mutex function to the new synchronization mutex function, and the user uses the original synchronization mutex function and the new Pthreads library to jointly write, compile and run a multi-threaded C program. The deadlock detection program obtains the running data of the above multi-threaded C program from the computer shared memory to detect deadlock. The second is the manual analysis method of pstack combined with GDP: use pstack to view the process execution stack, and then use GDP to manually view who holds the lock that the process is waiting for, and then determine whether there is a deadlock. The third is Java deadlock detection: Java can dynamically obtain the owner of the lock and use its unique deadlock detection algorithm to detect deadlock in real time. However, since modifying the Pthreads library method requires modifying the Pthread library code, there is a risk of code intrusion; the combination of pstack and GDP requires constant human intervention and cannot guarantee online real-time detection; except for Java, which has its own specific deadlock detection mechanism, programs developed in other languages ​​do not have real-time online detection technology for single-process internal deadlocks. Therefore, the existing thread deadlock detection technology cannot take into account security, real-time and versatility.

[0044] In one embodiment, Figure 1 As shown, a thread deadlock detection method is provided. This embodiment uses the method applied to a terminal as an example for illustration. It can be understood that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0045] S102, obtaining an operation instruction of a target thread on a target lock.

[0046] The operation instruction may include applying for a target lock or releasing a target lock, which is not limited here.

[0047] Specifically, when the system is running, there may be multiple threads running. If one of the threads needs to apply for the target resource at this time, it can apply for the target lock containing the target resource and trigger the operation instruction. That is, at this time, the terminal obtains the operation instruction of the target thread applying for the target lock. For example, during the operation of the system, there is a target thread 1 that applies for target lock A. At this time, the operation instruction of target thread 1 applying for target lock A can be triggered. It is also possible that during the operation of the system, the target thread already holds the target lock. After the target thread no longer needs the target resource of the target lock, the operation of releasing the target lock can be triggered, and the operation instruction of the target thread to release the target lock can be obtained. For example, if there is a target thread 2 that already holds target lock B, the operation instruction of target thread 2 to release target lock B can be triggered to release the possession relationship.

[0048] S104, when the operation instruction is to apply for a target lock, a preset target program is called to apply for the target lock according to the operation instruction to obtain an application result; the application result is used to indicate whether the target lock is successfully applied for.

[0049] Among them, the preset target program may include an eBPF program, a BPF program, etc., which is not limited here.

[0050] Specifically, during the operation of the system, the process of the target thread applying for the lock needs to call the pthread_mutex_lock function and the pthread_mutex_unlock function in the Pthread library through the portable operating system interface (POSIX), and the above function prototype can be int pthread_mutex_lock (pthread_mutex_t*mutex). Therefore, the function pthread_mutex_lock function in the Pthread library of the POSIX interface can be loaded at the entrance and exit. In the case where the operation instruction is to apply for the target lock, the preset target program is called to apply for the target lock according to the operation instruction, and the target lock is found to be held by an existing thread. If the target lock is already held by an existing thread, the application fails, and if the target lock is not held by an existing thread, the application is successful. For example, the mutex address of the target lock can be obtained by executing the eBPF entry program, and the return value can be obtained by executing the eBPF exit program before returning. When the return value is 0, it means that the lock is successfully acquired, and the lock is held, that is, the application is successful. If the mutex address of the target lock is held by other processes, after the eBPF entry program ends, it will enter a blocked state, waiting for the release of other processes, that is, the application fails. This can be achieved through the following program code.

[0051] int pthread_mutex_lock(pthread_mutex_t*mutex)

[0052] {

[0053] enter_probe; / / Get mutex address

[0054] ... / / The implementation process of the original function of pthread_mutex_lock

[0055] exit_probe; / / get the return value ret

[0056] return ret;

[0057] }

[0058] Optionally, after other processes release the target lock, they exit the blocked state and the target thread can apply for the target lock again. Before returning, the eBPF exit program is called with a return value of 0. At this time, the target thread successfully applies for the target lock.

[0059] S106, calling the target program to determine the deadlock result of the target thread according to the application result.

[0060] Specifically, when the target thread fails to apply for the target lock, it is necessary to determine whether the target thread is deadlocked when applying for the target lock. This can be done by calling a preset target program to find out whether there is a circular directed edge in the thread graph in the target program. If there is a circular directed edge, it indicates that the target thread is deadlocked. It is also possible to call the target program to find the target lock currently held by each thread collected and recorded in real time in the preset database, and determine whether there is a circular directed edge in the target thread. If so, it proves that the target thread is deadlocked.

[0061] Optionally, when the deadlock result of the target thread is that a deadlock exists, an alarm message may be sent for warning.

[0062] In the above-mentioned thread deadlock detection method, by obtaining the target thread's operation instruction for the target lock, when the operation instruction is to apply for the target lock, the preset target program is called to apply for the target lock according to the operation instruction, and an application result indicating whether the target lock is successfully applied is obtained; the target program is called to determine the deadlock result of the target thread according to the application result. Without manual intervention, it is possible to detect in real time whether there is a deadlock when the target thread applies for the target lock, and a preset target program common to multiple programming languages ​​is used to implement deadlock detection, which solves the problem of poor versatility, and does not require changes to the program code, reducing security risks. This method takes into account real-time, versatility, and security.

[0063] The above embodiment describes the thread deadlock detection method. In the process of the target thread applying for the target lock, it is necessary to first determine the application result of the thread applying for the resource. Now, an embodiment is used to describe how to determine the application result of the target thread for the target lock according to the operation instruction. In one embodiment, Figure 3 As shown, the preset target program is called to apply for the target lock according to the operation instruction, and the application result is obtained, including:

[0064] S202: According to the operation instruction, a preset target program is called to search for the thread holding state of the target lock in the thread graph.

[0065] Specifically, when the target thread fails to apply for the target lock, the preset target program is called to find the thread holding status of the target lock in the thread map. In the thread map locked Threa dmap, the data structure key is the address of the lock, that is, the mutex address obtained by the eBPF technology; the value is the thread number, representing the thread. The holding status can include holding and not holding.

[0066] Preferably, the preset target program is an eBPF program.

[0067] S204, determining the application result of the target thread applying for the target lock according to the thread holding state of the target lock.

[0068] Specifically, if the target lock is held by an existing thread, the application result is an application failure; if the target lock is not held by an existing thread, the application result is an application success.

[0069] Further, in one embodiment, if Figure 3 As shown, according to the application result, the deadlock result of the target thread is determined, including:

[0070] S302: If the application result is successful, determine that the deadlock result of the target thread is no deadlock, and update the corresponding relationship between the target thread and the target lock into the thread graph.

[0071] Specifically, if the target thread successfully applies for the target lock, it can be determined that the target thread will not be deadlocked. At this time, the correspondence between the target thread and the target lock is added to the thread map. For example, if thread T1 successfully calls to apply for and holds lock A, the lock address of A is used as the key and the thread number of T1 is used as the value to be recorded in the locked Thread map.

[0072] S304: If the application result is failure, then detect whether there is a directed cycle graph in the thread graph to obtain a detection result.

[0073] Specifically, if the target thread fails to apply for the target lock, it is necessary to further determine whether the target thread will deadlock. By calling the preset target program, such as the eBPF program, find out whether there is a directed cycle graph in the thread graph. Before searching for the directed cycle graph, the directed edge formed by the target lock and the target thread can be added to the thread graph. For example, thread T1 calls pthread_mutex_lock to apply for lock A, and queries the lockedThreadmap (thread graph) for the lock A holding thread. If there is a holding thread T2, the application fails, and the directed edge (T1->T2) is recorded in the thread graph. Among them, a directed cycle graph refers to a cycle with a certain point as the starting point and a path along the directed edge that can return to the starting point. In a directed cycle graph, starting from a thread and moving along the directed edge, you can return to the thread.

[0074] S306: Determine the deadlock result of the target thread according to the detection result.

[0075] Specifically, if the detection result is that there is a directed cycle graph in the thread graph, the deadlock result is determined to be a deadlock, such as Figure 4 As shown; if the detection result is that there is no directed cycle graph in the thread graph, the deadlock result is determined to be no deadlock, such as Figure 5 shown.

[0076] In this embodiment, according to the operation instruction, the preset target program is called to find the thread holding state of the target lock in the thread graph, and the application result of the target thread applying for the target lock is determined according to the thread holding state of the target lock. According to the application result, it can be preliminarily judged whether there is a deadlock. When the application is successful, the target thread must not be deadlocked. When it fails, consider whether the directed cycle graph exists to determine the final deadlock result. The method is simple and effective, does not require participation, and does not require modification of program code. It can be applied to multiple programming languages ​​using the eBPF program. The method takes into account security, versatility and real-time performance.

[0077] In the above embodiments, the acquired operation instruction is to apply for a target lock for a target thread. Now, an embodiment is used to illustrate the case where the operation instruction is to release. In one embodiment, the thread deadlock detection method further includes:

[0078] According to the operation instruction, the preset target program is called to delete the corresponding relationship between the target thread and the target lock in the thread graph.

[0079] Specifically, if the operation instruction at this time is to release the target lock held by the target thread, the corresponding relationship between the target thread and the target lock in the thread graph can be deleted by calling the preset target program. And, if there is a directed edge of the target thread in the thread graph, the directed edge related to the target lock corresponding to the target thread is deleted at the same time. For example, the target thread calls the pthread_mutex_unlock function to release the target lock, removes the relationship between the target lock and the target thread in the locked Thread map, and deletes the directed edge related to the lock. For example, the process of the target process releasing the target lock needs to call the pthread_mutex_unlock function, and the prototype of the pthread_mutex_unlock function is int pthread_mutex_unlock(pthread_mutex_t*mutex). Execute the eBPF entry program at the entry of the Pthread library of the POSIX interface to obtain the mutex address, and execute the eBPF exit program before returning to obtain the return value. When the return value is 0, it means that the lock is released successfully and the lock is no longer held.

[0080] int pthread_mutex_unlock(pthread_mutex_t*mutex)

[0081] {

[0082] enter_probe; / / Get mutex address

[0083] ... / / pthread_mutex_unlock original function implementation process

[0084] exit_probe; / / get the return value ret

[0085] return ret;

[0086] }

[0087] In this embodiment, by calling the preset target program to delete the correspondence between the target thread and the target lock in the thread graph according to the operation instruction, the correspondence between each thread and each lock in the thread graph can be updated in real time to ensure the accuracy of deadlock detection of the target thread.

[0088] In the above embodiment, the thread deadlock detection method is described. To facilitate the understanding of those skilled in the art, the thread deadlock detection method is further described by an embodiment. In one embodiment, Figure 6 As shown, the thread deadlock detection method includes:

[0089] S602, obtaining an operation instruction of a target thread on a target lock.

[0090] S604, when the operation instruction is to apply for a target lock, according to the operation instruction, a preset target program is called to search for a thread holding state of the target lock in the thread graph.

[0091] S606, according to the thread holding state of the target lock, determine the application result of the target thread applying for the target lock. S608, if the holding state of the target lock is held by an existing thread, the application result is application failure;

[0092] S610: If the target lock is not held by any existing thread, the application result is successful.

[0093] S612: If the application result is successful, determine that the deadlock result of the target thread is no deadlock, and update the corresponding relationship between the target thread and the target lock into the thread map.

[0094] S614, if the application result is failure, then detect whether there is a directed cycle graph in the thread graph and obtain the detection result.

[0095] S616, if the detection result is that there is a directed cycle graph in the thread graph, then the deadlock result is determined to be a deadlock;

[0096] S618: If the detection result is that there is no directed cycle graph in the thread graph, the deadlock result is determined to be no deadlock.

[0097] S620: According to the operation instruction, a preset target program is called to delete the corresponding relationship between the target thread and the target lock in the thread graph.

[0098] In this embodiment, by obtaining the target thread's operation instruction for the target lock, when the operation instruction is to apply for the target lock, the preset target program is called to apply for the target lock according to the operation instruction, and an application result indicating whether the target lock is successfully applied is obtained; the target program is called to determine the deadlock result of the target thread according to the application result. Without manual intervention, it is possible to detect in real time whether there is a deadlock when the target thread applies for the target lock, and a preset target program that is common to multiple programming languages ​​is used to implement deadlock detection, which solves the problem of poor versatility, and does not require changing the program code, reducing security risks. This method takes into account real-time, versatility, and security.

[0099] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0100] Based on the same inventive concept, the embodiment of the present application also provides a thread private lock detection device for implementing the thread deadlock detection method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more thread deadlock detection device embodiments provided below can refer to the limitations of the thread deadlock detection method above, and will not be repeated here.

[0101] In one embodiment, Figure 7 As shown, a thread deadlock detection device is provided, comprising:

[0102] An acquisition module 701 is used to acquire an operation instruction of a target thread on a target lock;

[0103] The first calling module 702 is used to call a preset target program to apply for the target lock according to the operation instruction and obtain an application result when the operation instruction is to apply for the target lock; the application result is used to indicate whether the target lock is successfully applied;

[0104] The second calling module 703 is used to call the target program to determine the deadlock result of the target thread according to the application result.

[0105] In this embodiment, the target thread obtains the operation instruction of the target lock through the acquisition module. When the operation instruction is to apply for the target lock, the first determination module calls the preset target program to apply for the target lock according to the operation instruction, and obtains the application result indicating whether the target lock is successfully applied; the second determination module calls the target program to determine the deadlock result of the target thread according to the application result. Without manual intervention, it is possible to detect in real time whether there is a deadlock when the target thread applies for the target lock, and the preset target program common to multiple programming languages ​​is used to realize the deadlock detection, which solves the problem of poor versatility, and does not need to change the program code, reducing the security risk. This method takes into account real-time, versatility and security.

[0106] In one embodiment, Figure 8 As shown, the first calling module 702 includes:

[0107] The calling unit 7021 is used to call a preset target program to find the thread holding state of the target lock in the thread graph according to the operation instruction;

[0108] The first determining unit 7022 is used to determine the application result of the target thread applying for the target lock according to the thread holding state of the target lock.

[0109] In one embodiment, the first calling module is specifically used to determine that if the target lock is held by an existing thread, the application result is an application failure; if the target lock is not held by an existing thread, the application result is an application success.

[0110] In one embodiment, see Figure 8 As shown, the second calling module 703 includes:

[0111] The second determining unit 7031 is used to determine the deadlock result of the target thread as no deadlock if the application result is successful, and update the corresponding relationship between the target thread and the target lock in the thread graph;

[0112] The detection unit 7032 is used to detect whether there is a directed cycle graph in the thread graph if the application result is failure, and obtain a detection result;

[0113] The third determining unit 7033 is used to determine the deadlock result of the target thread according to the detection result.

[0114] In one embodiment, the third determination unit is specifically used to determine the deadlock result as deadlock if the detection result is that there is a directed cycle graph in the thread graph; if the detection result is that there is no directed cycle graph in the thread graph, determine the deadlock result as no deadlock.

[0115] In one embodiment, see Figure 8 As shown, the thread deadlock detection device also includes:

[0116] The deletion module 704 is used to call a preset target program to delete the corresponding relationship between the target thread and the target lock in the thread graph according to the operation instruction.

[0117] Each module in the thread deadlock detection device can be implemented in whole or in part by software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute operations corresponding to each module.

[0118] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Fig. 9 As shown. The computer device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be achieved through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a thread deadlock detection method is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covered on the display screen, or a key, trackball or touchpad set on the computer device housing, or an external keyboard, touchpad or mouse, etc.

[0119] Those skilled in the art will understand that Fig. 9 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0120] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0121] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0122] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0123] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0124] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0125] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0126] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A thread deadlock detection method, characterized in that: The method comprises: Get the target thread's operation instruction on the target lock; In the case where the operation instruction is to apply for a target lock, a preset target program is called to apply for the target lock according to the operation instruction to obtain an application result; the application result is used to indicate whether the target lock is successfully applied for; the preset target program is an eBPF program common to multiple programming languages; Calling the target program to determine the deadlock result of the target thread according to the application result; If the deadlock result is that a deadlock exists, output an alarm message; When the operation instruction is to release the target lock, the preset target program is called to delete the corresponding relationship between the target thread and the target lock in the thread graph.

2. The method according to claim 1, characterized in that The calling of the preset target program applies for the target lock according to the operation instruction to obtain the application result, including: According to the operation instruction, calling the preset target program to search for the thread holding state of the target lock in the thread graph; According to the thread holding state of the target lock, an application result of the target thread applying for the target lock is determined.

3. The method according to claim 2, characterized in that The step of determining the application result of the target thread applying for the target lock according to the thread holding state of the target lock comprises: If the target lock is already held by an existing thread, the application result is application failure; If the target lock is not held by any existing thread, the application result is successful.

4. The method according to claim 3, characterized in that Determining the deadlock result of the target thread according to the application result includes: If the application result is successful, determining the deadlock result of the target thread is no deadlock, and updating the corresponding relationship between the target thread and the target lock in the thread graph; If the application result is failure, detecting whether there is a directed cyclic graph in the thread graph to obtain a detection result; The deadlock result of the target thread is determined according to the detection result.

5. The method according to claim 4, characterized in that Determining the deadlock result of the target thread according to the detection result includes: If the detection result is that the directed cycle graph exists in the thread graph, determining that the deadlock result is a deadlock; If the detection result is that the directed cycle graph does not exist in the thread graph, the deadlock result is determined to be no deadlock.

6. The method according to claim 2, characterized in that The thread holding state includes holding and not holding.

7. A thread deadlock detection device, characterized in that: The device comprises: An acquisition module is used to obtain the operation instruction of the target thread on the target lock; A first calling module is used for calling a preset target program to apply for the target lock according to the operation instruction when the operation instruction is to apply for the target lock, and obtaining an application result; the application result is used to indicate whether the target lock is successfully applied; the preset target program is an eBPF program common to multiple programming languages; A second calling module is used to call the target program to determine the deadlock result of the target thread according to the application result; if the deadlock result is that a deadlock exists, output an alarm message; The deletion module is used to call the preset target program to delete the corresponding relationship between the target thread and the target lock in the thread graph when the operation instruction is to release the target lock.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images