Deadlock monitoring method and device and medium

Abstract

The invention provides a deadlock monitoring method and device and a medium, and relates to the technical field of software, the method comprises the following steps: establishing a mapping 1 of a blocked thread and a lock of a target thread set, and a mapping 2 of an occupied lock and the thread; acquiring a blocked thread 1 from the mapping 1, acquiring a lock 1 corresponding to the blocked thread 1, acquiring a lock 2 corresponding to the thread 1 in the mapping 2, and acquiring a thread 2 corresponding to the lock 1 in the mapping 2; when i = 1, executing the following judgment: acquiring a lock i + 2 corresponding to the thread i + 1 in the mapping j, and / or a thread i + 2 corresponding to the lock i + 1 in the mapping j, when i is an odd number, j = 1, when i is an even number, if the lock i + 2 exists and the lock i + 2 is the lock i + 1, and / or the thread i + 2 exists and the thread i + 2 is the thread i + 1, judging that deadlock occurs to the thread 1 to the thread i + 1, and if the lock i + 2 exists and the lock i + 2 is not the lock i + 1, and / or the thread i + 2 exists and the thread i + 2 is not the thread i + 1, executing the following judgment; and making i = i + 1 and repeating the above judgment.

Description

Technical Field

[0001] The present application relates at least to the field of software technology, and in particular to a deadlock monitoring method, device, and medium. Background Art

[0002] In multithreaded programming, locks are often used to serialize access to shared data by multiple threads, preventing inconsistent data states caused by simultaneous modifications. Locking can largely address the issue of out-of-order access to shared data by multiple threads, but in extreme cases, deadlock can occur. Existing technologies can monitor thread blocking conditions but cannot determine whether the blockage is permanent (i.e., deadlock), which can lead to serious production failures. Summary of the Invention

[0003] In response to the above-mentioned deficiencies, the present application provides a deadlock monitoring method, device and medium to solve the following technical problem: how to determine multi-thread deadlock problems.

[0004] In a first aspect, the present application provides a deadlock monitoring method, the method comprising:

[0005] Establish a mapping 1 between blocked threads and locks of the target thread set, and a mapping 2 between occupied locks and threads;

[0006] Get the blocked thread 1 from map 1, and the lock 1 corresponding to the blocked thread 1, get the lock 2 corresponding to thread 1 in map 2, and the lock 1 corresponding to thread 2 in map 2;

[0007] Starting from i=1, the following judgment is performed:

[0008] Get the lock i+2 corresponding to thread i+1 in mapping j, and / or the lock i+1 corresponding to thread i+2 in mapping j, when i is odd, j=1, when i is even, j=2,

[0009] If lock i+2 exists and lock i+2 is lock i+1, and / or thread i+2 exists and thread i+2 is thread i+1, it is determined that thread 1 to thread i+1 is deadlocked.

[0010] If lock i+2 exists and lock i+2 is not lock i+1, and / or thread i+2 exists and thread i+2 is not thread i+1, set i=i+1 and repeat the above judgment.

[0011] Furthermore, a mapping 1 between blocked threads and locks, and a mapping 2 between occupied locks and threads of the target thread set are established, specifically including:

[0012] Obtain an event request manager of the target application, and create a monitoring blocking event request and a monitoring occupation event request in the event request manager;

[0013] If a thread in the target application is blocked while trying to acquire a lock, the blocking event monitoring request records the blocked thread and the lock as a set of corresponding relationships and adds them to mapping 1;

[0014] If a thread successfully acquires a lock when the target application is running, the monitoring occupation event request records the successfully acquired thread and the lock as a set of corresponding relationships and adds them to mapping 2, and deletes all mappings of at least one of the successfully acquired thread and the lock contained in mapping 1 before the current occupation moment.

[0015] Furthermore, the event request manager of the target application is obtained, and a monitoring blocking event request and a monitoring occupation event request are created in the event request manager, specifically including:

[0016] Pre-install a monitoring execution script on the server where the target application is located. The monitoring execution script includes an event request manager connected to the target application.

[0017] The server where the target application is located receives a first instruction to enable deadlock monitoring for the target application, runs a monitoring execution script according to the first instruction to connect to the event request manager of the target application, and creates a monitoring blocking event request and a monitoring occupying event request in the event request manager.

[0018] Furthermore, the server where the target application is located receives a first instruction to enable deadlock monitoring for the target application, and runs a monitoring execution script according to the first instruction, specifically including:

[0019] The developer enters the target application name to enable deadlock monitoring through the visualization page. The front-end device where the visualization page is located generates an operation request including the target application name and sends it to the server where the target application is located.

[0020] The server where the target application is located receives the operation request, obtains the target application name, and runs the corresponding monitoring execution script according to the target application name.

[0021] Furthermore, after obtaining an event request manager of the target application and creating a monitoring blocking event request and a monitoring occupying event request in the event request manager, the method further includes:

[0022] Create an event queue in the event request manager, and add each event triggered by the monitoring blocking event request and the monitoring occupying event request to the event queue in the order of triggering time;

[0023] Create at least three global static key-value pair mappings:

[0024] The first key-value pair mapping belongs to mapping 1, with a blocked thread as the key and a blocked lock as the value.

[0025] The second key-value pair mapping belongs to mapping 2, with an occupied thread as the key and an occupied lock as the value.

[0026] The third key-value pair mapping belongs to mapping 2, with an occupied lock as the key and an occupied thread as the value;

[0027] If a new event is received in the event queue, determine whether the new event comes from a monitoring blocking event request or a monitoring occupied event request. If the new event comes from a monitoring blocking event request, obtain the thread and lock corresponding to the new event as thread 1 and lock 1, and obtain mapping 1 and mapping 2 before the new event trigger time.

[0028] Furthermore, the method further comprises:

[0029] Create a global static fourth key-value pair mapping. The fourth key-value pair mapping belongs to mapping 1, with a blocked lock as the key and a blocked thread as the value.

[0030] Furthermore, after determining that thread 1 to thread i+1 are deadlocked, the method further includes:

[0031] Get the thread names of threads 1 to i+1 where deadlock occurs, the lock names of locks 1 to i+1, and the code block name where at least one of the locks from locks 1 to i+1 is located;

[0032] The developer is displayed the target application name, thread names of deadlocked threads 1 to i+1, lock names of locks 1 to i+1, and the code block name where at least one of the locks from locks 1 to i+1 is located.

[0033] Furthermore, the method further comprises:

[0034] According to the second instruction of the developer, at least one thread among threads 1 to i+1 where deadlock occurs processes data of at least one lock of locks 1 to i+1 and then kills the at least one thread;

[0035] The target application receives the code modified by the developer for the code block where at least one lock among lock 1 to lock i+1 is located.

[0036] In a second aspect, the present application provides a deadlock monitoring device, comprising:

[0037] A mapping module, used to establish a mapping 1 between blocked threads and locks, and a mapping 2 between occupied locks and threads of a target thread set;

[0038] The starting module is connected to the mapping module and is used to obtain the blocked thread 1 and the lock 1 corresponding to the blocked thread 1 from the mapping 1, obtain the lock 2 corresponding to the thread 1 in the mapping 2, and the lock 1 corresponding to the thread 2 in the mapping 2;

[0039] The judgment module is connected to the starting module and is used to perform the following judgment starting from i=1:

[0040] Get the lock i+2 corresponding to thread i+1 in mapping j, and / or the lock i+1 corresponding to thread i+2 in mapping j, when i is odd, j=1, when i is even, j=2,

[0041] If lock i+2 exists and lock i+2 is lock i+1, and / or thread i+2 exists and thread i+2 is thread i+1, it is determined that thread 1 to thread i+1 is deadlocked.

[0042] If lock i+2 exists and lock i+2 is not lock i+1, and / or thread i+2 exists and thread i+2 is not thread i+1, set i=i+1 and repeat the above judgment.

[0043] In a third aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the deadlock monitoring method as described above is implemented.

[0044] The present application provides a deadlock monitoring method, device and medium. By establishing a mapping between blocked threads and locks and a mapping between occupied locks and threads, the blocked threads and corresponding locks are obtained to determine whether they are occupied and / or blocked, and whether occupied and blocked threads and / or locks are mutually blocked. Based on this logic, it is determined whether a deadlock has occurred between the blocked threads. The deadlock can be automatically and timely analyzed, thereby helping developers solve deadlock problems and avoid production failures. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 This is a flowchart of a deadlock monitoring method according to an embodiment of the present application;

[0046] Figure 2 This is a structural diagram of a deadlock monitoring device according to an embodiment of the present application;

[0047] Figure 3 This is a flow chart of a deadlock monitoring determination method according to an embodiment of the present application;

[0048] Figure 4 This is an example diagram of a thread requiring operation of variables according to an embodiment of the present application;

[0049] Figure 5 This is an example diagram of a thread correctly operating variables in an embodiment of the present application;

[0050] Figure 6 This is another example diagram of a thread correctly operating variables in an embodiment of the present application;

[0051] Figure 7 This is an example diagram of a thread error operation variable in an embodiment of the present application;

[0052] Figure 8 This is an example diagram of a thread operation variable locking embodiment of the present application;

[0053] Figure 9 This is an example diagram of an embodiment of the present application for opening a deadlock monitoring page;

[0054] Figure 10 This is an example diagram of opening a deadlock monitoring prompt window in an embodiment of the present application;

[0055] Figure 11 This is an example diagram of a deadlock detected in an embodiment of the present application. DETAILED DESCRIPTION

[0056] In order to enable those skilled in the art to better understand the technical solution of the present application, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0057] It should be understood that the specific embodiments and drawings described herein are only used to explain the present application, rather than to limit the present application.

[0058] It can be understood that, in the absence of conflict, the various embodiments and features in the embodiments of the present application can be combined with each other.

[0059] It will be understood that, for the sake of ease of description, the drawings of this application only show the parts related to this application, while the parts not related to this application are not shown in the drawings.

[0060] It can be understood that each module and unit involved in the embodiments of the present application may correspond to only one physical structure, or may be composed of multiple physical structures, or multiple modules and units may be integrated into one physical structure.

[0061] It is understood that, in the absence of conflict, the functions and steps marked in the flowcharts and block diagrams of the present application may occur in an order different from that marked in the drawings.

[0062] It is understood that the flowcharts and block diagrams of the present application illustrate the possible architectures, functions, and operations of the systems, devices, equipment, and methods according to the various embodiments of the present application. Each box in the flowchart or block diagram may represent a module, unit, program segment, or code, which contains executable instructions for implementing the specified functions. Moreover, each box or combination of boxes in the block diagram and flowchart may be implemented by a hardware-based device that implements the specified functions, or by a combination of hardware and computer instructions.

[0063] It can be understood that the modules and units involved in the embodiments of the present application can be implemented by software or hardware, for example, the modules and units can be located in a processor.

[0064] Example 1:

[0065] like Figure 1 As shown, the present application provides a deadlock monitoring method, the method comprising:

[0066] Establish a mapping 1 between blocked threads and locks of the target thread set, and a mapping 2 between occupied locks and threads;

[0067] Get the blocked thread 1 from map 1, and the lock 1 corresponding to the blocked thread 1, get the lock 2 corresponding to thread 1 in map 2, and the lock 1 corresponding to thread 2 in map 2;

[0068] Starting from i=1, the following judgment is performed:

[0069] Get the lock i+2 corresponding to thread i+1 in mapping j, and / or the lock i+1 corresponding to thread i+2 in mapping j, when i is odd, j=1, when i is even, j=2,

[0070] If lock i+2 exists and lock i+2 is lock i+1, and / or thread i+2 exists and thread i+2 is thread i+1, it is determined that thread 1 to thread i+1 is deadlocked.

[0071] If lock i+2 exists and lock i+2 is not lock i+1, and / or thread i+2 exists and thread i+2 is not thread i+1, set i=i+1 and repeat the above judgment.

[0072] In this embodiment, the method establishes a mapping between blocked threads and locks and a mapping between occupied locks and threads, obtains information about blocked threads and corresponding locks to determine whether they are occupied and / or blocked, and determines whether occupied and blocked threads and / or locks are mutually blocked. Based on this logic, it determines whether deadlock has occurred between blocked threads, and can automatically and promptly analyze deadlocks, thereby helping developers resolve deadlock issues and avoid production failures. Figure 1 The method shown is applied to Figure 2 The device shown.

[0073] More specifically, if Figure 3 As shown, this embodiment provides a cyclic judgment process, which is as follows:

[0074] Get the lock i+2 corresponding to thread i+1 in mapping j, when i is an odd number, j=1, when i is an even number, j=2;

[0075] If lock i+2 does not exist, thread 1 is not deadlocked;

[0076] If lock i+2 exists, and lock i+2 is lock i+1, it is determined that thread 1 to thread i+1 is deadlocked;

[0077] If lock i+2 exists and lock i+2 is not lock i+1, obtain thread i+2 corresponding to lock i+1 in mapping j. When i is an odd number, j=1, and when i is an even number, j=2. Set i=i+1 and repeat the above judgment.

[0078] The above cyclic judgment process at least includes:

[0079] Get lock 3 corresponding to thread 2 in mapping 1;

[0080] If lock 3 exists and lock 3 is lock 2, it is determined that thread 1 and thread 2 are deadlocked.

[0081] Another equivalent judgment process is as follows:

[0082] Get lock i+1 in mapping j corresponding to thread i+2, when i is odd, j=1, when i is even, j=2;

[0083] If thread i+2 does not exist, thread 1 is not deadlocked;

[0084] If thread i+2 exists, and thread i+2 is thread i+1, it is determined that thread 1 to thread i+1 is deadlocked;

[0085] If thread i+2 exists and thread i+2 is not thread i+1, obtain the lock i+2 corresponding to thread i+1 in mapping j. When i is an odd number, j=1, and when i is an even number, j=2. Set i=i+1 and repeat the above judgment.

[0086] It can be understood that the above lock and thread labels represent the order in which they are taken from the map. If two locks or two threads are taken in one cycle, they can be judged once with the same label.

[0087] An example of multi-thread blocking cause analysis is as follows Figure 4-8As shown in Figure 2, in multi-threaded programming, locks are usually used to implement serial access to shared data by multiple threads, thereby avoiding inconsistent data states caused by simultaneous modifications of shared data.

[0088] like Figure 4 As shown, both thread 1 and thread 2 need to operate on variable a (initial value is 100) and variable b (initial value is 20). The logic of thread 1 is: first add 10 to a, then add 5 to b; the logic of thread 2 is: first add 10 to b, then add 5 to a. Assume that thread 1 first operates on a and b, and then thread b operates on a and b, and finally the value of a is 115 and the value of b is 35. Figure 5 As shown; suppose thread 2 first performs operations on a and b, and then thread 1 performs operations on a and b, and finally the value of a is 115 and the value of b is 35, as shown Figure 6 As shown; that is, under normal circumstances, no matter whether thread 1 or thread 2 executes the operation first, the final values of a and b are the same; but because a and b are shared data between threads 1 and 2, they may be executed out of order, such as Figure 7 As shown, although thread 1 starts to execute the operation first, thread 2 starts to execute the operation before thread 1 executes b=b+5 and writes the result into b (the value of b read by thread 2 is 20 at this time), so thread 2 adds 10 to the value of b, updating the value of b to 30. At this time, thread 1 also writes the result into b, updating the value of b to 25, so the final value of b is 25, not the expected 35; similarly, if thread 2 starts to execute the operation before thread 1 executes a=a+10 and writes the result into a, the final value of a may also not be the expected 115.

[0089] In order to solve the above problems, locks are usually added to the code for operations a and b (the code block affected by the lock is called a synchronized code block), such as Figure 8As shown, before operating on a, thread 1 first tries to obtain the lock (assuming it is called lock 1), and only starts to operate on a after it succeeds (synchronized code block 1). Before operating on b, it also tries to obtain the lock (assuming it is called lock 2), and only starts to operate on b after it succeeds (synchronized code block 2). Among them, since the operation on b is followed by the printing of the value of a (log (record) (a)), synchronized code block 1 contains synchronized code block 2. If the lock is already occupied by other threads when thread 1 tries to obtain it, thread 1 will enter a blocked state until other threads release the lock and wake up other blocked threads, then thread 1 will return to normal state. retries to acquire the lock in the synchronized state; when the synchronized code block is executed, the thread automatically releases the lock corresponding to the code block and wakes up other threads blocked on the lock; similarly, thread 2 also tries to acquire the lock before operating b and a. Since thread 2 operates b first, it will try to acquire lock 2, and only after success will it start operating b (synchronized code block 3). Before operating a, it also tries to acquire lock 1, and only after success will it start operating a (synchronized code block 4); similarly, since the value of b must be printed (log(b)) after operating a, synchronized code block 3 contains synchronized code block 4.

[0090] Locking can largely solve the problem of out-of-order access to shared data by multiple threads, but extreme cases can still present new problems. For example, in the case of two nested locks within a single thread, deadlock can occur. Suppose Thread 1 first acquires Lock 1 and executes synchronized block 1. Before Thread 1 attempts to acquire Lock 2, Thread 2 acquires Lock 2 and executes synchronized block 3. Thread 1 is blocked because it cannot acquire Lock 2. Thread 2 then attempts to acquire Lock 1 to execute synchronized block 4. Since Lock 1 is already held by Thread 1, Thread 2 also becomes blocked. Ultimately, both Thread 1 and Thread 2 are blocked, and their respective synchronized blocks cannot execute. Consequently, Lock 1 and Lock 2 are neither released, and ultimately, all threads blocked on Lock 1 and Lock 2 are unable to be awakened. In severe cases, this can permanently block a large number of threads, exhausting system resources and causing server crashes.

[0091] In the industry, thread blocking situations can be checked through the use of some tools, such as jConsole (a JMX-based GUI tool used to connect to a running JVM) commands and APM (Application Performance Management) tools. However, these tools can only be used to monitor whether there are threads in a blocked or waiting state, and cannot directly monitor whether there are permanent blocking or deadlock problems. After all, it is normal for threads to be blocked or waiting (they need to compete for locks). Developers need to conduct multiple monitoring checks and analyses to determine whether there are threads that are permanently blocked or deadlocked from many threads. By this time, serious production failures have often occurred.

[0092] In view of this, the purpose of this embodiment is to provide a deadlock real-time monitoring method that can automatically and promptly analyze whether a target application has a deadlock and can provide which method caused the deadlock, thereby helping developers to promptly discover and solve deadlock problems and avoid production failures.

[0093] In one embodiment, establishing a mapping 1 of blocked threads and locks, and a mapping 2 of occupied locks and threads of a target thread set specifically includes:

[0094] Obtain an event request manager of the target application, and create a monitoring blocking event request and a monitoring occupation event request in the event request manager;

[0095] If a thread in the target application is blocked while trying to acquire a lock, the blocking event monitoring request records the blocked thread and the lock as a set of corresponding relationships and adds them to mapping 1;

[0096] If a thread successfully acquires a lock when the target application is running, the monitoring occupation event request records the successfully acquired thread and the lock as a set of corresponding relationships and adds them to mapping 2, and deletes all mappings of at least one of the successfully acquired thread and the lock contained in mapping 1 before the current occupation moment.

[0097] In this embodiment, the logic for enabling deadlock monitoring for the target application includes:

[0098] (1) Get the VirtualMachine vm object connected to the target application's JVM environment. The key code is: VirtualMachine vm = new VirtualMachine(). Through the vm object, subsequent operations can be performed at the code level. The VirtualMachine class here is the VirtualMachine class under the com.sun.jdi package, which can be used to perform related operations on the target application's JVM environment.

[0099] (2) Obtain the event request manager EventRequestManager eventRequestManager object of the target application JVM environment through the vm object. The class of the eventRequestManager object is EventRequestManager, which is an event manager class. Therefore, eventRequestManager is an event manager and can be used to perform the next step at the code level. The event request manager here will be used to create MonitorContendedEnterEvent event requests and MonitorContendedEnteredEvent event requests. The MonitorContendedEnterEvent event is triggered when a thread is blocked because it tries to obtain a lock that is occupied by other threads. The MonitorContendedEnteredEvent event is triggered when a thread successfully obtains the lock.

[0100] (3) Create a MonitorContendedEnterEvent event request object monitorContendedEnterRequest (monitor content pending entry request, i.e. monitor blocking event request) through the eventRequestManager object; here, the monitorContendedEnterRequest object is created and the enable attribute is set to true, indicating that in the subsequent JVM environment of the target application, whenever a thread is blocked because it attempts to obtain a lock that is already occupied by another thread, the MonitorContendedEnterEvent event will be triggered, and the triggered event will be added to the JVM event queue;

[0101] (4) Similarly, a MonitorContendedEnteredEvent event request object monitorContendedEnteredRequest (monitor content has entered request, i.e. monitor occupied event request) is created through the eventRequestManager object; here, a monitorContendedEnteredRequest object is created and the enable attribute is set to true, indicating that in the future, as long as a thread in the JVM environment of the target application successfully acquires the lock, the MonitorContendedEnteredEvent event will be triggered, and the triggered event will also be added to the JVM event queue.

[0102] In one embodiment, obtaining an event request manager of a target application and creating a monitoring blocking event request and a monitoring occupation event request in the event request manager specifically include:

[0103] Pre-install a monitoring execution script on the server where the target application is located. The monitoring execution script includes an event request manager connected to the target application.

[0104] The server where the target application is located receives a first instruction to enable deadlock monitoring for the target application, runs a monitoring execution script according to the first instruction to connect to the event request manager of the target application, and creates a monitoring blocking event request and a monitoring occupying event request in the event request manager.

[0105] In this embodiment, an example of implementation steps includes:

[0106] 1. Developers Figure 9 Click the Add button on the page shown to configure the application (target application) for which deadlock monitoring needs to be enabled. Applications refer to business application systems. Because business application systems are at risk of deadlock, deadlock monitoring needs to be enabled for them. Taking the background as an example, threads 1 and 2 are both threads in the application. During execution, they operate on a and b. During these operations, lock contention may occur, resulting in lock occupation and lock blocking events, which can easily lead to deadlock.

[0107] 2. After clicking the Add button, a pop-up Figure 10 In the pop-up window, enter the application name (such as kcard-xxx) and click the OK button;

[0108] 3. After clicking the OK button, you will return to Figure 9 The newly added application (such as kcard-xxx) will be displayed on the page, and the status is "Not Enabled". At this time, the developer can click the Enable button to enable deadlock monitoring for the application;

[0109] 4. After clicking the Enable button, the application status will change to "Enabled", indicating that the application has enabled deadlock monitoring. At this time, the developer can click the View button to check whether a deadlock occurs;

[0110] 5. After clicking the View button, you will jump to Figure 11 When a deadlock occurs, the page will display the deadlock information in real time. If there are multiple deadlocks, multiple deadlock information will be displayed. The displayed information includes the deadlocked thread, the deadlocked method, and the deadlocked lock name. At this time, developers can use this information to determine which threads to process immediately and which methods to optimize or repair immediately, thereby greatly improving the efficiency of problem solving and shortening the delay in troubleshooting.

[0111] In one embodiment, the server where the target application is located receives a first instruction to enable deadlock monitoring for the target application, and runs a monitoring execution script according to the first instruction, specifically including:

[0112] The developer enters the target application name to enable deadlock monitoring through the visualization page. The front-end device where the visualization page is located generates an operation request including the target application name and sends it to the server where the target application is located.

[0113] The server where the target application is located receives the operation request, obtains the target application name, and runs the corresponding monitoring execution script according to the target application name.

[0114] In this embodiment, in an implementation step example, for step 3: after the developer clicks the start button, a request will be triggered to service A (which mainly has the following functions: as the backend service of this method, when the developer is performing page operations ( Figures 9 to 11The page will initiate an operation request to Service A, which will execute the relevant logic. The main logic is the content described in the principle of step 3. After receiving the request, Service A executes the following logic: execute the remote command to enable deadlock monitoring for the target application. For example, the command is: . / sandbox.sh -p 6 -d deadLockMonitor / excute? targetSystem=kcard-xxx, where 6 is the process of the target application, obtained by executing the command ps-ef|grep -i kcard-xxx|awk'{print$2}' (for example, the target application is kcard-xxx); sandbox.sh is the mount monitoring execution script of the jvm-sandbox installed in advance on the server where the target application is located; during the operation of the target application process, many threads will be executed, such as thread 1 and thread 2. The jvm-sandbox must be installed in advance on the server where the application is located. The installation work only needs to be done once. The jvm-sandbox is a JVM (Java Virtual Machine) based JVM (Java Virtual Machine) environment, which can monitor or operate Java processes (i.e., application processes) in the JVM. Similar tools include trace and arthas. Therefore, if you do not use JVM-Sandbox, you can also use other monitoring tools to achieve the purpose; deadLockMonitor / excute is the name of the implementation package of the operation deadlock monitoring logic provided by this embodiment. This package is saved in the module directory under the installation directory of JVM-Sandbox. It is a jar package. After being developed locally (a Spring and Maven project) and packaged into a jar package, it is saved in the module directory of JVM-Sandbox. Then, it is saved together when JVM-Sandbox is installed on the server (i.e., it is installed as part of JVM-Sandbox).

[0115] In one embodiment, after obtaining an event request manager of a target application and creating a monitoring blocking event request and a monitoring occupancy event request in the event request manager, the method further includes:

[0116] Create an event queue in the event request manager, and add each event triggered by the monitoring blocking event request and the monitoring occupying event request to the event queue in the order of triggering time;

[0117] Create at least three global static key-value pair mappings:

[0118] The first key-value pair mapping belongs to mapping 1, with a blocked thread as the key and a blocked lock as the value.

[0119] The second key-value pair mapping belongs to mapping 2, with an occupied thread as the key and an occupied lock as the value.

[0120] The third key-value pair mapping belongs to mapping 2, with an occupied lock as the key and an occupied thread as the value;

[0121] If a new event is received in the event queue, determine whether the new event comes from a monitoring blocking event request or a monitoring occupied event request. If the new event comes from a monitoring blocking event request, obtain the thread and lock corresponding to the new event as thread 1 and lock 1, and obtain mapping 1 and mapping 2 before the new event trigger time.

[0122] In this embodiment, the logic for enabling deadlock monitoring for the target application also includes:

[0123] (5) Get the event queue of the target application JVM environment: EventQueue eventQueue = vm.eventQueue(); all events that occur in the JVM (provided that the corresponding event request is created and the enable attribute is set to true, such as the previous MonitorContendedEnterEvent and MonitorContendedEnteredEvent) will enter the event queue, and these events can be obtained later through eventQueue;

[0124] (6) Create three global static HashMap (using Entry array to store key-value pairs) type variables: ThreadAndBlockedLockMap (mapping of threads and locked locks), EnteredLockAndThreadMap (mapping of entered locks and threads), and ThreadAndEnteredLockMap (mapping of threads and entered locks); among them, the purpose of ThreadAndBlockedLockMap is to save the blocked thread information (key is the blocked thread, value is the lock that caused the blocking) when a lock blocking event (MonitorContendedEnterEvent event) occurs; the purpose of EnteredLockAndThreadMap is to save the thread information of the occupied lock (key is the occupied lock, value is the thread occupying the lock) when a lock occupation event (MonitorContendedEnteredEvent event) occurs; the purpose of ThreadAndEnteredLockMap is also to save the thread information of the occupied lock when a lock occupation event occurs, but the key is the thread occupying the lock, and the value is the occupied lock;

[0125] (7) Start a new thread and execute a while loop in the thread. The following logic is executed in the loop:

[0126] (7-1) Get the latest event from the eventQueue queue;

[0127] (7-2) Determine whether the event belongs to the MonitorContendedEnteredEvent event (lock occupied event). If so, execute the logic of (7-3)-(7-4); Determine whether the event belongs to the MonitorContendedEnterEvent event (lock blocked event). If so, execute the logic of (7-5)-(7-9);

[0128] (7-3) Get the lock object and thread object that caused the event through the event object, use the lock object as the key and the thread object as the value, and save them to EnteredLockAndThreadMap; use the thread object as the key and the lock object as the value, and save them to ThreadAndEnteredLockMap;

[0129] (7-4) Determine whether the thread that caused the event has saved blocking information in ThreadAndBlockedLockMap (that is, whether there is a key-value pair with the key of the thread). If so, delete the information. Here is an explanation: if there is such blocking information, it means that the thread was previously blocked on a certain lock, and the lock must be the currently occupied lock. Now that it is occupied, the previously saved blocking information should be deleted. When a thread is competing for a lock, if the lock is already occupied by other threads, the thread will enter a blocked state and wait to be awakened. When other threads have finished using the lock (that is, when the synchronize code block is executed), they will release the lock and wake up all threads blocked on the lock. When the thread is awakened from the blocked state, it will compete for the lock again. If the thread was blocked before and can now obtain the lock, it means that the thread has been awakened from the blocked state and obtained the lock in the new competition.

[0130] (7-5) Get the lock object (assuming it is lock 2) and thread object (assuming it is thread 1) that caused the event through the event object, and save them to ThreadAndBlockedLockMap with thread 1 as the key and lock 2 as the value;

[0131] (7-6) Determine whether thread 1 has occupied other locks before blocking. The judgment method is to use thread 1 as the key and read the corresponding value from ThreadAndEnteredLockMap. If the value is read, it means that the thread has occupied other locks (assuming it is lock 1), and then execute the logic of (7-7). Deadlock can only occur if a lock is occupied and then blocked because it cannot compete for another lock.

[0132] (7-7) Get the thread object that occupies lock 2 (assuming it is thread 2). The acquisition method is to use lock 2 as the key and read the corresponding value from EnteredLockAndThreadMap; then get the state of the thread through the thread 2 object. If the state is BLOCKED (i.e. blocked), execute the logic of (7-8); because when a lock occupation event occurs, the lock object and thread object will be saved in EnteredLockAndThreadMap, so here we can get the thread 2 object that occupies lock 2 based on the lock 2 object;

[0133] (7-8) Get the lock object that causes thread 2 to be blocked. The acquisition method is to use thread 2 as the key and read the corresponding value from ThreadAndBlockedLockMap; then determine whether the lock object is lock 1. If so, it means that threads 1 and 2 are deadlocked with each other, and execute the logic of (7-9).

[0134] In one embodiment, the method further comprises:

[0135] Create a global static fourth key-value pair mapping. The fourth key-value pair mapping belongs to mapping 1, with a blocked lock as the key and a blocked thread as the value.

[0136] In this embodiment, in the above example, the deadlock of two locks is used as an example for description. If three or more locks are deadlocked, the judgment can be continued according to the above judgment logic.

[0137] In one embodiment, after determining that thread 1 to thread i+1 are deadlocked, the method further includes:

[0138] Get the thread names of threads 1 to i+1 where deadlock occurs, the lock names of locks 1 to i+1, and the code block name where at least one of the locks from locks 1 to i+1 is located;

[0139] The developer is displayed the target application name, thread names of deadlocked threads 1 to i+1, lock names of locks 1 to i+1, and the code block name where at least one of the locks from locks 1 to i+1 is located.

[0140] In this embodiment, the logic for enabling deadlock monitoring for the target application also includes:

[0141] (7-9) The class name and method name are obtained through the lock 2 object, and the thread 1 name, thread 2 name, lock 1 name, lock 2 name, and the class name and method name of lock 2 are saved in redis (Remote Dictionary Server, a remote dictionary service, a database). The key of redis is monitor: application name, such as sadd monitor:kcard-xxx{thread 1 name, thread 2 name, lock 1 name, lock 2 name, the class name and method name of lock 2}; at the Java code level, the lock belongs to a method, and the method belongs to a class. The method (method name) and class (class name) to which it belongs are obtained based on the lock 2 object. With this information, developers can quickly locate the specific class, method, and lock to be repaired in the application source code project.

[0142] In one embodiment, the method further comprises:

[0143] According to the second instruction of the developer, at least one thread among threads 1 to i+1 where deadlock occurs processes data of at least one lock of locks 1 to i+1 and then kills the at least one thread;

[0144] The target application receives the code modified by the developer for the code block where at least one lock among lock 1 to lock i+1 is located.

[0145] In this embodiment, in an example of implementation steps, for step 5: when jumping to Figure 11 After the page is displayed, the page will query service A for deadlock information of the target application every 1 second (if any, it will be saved to Redis through the sadd command (a command in Redis used to add one or more values to a set), as described above), and displayed in the page table after the query. Among them, the method that deadlocks is explained with the example in the background. Suppose thread 1 calls method A, and the method body content of method A is code block 1. When code block 1 is blocked during execution because it cannot obtain lock 2 and further evolves into a deadlock, method A is said to be a deadlocked method. For deadlocked threads, the general treatment is to kill the thread (to release resources). However, before killing, it is necessary to see whether some data processing or business processing is required to prevent affecting the normal operation of the application. These are all the processing contents of deadlocked threads; for methods that may deadlock (such as method A), they must be optimized or repaired (that is, the code must be adjusted) so that they will not deadlock again in the future.

[0146] This embodiment provides a deadlock real-time monitoring method, which uses event monitoring to design a deadlock monitoring solution, that is, an implementation package of the deadlock monitoring logic. The most critical logic for enabling the deadlock monitoring implementation for the target application is step (7). The key principle is: (7-4) and (7-5) find that thread 1 is blocked because it cannot compete for lock 2 (recorded in ThreadAndBlockedLockMap). At this time, it is necessary to check whether thread 1 has occupied other locks before blocking. If so, deadlock may occur; after (7-6) it is found that thread 1 does occupy other locks (previously recorded in ThreadAndEnteredLockMap), then it is necessary to continue to query which thread occupies lock 2 that causes thread 1 to block; after ( 7-7) It is found that the thread occupying Lock 2 is Thread 2 (previously recorded in EnteredLockAndThreadMap), so it is necessary to check whether Thread 2 is in a blocked state. If so, Thread 2 may be deadlocked with Thread 1. After (7-8) it is found that Thread 2 is blocked on Lock 1 (previously recorded in ThreadAndBlockedLockMap), that is, Thread 1 has acquired Lock 1, and Thread 2 has acquired Lock 2, but Thread 1 is blocked because it cannot compete for Lock 2, and Thread 2 is blocked because it cannot compete for Lock 1. Neither thread will release the lock, and neither thread will wake up the other, so Thread 1 and Thread 2 are deadlocked with each other. This solves the problem of how to quickly help developers discover deadlocks and locate the causes of deadlocks.

[0147] Example 2:

[0148] like Figure 2 As shown, the present application provides a deadlock monitoring device, the device comprising:

[0149] A mapping module, used to establish a mapping 1 between blocked threads and locks, and a mapping 2 between occupied locks and threads of a target thread set;

[0150] The starting module is connected to the mapping module and is used to obtain the blocked thread 1 and the lock 1 corresponding to the blocked thread 1 from the mapping 1, obtain the lock 2 corresponding to the thread 1 in the mapping 2, and the lock 1 corresponding to the thread 2 in the mapping 2;

[0151] The judgment module is connected to the starting module and is used to perform the following judgment starting from i=1:

[0152] Get the lock i+2 corresponding to thread i+1 in mapping j, and / or the lock i+1 corresponding to thread i+2 in mapping j, when i is odd, j=1, when i is even, j=2,

[0153] If lock i+2 exists and lock i+2 is lock i+1, and / or thread i+2 exists and thread i+2 is thread i+1, it is determined that thread 1 to thread i+1 is deadlocked.

[0154] If lock i+2 exists and lock i+2 is not lock i+1, and / or thread i+2 exists and thread i+2 is not thread i+1, set i=i+1 and repeat the above judgment.

[0155] In one embodiment, the mapping module specifically includes:

[0156] An event management unit, configured to obtain an event request manager of a target application and create a monitoring blocking event request and a monitoring occupying event request in the event request manager;

[0157] A blocking mapping unit is connected to the event management unit and is used to monitor the blocking event request and record the blocked thread and the locked lock as a set of corresponding relationships and add them to the mapping 1 if a thread is blocked while the target application is running.

[0158] The occupation mapping unit is connected to the event management unit and the blocking mapping unit, and is used to monitor the occupation event request and record the successful acquisition of a certain thread and a certain lock as a set of corresponding relationships and add them to Map 2, if a thread during the operation of the target application successfully acquires a certain lock, and delete all mappings of at least one of the successfully acquired thread and a certain lock contained in Map 1 before the current occupation moment.

[0159] In one embodiment, the event management unit specifically includes:

[0160] The mounting unit is used to mount the monitoring execution script on the server where the target application is located in advance, and the monitoring execution script includes an event request manager connected to the target application;

[0161] The execution unit is connected to the mounting unit and is used for the server where the target application is located to receive the first instruction to start deadlock monitoring for the target application, run the monitoring execution script according to the first instruction to connect to the event request manager of the target application, and create a monitoring blocking event request and a monitoring occupation event request in the event request manager.

[0162] In one embodiment, the execution unit specifically includes:

[0163] The front-end unit is used for developers to input the target application name to enable deadlock monitoring through a visual page. The front-end device where the visual page is located generates an operation request including the target application name and sends it to the server where the target application is located;

[0164] The back-end unit is connected to the front-end unit and is used to receive the operation request from the server where the target application is located, obtain the target application name, and run the corresponding monitoring execution script according to the target application name.

[0165] In one embodiment, the device further comprises:

[0166] An event queue unit, connected to the event management unit, is used to create an event queue in the event request manager and add each event triggered by the monitoring blocking event request and the monitoring occupying event request to the event queue in the order of triggering time;

[0167] The mapping pair unit is used to create at least three global static key-value pair mappings:

[0168] The first key-value pair mapping belongs to mapping 1, with a blocked thread as the key and a blocked lock as the value.

[0169] The second key-value pair mapping belongs to mapping 2, with an occupied thread as the key and an occupied lock as the value.

[0170] The third key-value pair mapping belongs to mapping 2, with an occupied lock as the key and an occupied thread as the value;

[0171] The new event judgment unit is connected to the mapping pair unit and the event queue unit. If a new event is received in the event queue, it is used to determine whether the new event comes from a monitoring blocking event request or a monitoring occupied event request. If the new event comes from a monitoring blocking event request, the thread and lock corresponding to the new event are obtained as thread 1 and lock 1, and mapping 1 and mapping 2 before the new event trigger time are obtained.

[0172] In one embodiment, the mapping pair unit further comprises:

[0173] Create a global static fourth key-value pair mapping. The fourth key-value pair mapping belongs to mapping 1, with a blocked lock as the key and a blocked thread as the value.

[0174] In one embodiment, the device further comprises:

[0175] A name acquisition unit, connected to the judgment module, is used to obtain the thread names of threads 1 to thread i+1 where deadlock occurs, the lock names of locks 1 to lock i+1, and the code block name where at least one lock from lock 1 to lock i+1 is located;

[0176] The front-end unit is connected to the name acquisition unit and is used to display the target application name, the thread names of threads 1 to thread i+1 where deadlock occurs, the lock names of locks 1 to lock i+1, and the code block name where at least one lock from locks 1 to lock i+1 is located to the developer.

[0177] In one embodiment, the device further comprises:

[0178] a deadlock processing unit connected to the front-end unit, configured to process data of at least one lock of lock 1 to lock i+1 for at least one thread among threads 1 to threads i+1 where deadlock occurs according to a second instruction of the developer, and then kill the at least one thread;

[0179] The code modification unit is connected to the front-end unit and is used for the target application to receive the code modified by the developer for the code block where at least one lock among lock 1 to lock i+1 is located.

[0180] Example 3:

[0181] Embodiment 3 of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the deadlock monitoring method as described in embodiment 1 or the deadlock monitoring device as described in embodiment 2 is implemented.

[0182] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program elements or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable read only memory), flash memory or other memory technology, CD-ROM (Compact Disc Read-Only Memory), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0183] In addition, the present application may also provide a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes the deadlock monitoring method as described in Example 1. The computer device may be the deadlock monitoring device as described in Example 2.

[0184] The memory is connected to the processor, the memory may be a flash memory, a read-only memory or other memory, and the processor may be a central processing unit or a single-chip microcomputer.

[0185] Embodiments 1-3 of the present application provide a deadlock monitoring method, device and medium. By establishing a mapping between blocked threads and locks and a mapping between occupied locks and threads, the blocked threads and corresponding locks are obtained to determine whether they are occupied and / or blocked, and whether mutual blocking is formed between occupied and blocked threads and / or locks. Based on this logic, it is determined whether a deadlock has occurred between the blocked threads, and the deadlock can be automatically and timely analyzed, thereby helping developers solve deadlock problems and avoid production failures.

[0186] It is understood that the above embodiments are merely exemplary embodiments for illustrating the principles of the present application, and the present application is not limited thereto. Those skilled in the art may make various modifications and improvements without departing from the spirit and substance of the present application, and such modifications and improvements are also considered to be within the scope of protection of the present application.

Claims

1. A deadlock monitoring method, characterized in that: The method comprises: Establish a mapping 1 between blocked threads and locks of the target thread set, and a mapping 2 between occupied locks and threads; Get the blocked thread 1 from map 1, and the lock 1 corresponding to the blocked thread 1, get the lock 2 corresponding to thread 1 in map 2, and the lock 1 corresponding to thread 2 in map 2; Starting from i=1, the following judgment is performed: Get the lock i+2 corresponding to thread i+1 in mapping j, and / or the lock i+1 corresponding to thread i+2 in mapping j, when i is odd, j=1, when i is even, j=2, If lock i+2 exists and lock i+2 is lock i+1, and / or thread i+2 exists and thread i+2 is thread i+1, it is determined that thread 1 to thread i+1 is deadlocked. If lock i+2 exists and lock i+2 is not lock i+1, and / or thread i+2 exists and thread i+2 is not thread i+1, set i=i+1 and repeat the above judgment.

2. The method according to claim 1, characterized in that Establish a mapping 1 between blocked threads and locks of the target thread set, and a mapping 2 between occupied locks and threads, specifically including: Obtain an event request manager of the target application, and create a monitoring blocking event request and a monitoring occupation event request in the event request manager; If a thread in the target application is blocked while trying to acquire a lock, the blocking event monitoring request records the blocked thread and the lock as a set of corresponding relationships and adds them to mapping 1; If a thread successfully acquires a lock when the target application is running, the monitoring occupation event request records the successfully acquired thread and the lock as a set of corresponding relationships and adds them to mapping 2, and deletes all mappings of at least one of the successfully acquired thread and the lock contained in mapping 1 before the current occupation moment.

3. The method according to claim 2, characterized in that Obtain the event request manager of the target application and create a monitoring blocking event request and a monitoring occupation event request in the event request manager, specifically including: Pre-install a monitoring execution script on the server where the target application is located. The monitoring execution script includes an event request manager connected to the target application. The server where the target application is located receives a first instruction to enable deadlock monitoring for the target application, runs a monitoring execution script according to the first instruction to connect to the event request manager of the target application, and creates a monitoring blocking event request and a monitoring occupying event request in the event request manager.

4. The method according to claim 3, characterized in that The server where the target application is located receives the first instruction to enable deadlock monitoring for the target application and runs the monitoring execution script according to the first instruction, specifically including: The developer enters the target application name to enable deadlock monitoring through the visualization page. The front-end device where the visualization page is located generates an operation request including the target application name and sends it to the server where the target application is located. The server where the target application is located receives the operation request, obtains the target application name, and runs the corresponding monitoring execution script according to the target application name.

5. The method according to claim 2, characterized in that After obtaining an event request manager of the target application and creating a monitoring blocking event request and a monitoring occupation event request in the event request manager, the method further includes: Create an event queue in the event request manager, and add each event triggered by the monitoring blocking event request and the monitoring occupying event request to the event queue in the order of triggering time; Create at least three global static key-value pair mappings: The first key-value pair mapping belongs to mapping 1, with a blocked thread as the key and a blocked lock as the value. The second key-value pair mapping belongs to mapping 2, with an occupied thread as the key and an occupied lock as the value. The third key-value pair mapping belongs to mapping 2, with an occupied lock as the key and an occupied thread as the value; If a new event is received in the event queue, determine whether the new event comes from a monitoring blocking event request or a monitoring occupied event request. If the new event comes from a monitoring blocking event request, obtain the thread and lock corresponding to the new event as thread 1 and lock 1, and obtain mapping 1 and mapping 2 before the new event trigger time.

6. The method according to claim 5, characterized in that The method further comprises: Create a global static fourth key-value pair mapping. The fourth key-value pair mapping belongs to mapping 1, with a blocked lock as the key and a blocked thread as the value.

7. The method according to claim 2, characterized in that After determining that thread 1 to thread i+1 are deadlocked, the method further includes: Get the thread names of threads 1 to i+1 where deadlock occurs, the lock names of locks 1 to i+1, and the code block name where at least one of the locks from locks 1 to i+1 is located; The developer is displayed the target application name, thread names of deadlocked threads 1 to i+1, lock names of locks 1 to i+1, and the code block name where at least one of the locks from locks 1 to i+1 is located.

8. The method according to claim 7, characterized in that The method further comprises: According to the second instruction of the developer, at least one thread among threads 1 to i+1 where deadlock occurs processes data of at least one lock of locks 1 to i+1 and then kills the at least one thread; The target application receives the code modified by the developer for the code block where at least one lock among lock 1 to lock i+1 is located.

9. A deadlock monitoring device, characterized in that: The device comprises: A mapping module, used to establish a mapping 1 between blocked threads and locks, and a mapping 2 between occupied locks and threads of a target thread set; The starting module is connected to the mapping module and is used to obtain the blocked thread 1 and the lock 1 corresponding to the blocked thread 1 from the mapping 1, obtain the lock 2 corresponding to the thread 1 in the mapping 2, and the lock 1 corresponding to the thread 2 in the mapping 2; The judgment module is connected to the starting module and is used to perform the following judgment starting from i=1: Get the lock i+2 corresponding to thread i+1 in mapping j, and / or the lock i+1 corresponding to thread i+2 in mapping j, when i is odd, j=1, when i is even, j=2, If lock i+2 exists and lock i+2 is lock i+1, and / or thread i+2 exists and thread i+2 is thread i+1, it is determined that thread 1 to thread i+1 is deadlocked. If lock i+2 exists and lock i+2 is not lock i+1, and / or thread i+2 exists and thread i+2 is not thread i+1, set i=i+1 and repeat the above judgment.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the deadlock monitoring method according to any one of claims 1 to 8 is implemented.

Images