WO2017167062A1 - 一种应用程序接口死锁监控方法和装置 - Google Patents

一种应用程序接口死锁监控方法和装置 Download PDF

Info

Publication number
WO2017167062A1
WO2017167062A1 PCT/CN2017/077448 CN2017077448W WO2017167062A1 WO 2017167062 A1 WO2017167062 A1 WO 2017167062A1 CN 2017077448 W CN2017077448 W CN 2017077448W WO 2017167062 A1 WO2017167062 A1 WO 2017167062A1
Authority
WO
WIPO (PCT)
Prior art keywords
deadlock
detection node
time
queue
deadlock detection
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2017/077448
Other languages
English (en)
French (fr)
Inventor
邢勇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Publication of WO2017167062A1 publication Critical patent/WO2017167062A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/524—Deadlock detection or avoidance

Definitions

  • the present application relates to the field of computer technology, and in particular, to an application program deadlock monitoring method and an application program deadlock monitoring device.
  • the system architecture and design are very complex, and the processing logic inevitably has errors.
  • the client requests the service by calling the system's Application Programming Interface (API), which has a low probability of not responding for a long time, and the system neither returns the user success nor returns a user error.
  • API Application Programming Interface
  • the occurrence of deadlocks can cause the program to wait indefinitely or the resources are heavily consumed, which makes the whole system have no resources available and is paralyzed, which seriously affects the system security and reliability.
  • the existing methods of deadlock detection can be mainly divided into static and dynamic categories.
  • the most basic of static methods is code checking, and all techniques that do static deadlock detection directly on the source program use static program analysis techniques.
  • the static program analysis technology is to manually or automatically analyze the source code or specification of the concurrent program, and then obtain the data dependency of each module of the program through analysis.
  • Static methods can achieve certain effects, but if there are concurrent defects such as deadlocks and livelocks, they are generated from specific program states, and the concurrent software state space is very large, time is long, and it will be artificial. Code checking is difficult and not very suitable.
  • the dynamic method is to run in a real environment or a simulated environment through a concurrent program, collect the running information through the detecting software, and then use the collected information to perform deadlock detection.
  • Dynamic analysis methods can be divided into two categories: testing and monitoring.
  • the dynamic method can only cover a limited software operation. For a defect with a low probability of occurrence such as deadlock, it cannot be effectively detected, and the applicability is not high.
  • an application interface deadlock monitoring method which includes:
  • the method before the step of inserting the deadlock detection node into the first queue, the method further includes:
  • the step of inserting the deadlock detection node into the first queue includes inserting the deadlock detection node into a first queue in the slot.
  • the step of monitoring whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold includes:
  • the current deadlock time threshold of a deadlock detection node exceeds one time round period, the current deadlock time threshold is subtracted from the result of one time round period as a new one of the deadlock detection nodes. Deadlock time threshold;
  • the method further includes:
  • the deadlock detection node is hashed according to the number of time rounds, and the deadlock detection node is allocated to the time round corresponding to the hash calculation result according to the calculation result.
  • the step of performing a hash calculation on the deadlock detection node according to the number of time rounds, and assigning the deadlock detection node to the corresponding time wheel according to the calculation result includes:
  • the deadlock detection node is assigned to the corresponding time wheel.
  • the method further includes:
  • the method further includes:
  • the restarting the global identifier allows the client to restart the call request of the application interface after determining that the corresponding invoked application interface is deadlocked;
  • the step of the notification calling the request corresponding to the client to deadlock the call of the application interface includes:
  • the method before creating a deadlock detection node for the call request, the method further includes:
  • the time length threshold configured by the client for the application interface is received.
  • each slot of the time wheel is configured with a spin lock; the spin lock is added before the first queue is operated, and is released after the first queue is operated.
  • the first queue includes a doubly linked list or a singly linked list.
  • the data structure of the deadlock detection node includes:
  • the step of creating a deadlock detection node for the call request includes:
  • a deadlock detection node is created in the application interface context data structure when the application interface is invoked.
  • the first queue is a priority queue, and the deadlock detection node is inserted.
  • the steps to enter the first queue include:
  • the priority of the deadlock detection node is a cutoff time; and the cutoff time is a sum of a detection node creation time and a deadlock time threshold;
  • the deadlock detection node is inserted into the priority queue according to the priority of the deadlock detection node.
  • the step of monitoring whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold includes:
  • the application also discloses an application interface deadlock monitoring device, which comprises:
  • a receiving module configured to receive a call request from a client to an application program interface
  • An insertion module configured to insert the deadlock detection node into the first queue; wherein, when the call to the application interface ends, the corresponding deadlock detection node in the first queue is deleted;
  • the monitoring module is configured to monitor whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold; if it is detected that the deadlock detection node exists for more than a deadlock time threshold, the confirmation module is entered;
  • the confirmation module is adapted to determine the corresponding application interface interface deadlock.
  • the method before the inserting the module, the method further includes:
  • a slot calculation module configured to calculate a slot corresponding to the deadlock detection node according to a current deadlock time threshold and a slot where the pointer is located in the time wheel, and the entire time cycle;
  • the insertion module then includes an insertion sub-module adapted to insert the deadlock detection node into the first queue in the slot.
  • the monitoring module includes:
  • a pointer movement sub-module adapted to periodically move the pointer of the time wheel to the next slot
  • the deadlock time judging submodule is adapted to the slot pointed by the pointer, and determines whether the deadlock time threshold of each deadlock detection node of the first queue in the slot exceeds one time slot period; if a deadlock detection node If the current deadlock time threshold of the point exceeds one time round period, the deadlock time threshold update sub-module is entered; if the current deadlock time threshold of a deadlock detection node does not exceed one time round period, the confirmation module is entered;
  • the deadlock time threshold update submodule is adapted to subtract the current deadlock time threshold from the result obtained by one time round period as a new deadlock time threshold of the deadlock detection node.
  • the method further includes:
  • the deadlock detection node allocation module is adapted to perform a hash calculation on the deadlock detection node according to the number of time wheels, and allocate the deadlock detection node to the time round corresponding to the hash calculation result according to the calculation result.
  • the deadlock detection node allocation module includes:
  • the hash value obtaining submodule is adapted to obtain a hash value of a memory address of the deadlock detection node
  • the remainder submodule is adapted to take the hash value into a remainder of the number of time wheels
  • the deadlock detection node allocation sub-module is adapted to allocate the deadlock detection node to the corresponding time wheel according to the correspondence between the remainder and the time wheel.
  • the method further includes:
  • the deleting the notification module is configured to delete the corresponding deadlock detection node in the first queue, and notify the client corresponding to the calling request to deadlock the call of the application interface;
  • the restart module is deleted, and the corresponding deadlock detection node in the first queue is deleted, and Restart the client's call request to the application interface.
  • the method further includes:
  • the open request receiving module is adapted to receive a client open request for restarting the global identifier; the restart global identifier allows the client to restart the client to invoke the application interface after determining that the corresponding invoked application interface is deadlocked;
  • the global identifier opening module is restarted, and is configured to open the restart global identifier according to the opening request.
  • the deleting the notification module includes:
  • An application interface information obtaining submodule adapted to obtain information of a deadlocked application interface
  • a serialization submodule configured to serialize the information of the deadlocked application interface into a string and return it to the client; after receiving the string, the client deserializes the string, Get information about the deadlocked application interface.
  • the method further includes:
  • the time length threshold receiving module is adapted to receive a time length threshold configured by the client for the application interface.
  • each slot of the time wheel is configured with a spin lock; the spin lock is added before the first queue is operated, and is released after the first queue is operated.
  • the first queue includes a doubly linked list or a singly linked list.
  • the data structure of the deadlock detection node includes:
  • the creating module includes:
  • the first queue is a priority queue
  • the inserting module includes:
  • a priority calculation submodule configured to calculate a priority of the deadlock detection node; the priority of the deadlock detection node is a cutoff time; and the cutoff time is a detection node creation time and a deadlock time threshold with;
  • the monitoring module includes:
  • the deadline detection module is adapted to detect whether the deadline of the deadlock detection node of the priority queue header arrives; if the deadline of the detection node of the priority queue header arrives, the confirmation module is entered.
  • a deadlock detection node for the call request is created, and then the deadlock detection node is inserted into the first queue, where the call request is At the end of the call to the application interface, the corresponding deadlock detection node in the first queue is deleted. Further, it is further monitored whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold. If it is detected that the deadlock detection node exists for more than a deadlock time threshold, the corresponding called application interface is determined. Deadlock.
  • the deadlock monitoring of the API is implemented by monitoring the existence time of the deadlock monitoring node, and the application interface deadlock described in the present application is compared with the deadlock detecting method in the background art.
  • the monitoring method is more applicable and more accurate.
  • FIG. 2 is a flow chart of steps of an embodiment of an application interface deadlock monitoring method according to the present application
  • 2A is a schematic diagram showing the location of an API deadlock monitoring node in the context of the present application
  • 2B is a schematic diagram showing the data structure of a deadlock detection node of the present application.
  • 2C is a schematic diagram of a time wheel of the present application.
  • 2D is a schematic diagram showing the data structure of a doubly linked list of the present application.
  • 2E is a schematic diagram of a deadlock monitoring node using a doubly linked list API in the present application
  • 2F is a schematic diagram of inserting a deadlock detection node in a doubly linked list according to the present application
  • 2G is a schematic diagram of a data structure of an internal state of the present application.
  • FIG. 3 is a flow chart of steps of an embodiment of an application interface deadlock monitoring method according to the present application.
  • FIG. 4 is a structural block diagram of an embodiment of an application interface deadlock monitoring apparatus of the present application.
  • FIG. 5 is a structural block diagram of an embodiment of an application interface deadlock monitoring apparatus of the present application.
  • FIG. 6 is a structural block diagram of an embodiment of an application interface deadlock monitoring apparatus of the present application.
  • One of the core concepts of the embodiment of the present application is that after receiving a call request from an application interface to an application program, a deadlock detection node for the call request is created, and then the deadlock detection node is inserted into the first queue, where When the call of the call request to the application interface ends, the corresponding deadlock detection node in the first queue is deleted. Further monitoring the deaths in the first queue Whether the lock detection node exists for more than the deadlock time threshold. If it is detected that the deadlock detection node exists for more than the deadlock time threshold, the corresponding called application interface deadlock is determined.
  • the deadlock monitoring of the API is implemented by monitoring the existence time of the deadlock monitoring node, and the application interface deadlock described in the present application is compared with the deadlock detecting method in the background art.
  • the monitoring method is more applicable and more accurate.
  • FIG. 1 a flow chart of steps of an application interface deadlock monitoring method embodiment of the present application is shown, which may specifically include the following steps:
  • Step 110 Receive a client request for an application interface.
  • each layer in the network layer interacts with each other and provides services.
  • the interface between the application layer and the client is called an application interface.
  • the client can request the system to provide services by calling an application interface.
  • Step 120 Create a deadlock detection node for the call request.
  • the deadlock detection node is used to save the information of the deadlock detection of each call request.
  • the API deadlock refers to a phenomenon in which a user invokes an API request service in a distributed system, and the system neither returns success nor returns a failure, causing the user request to be blocked.
  • a first process may be created, and the first process is used to create a deadlock detection node for the call request.
  • the first process may be created before this step, or before any step before this step, which is not limited in this embodiment.
  • the deadlock time threshold for determining that each API enters a deadlock state may be preset. If the waiting time exceeds the deadlock time threshold from the start of the API call, the system still does not return any message. The corresponding API deadlock can be determined. It should be noted that, in actual applications, the services corresponding to the APIs are different, so the deadlock time thresholds of different APIs are not completely the same. The deadlock time threshold of each API can be set according to the situation before each API is called. The embodiment of the present application is not limited.
  • Step 130 Insert the deadlock detection node into the first queue; wherein, when the call to the application interface ends, the corresponding deadlock detection node in the first queue is deleted.
  • a first queue is created to store a deadlock detection node.
  • the deadlock detection nodes may be inserted into the first queue according to a deadlock time threshold according to a deadlock time threshold corresponding to each API.
  • the deadlock detection node may be inserted into the first queue according to other methods, which is not limited in this embodiment of the present application.
  • the first process in step 120 may be utilized. Delete the corresponding deadlock detection node in the first queue.
  • the first queue includes a doubly linked list or a singly linked list.
  • the doubly linked list is also called a double-linked list, which is a kind of linked list.
  • Each of its data nodes has two pointers pointing to the previous node and the next node.
  • the two pointers may be referred to as a forward pointer and a backward pointer, respectively, wherein the forward pointer is a pointer to the previous node, and the backward pointer is to the next node. Pointer. Therefore, starting from any node in the doubly linked list, it is convenient to access its previous node and the next node.
  • the insertion and deletion operations of the node only involve the modification of the pointer, and the time complexity is O(1).
  • O(f(n)) is a time complexity function, which can quantitatively describe the running time of the algorithm f(n).
  • the first queue may also be a singly linked list.
  • the unidirectional linked list is characterized in that the linked direction of the linked list is unidirectional, and the access to the linked list is sequentially read. Starting from the head, so from any node in the singly linked list, only the previous node can be fixedly accessed, or the next node can be accessed fixedly.
  • the use of the doubly linked list as the first queue is effective, but the priority queue or the singly linked list may be used as the first queue.
  • Step 140 Monitor whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold; if it is detected that the existence time of any deadlock detection node exceeds the deadlock time threshold, proceed to step 150.
  • a monitoring process may be created to monitor whether the dead time of each deadlock detection node in the first queue exceeds a deadlock time threshold.
  • the monitoring process may be set before the step or before any step before the step, which is not limited in this embodiment.
  • a deadlock detection node for the call request is created, and the call is deleted correspondingly after the call request ends.
  • Step 150 determining that the corresponding invoked application interface deadlock.
  • a deadlock detection node for the call request After receiving a client call request to an application interface, a deadlock detection node for the call request is created, and then the deadlock detection node is inserted into the first queue, wherein when the call request is invoked on the application interface At the end, delete the corresponding deadlock detection node in the first queue. Further, it is further monitored whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold. If it is detected that the deadlock detection node exists for more than a deadlock time threshold, the corresponding called application interface is determined. Deadlock.
  • the deadlock monitoring of the API is implemented by monitoring the existence time of the deadlock monitoring node, and the application interface deadlock described in the present application is compared with the deadlock detecting method in the background art.
  • the monitoring method is more applicable and more accurate.
  • FIG. 2 a flow chart of steps of an application interface deadlock monitoring method embodiment of the present application is shown, which may specifically include the following steps:
  • Step 210 Receive a client request for an application interface.
  • Step 220 Create a deadlock detection node in the application interface context data structure when the application interface is invoked.
  • the deadlock detection node is created in the context data structure of the corresponding API, so that the life cycle of the deadlock detection node is the same as the corresponding API context environment data structure, and the deadlock detection node is The memory space can be allocated in the context, so that frequent calling functions are allocated separately for the deadlock detection node, and the memory space is freed.
  • the deadlock detection node is continuous with the memory space of the context environment, and can also avoid memory fragmentation.
  • different API contexts are different, but the structure of the deadlock detection nodes is the same. Therefore, creating a deadlock detection node in the API context data structure can solve the problem of managing all API calls with the same container and solving the problem of conveniently obtaining API related information.
  • the location of the API deadlock monitoring node in the context is shown in Figure 2A.
  • the API context environment data structure includes a deadlock detection node and other API related fields.
  • the other API-related fields may include any other fields related to the API that may exist in the data structure of the context, and are not limited in this embodiment.
  • the data structure of the deadlock detection node is as shown in FIG. 2B, and includes:
  • the doubly linked list node parameter refers to each pair used to connect the current deadlock detection node Parameters to the link point, such as pointers in each doubly linked list node.
  • the deadlock time threshold parameter refers to the acceptable time threshold parameter for waiting for the system response.
  • the time round hash index parameter refers to an index parameter of a time wheel to which the current deadlock detection node belongs, such as a time wheel label.
  • each deadlock detection node may be assigned to a different time wheel.
  • the specific allocation method includes a hash algorithm, a so-called hash algorithm, which is a one-way cryptosystem, that is, it is an irreversible mapping from plaintext to ciphertext, and only the encryption process has no decryption process.
  • the hash function can change the input of any length to obtain a fixed-length output.
  • the unidirectional feature of the hash function and the fixed length of the output data enable it to generate messages or data.
  • the Timing Wheel is a data structure whose main body is a circular buffer. Each list contains a structure called a slot, as shown in Figure 2C. Schematic diagram of the wheel. The working principle of the time wheel can be analogized to the clock. As shown in Figure 2C, the pointer (arrow) rotates at a fixed frequency in a certain direction. Each beat is called a tick. The slot currently pointed by the pointer is currently selected. The fixed slot. In this way, it can be seen that the time wheel has three important attribute parameters, namely, the number of slots of an entire time wheel, the time wheel period, and the duration of each slot, wherein the time wheel period is the number of slots and each slot. The product of the bit duration. For example, when the number of slots in an entire time wheel is 60 and the duration of one slot is 1 second, this is exactly the same as the second hand movement of the clock in reality.
  • the time slot pointer slot parameter refers to a specific slot parameter in the time slot of the current deadlock detection node, such as a slot label.
  • Step 230 Perform a hash calculation on the deadlock detection node according to the number of time wheels, and assign the deadlock detection node to the time round corresponding to the hash calculation result according to the calculation result.
  • each deadlock detection node needs to be allocated to the corresponding time wheel.
  • the hash calculation can be performed by counting the number of time rounds for each deadlock detection node. According to the calculation result, the deadlock detection node is assigned to the time round corresponding to the hash calculation result.
  • a hash algorithm is used to calculate a hash value of each deadlock detection node for a certain parameter, and then based on the calculated hash value according to the calculated hash value, the deadlock detection node is assigned according to a certain rule.
  • the parameters may be related parameters of the deadlock detection nodes that are available and unique to each other, such as the memory address of the deadlock detection node. Specific rules may include: direct addressing method, digital analysis method, square extraction method, folding method, random number method, and remainder remainder method.
  • step 230 includes:
  • Sub-step 231 obtaining a hash value of the hash value of the memory address of the deadlock detection node.
  • the hash value of the memory address of the deadlock detection node is obtained based on the memory address of the deadlock detection node.
  • any one of the above-mentioned hash algorithms may be used, which is not limited in this application.
  • Sub-step 232 taking the hash value to the number of time wheels as a remainder.
  • the number of time wheels is constant, it can be set according to requirements.
  • the hash value corresponds to a certain fixed time.
  • the wheel may of course be other correspondences, which is not limited in this application.
  • the hash value may be reserved for the number of time wheels, and the obtained remainder may be zero to the number of time rounds minus one integer, that is, the number of possible values of the remainder is equal to the number of time wheels. Therefore, the correspondence between the remainder and the time wheel can be preset.
  • the number of deadlock detection nodes in each time wheel is averaged as much as possible to avoid data confusion, and the remainder is in one-to-one correspondence with the time wheel.
  • the remainder is in one-to-one correspondence with the time wheel.
  • the application is not limited thereto.
  • Sub-step 233 according to the correspondence between the remainder and the time wheel, the deadlock detection node is allocated Go to the corresponding time round.
  • the deadlock detection node After determining the correspondence between the remainder and the time wheel and obtaining the remainder corresponding to the deadlock detection node, the deadlock detection node can be correspondingly allocated to the corresponding time wheel.
  • Step 240 Calculate a slot corresponding to the deadlock detection node according to a current deadlock time threshold and a slot in which the pointer is located in the time wheel, and the entire time wheel period.
  • the duration of each slot in the same time wheel is consistent.
  • a slot in the time slot can be set as the initial slot.
  • the slot in which the current time wheel pointer is located is the initial slot, and the pointer moves from the initial slot to the slot.
  • the next slot in the initial slot needs to pass a duration. If the pointer moves from the initial slot to the Nth (N is greater than 1 and less than the number of slots in the time slot) after the initial slot, then Need to go through N durations.
  • the deadlock time threshold may be reserved for the time round period, and the obtained remainder is used as a new deadlock time threshold corresponding to the deadlock time threshold, and then according to the above method. Calculate the slot of the deadlock detection node corresponding to the original deadlock time threshold.
  • the pointer of the corresponding time wheel can be moved from the initial slot to the pointed slot.
  • the deadlock detection node corresponding to the deadlock time threshold belongs to the slot to which the node belongs.
  • the deadlock detection node assigned to the time wheel A after the step 230 includes a deadlock detection node a and a deadlock detection node b.
  • the deadlock detection threshold of the deadlock detection node a is 3 seconds
  • the thinking time threshold of the deadlock detection node b is 6 seconds
  • the slot number of the pointer in the current time round is 5.
  • the slot number of the deadlock detection node a is 7; after 4 seconds, the pointer of the time wheel moves from the slot where the current time is located to the third slot after it. At this time, the slot number of the deadlock detection node b is 8.
  • each slot of the time wheel is configured with a spin lock; the spin lock is added before the first queue is operated, and is operated in the first queue. Released after completion.
  • the spin lock is added before the doubly linked list is operated, and is released after the doubly linked list is manipulated.
  • the purpose of the spin lock is to ensure the security of the chain doubly linked list operation.
  • the spin lock is added to the doubly linked list, and then released after the corresponding operation is performed. Twist lock.
  • Step 250 Insert the deadlock detection node into the first queue in the slot; the first queue is a doubly linked list or a singly linked list.
  • the first queue is a doubly linked list or a singly linked list.
  • the doubly linked list is also called a double-linked list, which is a kind of linked list.
  • Each of its data nodes has two pointers pointing to the previous node and the next node.
  • 2D is a data structure of a doubly linked list
  • FIG. 2E is a schematic diagram of a deadlock monitoring node by using a doubly linked list API.
  • the two pointers may be referred to as a forward pointer and a backward pointer, respectively, wherein the forward pointer is a pointer to the previous node, and the backward pointer is to the next node. Pointer.
  • the insertion and deletion operations of the node only involve the modification of the pointer, and the time complexity is O(1).
  • O(f(n)) is a time complexity function, which can quantitatively describe the running time of the algorithm f(n).
  • 2F is a schematic diagram of inserting a deadlock detection node in a doubly linked list. It is assumed that the doubly linked list has five nodes, wherein the dotted line portion is an address value, and the address value is a value for conveniently describing the random setting. In practical applications, other values may be set according to the situation, and the present application is implemented. The example is not limited. These address values are placed in a variable, and the construction of the linked list can be achieved by assigning values to variables. It is easy to see from Figure 2F that the blue arrows make up a single linked list, and the red arrows form a single linked list (reverse).
  • the deadlock detection node is equivalent to one of the nodes described in FIG. 2F. Therefore, the specific process of inserting the deadlock detection node into the doubly linked list in the slot is consistent with the foregoing.
  • the first queue may also be a singly linked list.
  • the singly linked list is characterized in that the linked direction of the linked list is unidirectional, and the access to the linked list is To start from the head by sequential reading, starting from any node in the singly linked list, only the previous node can be fixedly accessed, or the next node can be accessed fixedly.
  • the use of the doubly linked list as the first queue is more effective, but the unidirectional linked list can also be used as the first queue, which is not limited in this embodiment.
  • step 260 the pointer of the time wheel is periodically moved to the next slot.
  • each slot of the time wheel has a certain duration, starting from a pointer at a certain slot time, and after a fixed time, the pointer moves to the next slot of the slot.
  • a monitoring process may be created, and the pointer of the time wheel is periodically moved to the next slot according to the duration of each slot.
  • Step 270 Determine, for the slot pointed by the pointer, the death of the first queue in the slot Whether the deadlock time threshold of the lock detection node exceeds one time round period; if the current deadlock time threshold of a deadlock detection node exceeds one time round period, proceed to step 280; if a deadlock detects the current node If the deadlock time threshold does not exceed one time round period, then step 290 is entered.
  • the deadlock time threshold corresponding to the deadlock detection node included in each slot in the time slot may be greater than one time slot period. For such deadlock detection checkpoint, it may be necessary to go through After at least one time round period, it can be judged whether the existence time exceeds the deadlock time threshold, and relatively, it takes a relatively long time.
  • step 270 is performed to make a determination.
  • this step can still be performed by the monitoring process described above.
  • Step 280 subtracting the current deadlock time threshold from the result obtained by one time round period as a new deadlock time threshold of the deadlock detection node.
  • this step may be performed by the monitoring process described above.
  • step 290 it is determined that the corresponding called application interface deadlock.
  • step 290 the method further includes:
  • Step 2110 Delete the corresponding deadlock detection node in the first queue, and notify the client corresponding to the call request to deadlock the call to the application interface.
  • the client corresponding to the call request may be notified to deadlock the call of the application program interface.
  • the client corresponding to the notification call request may be implemented by using any existing technology.
  • the call deadlock of the application program interface is not limited in this embodiment of the present application.
  • step 2120 the corresponding deadlock detection node in the first queue is deleted, and the client's call request to the application interface is restarted.
  • the client may also restart the call request of the application interface, and then Step 210 and subsequent steps are performed again.
  • the abort function can be called to force the process to be terminated by the deadlock application interface, and then the system will restart the process that is forcibly terminated, and then the client will restart the call request of the deadlocked application interface. Avoiding deadlocks has a serious impact on the upper-level business.
  • the above-mentioned call request restart mode using the abort function is a more aggressive fault recovery mode.
  • the restart mode may not be enabled by default, and may be turned on by default according to requirements.
  • the embodiments of the present application are not limited.
  • the method before step 2120, the method further includes:
  • Step 2130 Receive an open request of the client to restart the global identifier.
  • the restart global identifier allows the client to restart the call request of the application interface after determining that the corresponding invoked application interface is deadlocked.
  • a restart global flag may be provided to indicate that the user process is directly restarted when an API deadlock occurs.
  • the user process includes a call to the deadlock API. Therefore, restarting the global identifier at this time can restart the client's call request for the deadlocked application interface.
  • the client before the step 2120 is performed, the client first receives an open request for restarting the global identifier.
  • Step 2140 Open the restart global identifier according to the open request.
  • step 2130 upon opening the restart global identifier according to the open request, the client restarts the call request of the deadlocked application interface.
  • the user process that invoked the deadlock API can be closed by calling the abort function.
  • a first process that monitors abnormal shutdown may be set, and the first process monitors that the user process of the corresponding client is closed, and then the first process monitors the user process of the corresponding client.
  • the abnormally closed user process is restarted. In turn, it is possible to restart the client to make a call request to the deadlocked application interface.
  • step 2110 includes:
  • Sub-step 2111 obtaining information of the deadlocked application interface.
  • the call of the client to the application program interface is deadlocked.
  • information about the application of the deadlock needs to be obtained, such as an application program interface. Name, function, and more.
  • Sub-step 2112 serializing the information of the deadlocked application interface into a string and returning it to the client; after receiving the string, the client deserializes the string to obtain a deadlock. Information about the application interface.
  • the information about the obtained deadlock application interface may be serialized into a string and then returned to the value client.
  • serialization is a process of converting state information of an object into a form that can be stored or transmitted.
  • the state information of the object includes information of the application interface of the deadlock, and the converted form is a character string.
  • the client receives the above string
  • the string is deserialized, that is, the reverse process of serialization is performed, and the string is restored to the application of the deadlock before the serialization.
  • Order interface information
  • the client may also invoke a deadlock API information feedback interface, and feed back information of the deadlock API to the client through the deadlock API information feedback interface.
  • the information fed back by the deadlock API information feedback interface is: the number of times each type of API deadlocks at the current time.
  • the deadlock API information feedback interface is defined as follows:
  • the return code type is an integer indicating the reason for the success or failure of the query.
  • the serialized string is an output parameter, which outputs the serialized string of the information of the deadlock API. If there is no API deadlock, it is empty. string. After the deadlock API information feedback interface returns, the client checks that the return code is successful, and the string is not empty, indicating that there is an API deadlock, then the string can be deserialized to obtain a data structure for querying the internal state of the system.
  • the data structure of the internal state is as shown in FIG. 2G, and includes a deadlock monitoring result map ⁇ API name, number of deadlocks>, the key of the map is the API function name, and the value is the number of deadlocks at the current time.
  • the method before step 220, the method further includes:
  • Step 2150 Receive a time length threshold configured by the client for the application interface.
  • the length of time threshold of each application interface may be different depending on the application interface and the client that invokes each application interface. Therefore, in the embodiment of the present application, before step 220, the time length threshold configured by the client for the application interface may be received.
  • the received time length threshold is a subsequent deadlock detection node.
  • a deadlock detection node for the call request is created, and then the deadlock detection node is inserted into the first queue, wherein, when the call is When the request to the application interface ends, the corresponding deadlock detection node in the first queue is deleted. Further, it is further monitored whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold. If it is detected that the deadlock detection node exists for more than a deadlock time threshold, the corresponding called application interface is determined. Deadlock.
  • the deadlock monitoring of the API is implemented by monitoring the existence time of the deadlock monitoring node, and the application interface deadlock described in the present application is compared with the deadlock detecting method in the background art.
  • the monitoring method is more applicable and more accurate.
  • the deadlock detection node is inserted into the doubly linked list or the singly linked list located in the slots of different time wheels according to certain rules.
  • the nodes in the doubly linked list can access the nodes in the front and rear directions adjacent thereto, and the nodes in the singly linked list can only access the adjacent forward nodes or are associated with them. Neighboring backward nodes, so relatively speaking, using a doubly linked list as the first queue is more efficient than a unidirectional linked list.
  • FIG. 3 a flow chart of steps of an application interface deadlock monitoring method embodiment of the present application is shown, which may specifically include the following steps:
  • Step 310 Receive a client request for an application interface.
  • Step 320 creating a deadlock detection node for the call request.
  • Step 330 Calculate a priority of the deadlock detection node; the priority of the deadlock detection node is a cutoff time; and the cutoff time is a detection node creation time and a deadlock time threshold. with.
  • the first queue used to store the deadlock detection node is a priority queue.
  • the priority queue is a collection of zero or more elements, and each element has a priority. For the elements with the same priority, they can be processed in the first-in first-out order or in any priority. For priority queues, each element can only be accessed sequentially in order of priority, and each time the priority queue is taken out is the element with the highest priority in the current priority queue.
  • the priority queue is a queue that stores elements in order of priority, so the priority of the deadlock detection node needs to be calculated.
  • the deadline is used as the priority of the deadlock detection node, and the shorter the deadline, the higher the priority.
  • the cutoff time is the sum of the detection node creation time and the deadlock time threshold. Of course, in view of the fact that the creation time difference is not obvious, the deadline may also include only the deadlock time threshold, which is not limited in this application.
  • the priority of the deadlock detection node needs to be calculated first, and then the deadlock detection node is inserted into the priority according to the priority.
  • the level queue For example, if the current deadlock monitoring node has a higher priority than all deadlock monitoring nodes in the priority queue, the current deadlock monitoring node can be placed at the head of the priority queue; if the current deadlock If the priority of the monitoring node is not higher than the priority of all the deadlock monitoring nodes in the priority queue, the deadlock detection node is inserted into the priority queue, and the priority is greater than each of the current deadlock detection nodes. The deadlock detection node with the lowest priority in the deadlock detection node.
  • Step 340 Insert the deadlock detection node into the priority queue according to the priority of the deadlock detection node.
  • the corresponding deadlock detection node For the priority queue, when the user requests to invoke an API, the corresponding deadlock detection node is inserted in the priority queue. When the API is exited, the corresponding deadlock detection node is deleted in the priority queue.
  • the time complexity O(logN), and N is the system. The number of requests being processed.
  • the deadlock detection node is inserted into the priority queue in the slot to which it belongs, according to its priority.
  • the deadlock detects the priority of the node and the deadlock detection node with the lowest priority. It should be noted that if a deadlock detection node is inserted in the priority queue, a deadlock detection node needs to be moved underground in a storage location whose priority is less than the deadlock detection node in the priority queue. s position. Therefore, in the process of inserting multiple deadlock detection nodes into the priority queue, the location of the deadlock detection node that has been stored in the priority queue may be adjusted multiple times. Therefore, relatively speaking, the method of storing the deadlock detection node by using the priority queue is less efficient than the method of storing the deadlock detection node by using the doubly linked list in the second embodiment.
  • the deadlock detection node may also be stored in accordance with a plurality of priority queues. Then, firstly, the deadlock detection node needs to be allocated to different priority queues by using the foregoing hash algorithm, and then step 330 is further performed, and then the deadlock detection node is detected according to the priority of the deadlock detection node according to this step. The point is inserted into the corresponding position in the priority queue to which it belongs.
  • the deadlock detection node is automatically deleted in the priority list.
  • Step 350 Detect whether the deadline of the deadlock detection node of the priority queue header arrives; if the deadline of the detection node of the priority queue header arrives, proceed to step 360.
  • the lock detection node's deadline reaches, it can determine the corresponding application interface deadlock, and then the deadlock detection node can be deleted from the priority queue. And if the deadline of the deadlock detection node of the priority queue header is not reached, then Wait until the deadlock detection node is deleted or the deadlock detection node's deadline reaches.
  • the deadlock detection node After determining whether the deadline of the deadlock detection node of the current priority queue head arrives, the deadlock detection node can be deleted from the priority queue, and then the next deadlock detection node becomes the priority queue. The first deadlock detection node, then continue with this step.
  • step 360 it is determined that the corresponding called application interface deadlock.
  • a deadlock detection node for the call request is created, and then the priority of the deadlock detection node is calculated, and the node is detected according to the deadlock.
  • the priority inserts a deadlock detection node into the priority queue, wherein when the call to the application interface ends, the corresponding deadlock detection node in the first queue is deleted. Further, it is further monitored whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold. If it is detected that the deadlock detection node exists for more than a deadlock time threshold, the corresponding called application interface is determined. Deadlock.
  • the deadlock monitoring of the API is implemented by monitoring the existence time of the deadlock monitoring node, and the application interface deadlock described in the present application is compared with the deadlock detecting method in the background art.
  • the monitoring method is more applicable and more accurate.
  • the priority of each deadlock detection node is obtained according to the dead time of the deadlock detection node, and then the deadlock detection nodes are inserted into the priority according to the priority from high to low.
  • the accuracy and efficiency of the deadlock detection can be further improved, but relatively speaking, the use of the doubly linked list or the singly linked list is stored in the second embodiment.
  • the deadlock detection scheme of the lock detection node is more efficient than the present embodiment.
  • FIG. 4 a structural block diagram of an embodiment of an application program deadlock monitoring apparatus of the present application is shown, which may specifically include the following modules:
  • the receiving module 410 is adapted to receive a request for a client to invoke an application program interface.
  • a create module 420 is adapted to create a deadlock detection node for the call request.
  • the inserting module 430 is adapted to insert the deadlock detection node into the first queue; wherein, when the call of the call request to the application interface ends, the corresponding deadlock detection node in the first queue is deleted.
  • the monitoring module 440 is configured to monitor whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold; if it is detected that the deadlock detection node exists for more than a deadlock time threshold, the confirmation module is entered. 450.
  • the validation module 450 is adapted to determine a corresponding application interface interface deadlock.
  • a deadlock detection node for the call request is created, and then the deadlock detection node is inserted into the first queue, wherein, when the call is When the request to the application interface ends, the corresponding deadlock detection node in the first queue is deleted. Further, it is further monitored whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold. If it is detected that the deadlock detection node exists for more than a deadlock time threshold, the corresponding called application interface is determined. Deadlock.
  • the deadlock monitoring of the API is implemented by monitoring the existence time of the deadlock monitoring node, and the application interface deadlock described in the present application is compared with the deadlock detecting method in the background art.
  • the monitoring method is more applicable and more accurate.
  • FIG. 5 a structural block diagram of an embodiment of an application program deadlock monitoring apparatus of the present application is shown, which may specifically include the following modules:
  • the receiving module 510 is adapted to receive a request for a client to invoke an application program interface.
  • a create module 520 is adapted to create a deadlock detection node for the call request. Specifically include:
  • a submodule 521 is created that is adapted to create a deadlock detection node in the application interface context data structure when the application interface is invoked.
  • the deadlock detection node allocation module 530 is adapted to perform a hash calculation on the deadlock detection node according to the number of time wheels, and allocate the deadlock detection node to the time wheel corresponding to the hash calculation result according to the calculation result. . Specifically include:
  • the hash value obtaining submodule 531 is adapted to obtain a hash value of a memory address of the deadlock detection node.
  • the remainder submodule 532 is adapted to take the hash value to the number of time wheels as a remainder.
  • the deadlock detection node allocation sub-module 533 is adapted to allocate the deadlock detection node to the corresponding time wheel according to the correspondence between the remainder and the time wheel.
  • the slot calculation module 540 is adapted to calculate a slot corresponding to the deadlock detection node according to a current deadlock time threshold and a slot in which the pointer is located in the time wheel, and the entire time wheel period.
  • the inserting module 550 is adapted to insert the deadlock detection node into the first queue; wherein, when the call of the calling request to the application interface ends, the corresponding deadlock detection node in the first queue is deleted. Specifically include:
  • the first insertion sub-module 551 is adapted to insert the deadlock detection node into the first queue in the slot.
  • the monitoring module 560 is configured to monitor whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold; if it is detected that the deadlock detection node exists for more than a deadlock time threshold, the confirmation module is entered. . Specifically include:
  • the pointer movement sub-module 561 is adapted to periodically move the pointer of the time wheel to the next slot.
  • the deadlock time judging sub-module 562 is adapted to the slot pointed by the pointer, and determines whether the deadlock time threshold of each deadlock detection node of the first queue in the slot exceeds a time slot period; if a deadlock detection If the current deadlock time threshold of the node exceeds one time round period, the deadlock time threshold update sub-module is entered; if the current deadlock time threshold of a deadlock detection node does not exceed one time round period, the confirmation module is entered. .
  • the deadlock time threshold update sub-module 563 is adapted to subtract the current deadlock time threshold from the result obtained by one time round period as a new deadlock time threshold of the deadlock detection node.
  • the validation module 570 is adapted to determine the corresponding invoked application interface deadlock.
  • the method further includes:
  • the delete notification module 580 is adapted to delete the corresponding deadlock detection node in the first queue, and notify the client corresponding to the call request to deadlock the call of the application interface.
  • the delete restart module 590 is adapted to delete the corresponding deadlock detection node in the first queue, and restart the client call request to the application interface.
  • the method before deleting the notification module 580, the method further includes:
  • the open request receiving module 590 is adapted to receive a client open request for restarting the global identifier; the restart global identifier allows the client to restart the call request of the application interface after determining that the corresponding invoked application interface is deadlocked .
  • the global identifier opening module 5110 is restarted, and is adapted to open the restart global identifier according to the opening request.
  • the deletion notification module 580 includes:
  • the application interface information obtaining submodule 581 is adapted to obtain information of the deadlocked application interface.
  • Serialization sub-module 582 adapted to serialize information of the deadlocked application interface to The string is returned to the client; after receiving the string, the client deserializes the string to obtain information of the deadlocked application interface.
  • the method before the module is created, the method further includes:
  • the time length threshold receiving module 5120 is adapted to receive a time length threshold configured by the client for the application interface.
  • a deadlock detection node for the call request is created, and then the deadlock detection node is inserted into the first queue, wherein, when the call is When the request to the application interface ends, the corresponding deadlock detection node in the first queue is deleted. Further, it is further monitored whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold. If it is detected that the deadlock detection node exists for more than a deadlock time threshold, the corresponding called application interface is determined. Deadlock.
  • the deadlock monitoring of the API is implemented by monitoring the existence time of the deadlock monitoring node, and the application interface deadlock described in the present application is compared with the deadlock detecting method in the background art.
  • the monitoring method is more applicable and more accurate.
  • the deadlock detection node is inserted into the doubly linked list or the singly linked list located in the slots of different time wheels according to certain rules.
  • the nodes in the doubly linked list can access the nodes in the front and rear directions adjacent thereto, and the nodes in the singly linked list can only access the adjacent forward nodes or are associated with them. Neighboring backward nodes, so relatively speaking, using a doubly linked list as the first queue is more efficient than a unidirectional linked list.
  • FIG. 6 a structural block diagram of an embodiment of an application interface deadlock monitoring apparatus of the present application is shown, which may specifically include the following modules:
  • the receiving module 610 is adapted to receive a request for a client to invoke an application program interface.
  • a creation module 620 is adapted to create a deadlock detection node for the call request.
  • the inserting module 630 is adapted to insert the deadlock detection node into the first queue; wherein, when the call of the call request to the application interface ends, the corresponding deadlock detection node in the first queue is deleted.
  • the first queue is a priority queue, and the module 630 is inserted, specifically including:
  • the priority calculation sub-module 631 is adapted to calculate a priority of the deadlock detection node; the priority of the deadlock detection node is a cut-off time; and the cut-off time is a detection node creation time and a deadlock time threshold. Sum.
  • the second insertion sub-module 632 is adapted to insert the deadlock detection node into the priority queue according to the priority of the deadlock detection node.
  • the monitoring module 640 is configured to monitor whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold; if it is detected that the deadlock detection node exists for more than a deadlock time threshold, the confirmation module is entered. 650. Specifically include:
  • the deadline detection module 641 is adapted to detect whether the deadline of the deadlock detection node of the priority queue header arrives; if the deadline of the detection node of the priority queue header arrives, the confirmation module 650 is entered.
  • the validation module 650 is adapted to determine a corresponding application interface interface deadlock.
  • a deadlock detection node for the call request is created, and then the priority of the deadlock detection node is calculated, and the node is detected according to the deadlock.
  • the priority inserts a deadlock detection node into the priority queue, wherein when the call to the application interface ends, the corresponding deadlock detection node in the first queue is deleted. Further, it is further monitored whether the existence time of each deadlock detection node in the first queue exceeds a deadlock time threshold. If it is detected that the deadlock detection node exists for more than a deadlock time threshold, the corresponding called application interface is determined. Deadlock.
  • the deadlock monitoring node realizes the deadlock monitoring of the API by monitoring the existence time of the deadlock monitoring node.
  • the application interface deadlock monitoring method described in the present application is applicable. Stronger and more accurate.
  • the priority of each deadlock detection node is obtained according to the dead time of the deadlock detection node, and then the deadlock detection nodes are inserted into the priority according to the priority from high to low.
  • the accuracy and efficiency of the deadlock detection can be further improved, but the deadlock detection scheme using the doubly linked list or the singly linked list to store the deadlock detection node in the second embodiment is more than the present embodiment. higher efficiency.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • embodiments of the embodiments of the present application can be provided as a method, apparatus, or computer program product. Therefore, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, embodiments of the present application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • Memory may include computer readable media Non-permanent memory, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read-only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • ROM read only memory
  • EEPROM electrically erasable programmable read only memory
  • flash memory or other memory technology
  • compact disk read only memory CD-ROM
  • DVD digital versatile disk
  • Magnetic tape cartridges magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include non-persistent computer readable media, such as modulated data signals and carrier waves.
  • Embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present application. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG.
  • These computer program instructions can be provided to a general purpose computer, a special purpose computer, an embedded processor or other programmable data processing terminal device
  • the processor is configured to generate a machine such that instructions executed by a processor of a computer or other programmable data processing terminal device are generated for implementation in a block or blocks of a flow or a flow and/or block diagram of the flowchart The device for the specified function.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the instruction device implements the functions specified in one or more blocks of the flowchart or in a flow or block of the flowchart.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种应用程序接口死锁监控方法和装置，涉及计算机技术领域。所述方法包括：接收客户端对一应用程序接口的调用请求（110）；创建针对所述调用请求的死锁检测结点（120）；将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点（130）；监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值（140）；如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁（150）。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，适用性更强，而且精确度较高。

Description

一种应用程序接口死锁监控方法和装置 技术领域
本申请涉及计算机技术领域，特别是涉及一种应用程序接口死锁监控方法和一种应用程序接口死锁监控装置。
背景技术
在分步式系统中，系统架构和设计非常复杂，处理逻辑不可避免地存在错误。例如，客户端通过调用系统的应用程序接口(Application Programming Interface，API)请求服务，会有较低的概率很长时间没有得到响应，系统既不返回用户成功，也不返回用户错误。这就是API死锁，死锁的发生会导致程序无限等待或资源严重消耗，使整个系统没有可用资源而陷于瘫痪，严重影响系统安全性和可靠性。
现有的死锁检测的方法主要可以分为静态和动态两大类。静态方法最基本的是代码检查，而所有直接在源程序上做静态死锁检测的技术，都会使用静态程序分析技术。静态程序分析技术是对并发程序的源代码或者规格说明进行人工或者自动化分析，然后通过分析获得程序各个模块的数据依赖关系。静态方法能取得一定的效果，但如果出现并发缺陷如死锁和活锁，其产生来源于特定的程序状态，而且并发软件状态空间非常庞大，时间耗费较长，而且会使得以人工为主的代码检查难以胜任，适用性不高。
动态方法则是通过并发程序在真实环境或模拟环境中运行，通过检测软件对运行信息进行收集，然后利用收集到的信息进行死锁检测。动态分析方法可以分为测试和监控两大类。动态方法只能覆盖到有限的软件运行情况，对于死锁这类出现概率低的缺陷，并不能有效的检测，同样适用性不高。
发明内容
鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种应用程序接口死锁监控方法和相应的一种应用程序接口死锁监控装置。
为了解决上述问题，本申请公开了一种应用程序接口死锁监控方法，其特征在于，包括：
接收客户端对一应用程序接口的调用请求；
创建针对所述调用请求的死锁检测结点；
将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点；
监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；
如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。
可选地，所述将所述死锁检测结点插入第一队列的步骤之前，还包括：
根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位；
则所述将所述死锁检测结点插入第一队列的步骤包括：将所述死锁检测结点插入所述槽位中的第一队列。
可选地，所述监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值的步骤，包括：
定期将时间轮的指针移动到下一个槽位；
对于指针指向的槽位，判断所述槽位中的第一队列的各死锁检测结 点的死锁时间阈值是否超过一个时间轮周期；
如果一死锁检测结点的当前的死锁时间阈值超过一个时间轮周期，则将当前的死锁时间阈值减去一个时间轮周期所得到的结果，作为所述死锁检测结点的新的死锁时间阈值；
如果一死锁检测结点的当前的死锁时间阈值不超过一个时间轮周期，则确定相应被调用的应用程序接口死锁。
可选地，在根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位的步骤之前，还包括：
对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应哈希计算结果的时间轮。
可选地，所述对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应的时间轮的步骤，包括：
获取死锁检测结点的内存地址的哈希值；
将所述哈希值对时间轮的数量取余数；
根据余数与时间轮的对应关系，将死锁检测结点分配到相应的时间轮中。
可选地，在确定相应被调用的应用程序接口死锁的步骤之后，还包括：
删除第一队列中相应的死锁检测结点，并通知调用请求所对应的客户端对所述应用程序接口的调用死锁；
或，删除第一队列中相应的死锁检测结点，并重启客户端对所述应用程序接口的调用请求。
可选地，所述删除第一队列中相应的死锁检测结点，并重启客户端对 所述应用程序接口的调用请求的步骤之前，还包括：
接收客户端对重启全局标识的打开请求；所述重启全局标识允许在确定相应被调用的应用程序接口死锁后，重启客户端对所述应用程序接口的调用请求；
根据所述打开请求，打开所述重启全局标识。
可选地，所述通知调用请求所对应的客户端对所述应用程序接口的调用死锁的步骤，包括：
获取死锁的应用程序接口的信息；
将所述死锁的应用程序接口的信息序列化为字符串返回给客户端；所述客户端接收到所述字符串后，对所述字符串进行反序列化，得到死锁的应用程序接口的信息。
可选地，在创建针对所述调用请求的死锁检测结点之前，还包括：
接收客户端针对所述应用程序接口配置的时间长度阈值。
可选地，所述时间轮的每个槽位配置有自旋锁；所述自旋锁在第一队列被操作之前添加，以及在第一队列被操作完毕之后释放。
可选地，所述第一队列包括双向链表或单向链表。
可选地，当所述第一队列为双向链表时，所述死锁检测结点的数据结构包括：
双向链表结点参数、死锁时间阈值参数、时间轮哈希索引参数、时间轮指针槽位参数。
可选地，所述创建针对所述调用请求的死锁检测结点的步骤，包括：
在调用应用程序接口时，在应用程序接口上下文环境数据结构中创建死锁检测结点。
可选地，所述第一队列为优先级队列，则所述将所述死锁检测结点插 入第一队列的步骤包括：
计算所述死锁检测结点的优先级；所述死锁检测结点的优先级为截止时间；所述截止时间为检测结点创建时间与死锁时间阈值之和；
根据所述死锁检测结点的优先级，将所述死锁检测结点插入优先级队列。
可选地，所述监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值的步骤，包括：
检测优先级队列首部的死锁检测结点的截止时间是否到达；
如果优先级队列首部的检测结点的截止时间到达，则确定相应被调用的应用程序接口死锁。
本申请还公开了一种应用程序接口死锁监控装置，其特征在于，包括：
接收模块，适于接收客户端对一应用程序接口的调用请求；
创建模块，适于创建针对所述调用请求的死锁检测结点；
插入模块，适于将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点；
监控模块，适于监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则进入确认模块；
确认模块，适于确定相应被调用的应用程序接口死锁。
可选地，在所述插入模块之前，还包括：
槽位计算模块，适于根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位；
则所述插入模块包括：插入子模块，适于将所述死锁检测结点插入所述槽位中的第一队列。
可选地，所述监控模块，包括：
指针移动子模块，适于定期将时间轮的指针移动到下一个槽位；
死锁时间判断子模块，适于指针指向的槽位，判断所述槽位中的第一队列的各死锁检测结点的死锁时间阈值是否超过一个时间轮周期；如果一死锁检测结点的当前的死锁时间阈值超过一个时间轮周期，则进入死锁时间阈值更新子模块；如果一死锁检测结点的当前的死锁时间阈值不超过一个时间轮周期，则进入确认模块；
死锁时间阈值更新子模块，适于将当前的死锁时间阈值减去一个时间轮周期所得到的结果，作为所述死锁检测结点的新的死锁时间阈值。
可选地，在所述槽位计算模块之前，还包括：
死锁检测结点分配模块，适于对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应哈希计算结果的时间轮。
可选地，所述死锁检测结点分配模块，包括：
哈希值获取子模块，适于获取死锁检测结点的内存地址的哈希值；
取余子模块，适于将所述哈希值对时间轮的数量取余数；
死锁检测结点分配子模块，适于根据余数与时间轮的对应关系，将死锁检测结点分配到相应的时间轮中。
可选地，在所述确认模块之后，还包括：
删除通知模块，适于删除第一队列中相应的死锁检测结点，并通知调用请求所对应的客户端对所述应用程序接口的调用死锁；
或，删除重启模块，适于删除第一队列中相应的死锁检测结点，并 重启客户端对所述应用程序接口的调用请求。
可选地，在所述删除重启模块之前，还包括：
打开请求接收模块，适于接收客户端对重启全局标识的打开请求；所述重启全局标识允许在确定相应被调用的应用程序接口死锁后，重启客户端对所述应用程序接口的调用请求；
重启全局标识开启模块，适于根据所述打开请求，打开所述重启全局标识。
可选地，所述删除通知模块，包括：
应用程序接口信息获取子模块，适于获取死锁的应用程序接口的信息；
序列化子模块，适于将所述死锁的应用程序接口的信息序列化为字符串返回给客户端；所述客户端接收到所述字符串后，对所述字符串进行反序列化，得到死锁的应用程序接口的信息。
可选地，在所述创建模块之前，还包括：
时间长度阈值接收模块，适于接收客户端针对所述应用程序接口配置的时间长度阈值。
可选地，所述时间轮的每个槽位配置有自旋锁；所述自旋锁在第一队列被操作之前添加，以及在第一队列被操作完毕之后释放。
可选地，所述第一队列包括双向链表或单向链表。
可选地，当所述第一队列为双向链表时，所述死锁检测结点的数据结构包括：
双向链表结点参数、死锁时间阈值参数、时间轮哈希索引参数、时间轮指针槽位参数。
可选地，所述创建模块，包括：
创建子模块，适于在调用应用程序接口时，在应用程序接口上下文环境数据结构中创建死锁检测结点。
可选地，所述第一队列为优先级队列，则所述插入模块，包括：
优先级计算子模块，适于计算所述死锁检测结点的优先级；所述死锁检测结点的优先级为截止时间；所述截止时间为检测结点创建时间与死锁时间阈值之和；
插入子模块，适于根据所述死锁检测结点的优先级，将所述死锁检测结点插入优先级队列。
可选地，所述监控模块，包括：
截止时间检测模块，适于检测优先级队列首部的死锁检测结点的截止时间是否到达；如果优先级队列首部的检测结点的截止时间到达，则进入确认模块。
本申请实施例包括以下优点：
本申请实施例，在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后将死锁检测结点插入第一队列，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
附图说明
图1是本申请的一种应用程序接口死锁监控方法实施例的步骤流程 图；
图2是本申请的一种应用程序接口死锁监控方法实施例的步骤流程图；
图2A是本申请的一种API死锁监测结点在上下文环境中的位置示意图；
图2B是本申请的一种死锁检测结点的数据结构示意图；
图2C是本申请的一个时间轮的示意图；
图2D是本申请的一种双向链表的数据结构示意图；
图2E是本申请的一种用双向链表串联API死锁监测结点的示意图；
图2F是本申请的一种在双向链表中插入死锁检测结点的示意图；
图2G是本申请的一种内部状态的数据结构示意图；
图3是本申请的一种应用程序接口死锁监控方法实施例的步骤流程图；
图4是本申请的一种应用程序接口死锁监控装置实施例的结构框图；
图5是本申请的一种应用程序接口死锁监控装置实施例的结构框图；
图6是本申请的一种应用程序接口死锁监控装置实施例的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。
本申请实施例的核心构思之一在于，在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后将死锁检测结点插入第一队列，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死 锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
实施例一
参照图1，示出了本申请的一种应用程序接口死锁监控方法实施例的步骤流程图，具体可以包括如下步骤：
步骤110，接收客户端对一应用程序接口的调用请求。
在数据封装时，网络分层中的每个层相互之间会用接口进行交互并提供服务，其中应用层与客户端之间的接口称之为应用程序接口。在实际应用中，客户端可以通过调用一应用程序接口请求系统提供服务。
步骤120，创建针对所述调用请求的死锁检测结点。
在本申请实施例中，死锁检测结点用于保存每个调用请求的死锁检测的信息。其中，API死锁是指在分布式系统中，用户调用一API请求服务，而系统既不返回成功，也不返回失败，导致用户请求被阻塞的一种现象。
在本申请实施例中，可以先创建一个第一进程，利用该第一进程创建针对调用请求的死锁检测结点。第一进程可以在本步骤之前，或者是本步骤之前的任一步骤之前创建，对此本申请实施例不加以限定。
另外，在本申请实施例中，可以预先设定判定各API进入死锁状态的死锁时间阈值，若从开始调用API开始，等待的时间超过死锁时间阈值，系统仍未返回任何消息，则可以判定对应API死锁。需要说明的是，在实际应用中，各API对应的服务不同，所以不同API的死锁时间阈值也会不完全相同。各API的死锁时间阈值可以在各API在被调用之前根据情况设 定，对此本申请实施例不加以限定。
步骤130，将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。
在本申请实施例中，会创建第一队列，用以存放死锁检测结点。其中，可以根据各API对应的死锁时间阈值，将各死锁检测节点按照死锁时间阈值从大的小的顺序插入第一队列。当然，也可以按照其他方式将死锁检测结点插入第一队列，对此本申请实施例不加以限定。
另外，在实际应用中，当调用请求对应用程序接口的调用结束时，此时不再需要对该应用程序接口进行死锁监控，在本申请实施例中，可以利用步骤120中的第一进程删除第一队列中相应的死锁检测节点。
在本申请另一优选的实施例中，所述第一队列包括双向链表或单向链表。
其中，双向链表也叫双链表，是链表的一种，它的每个数据结点中都有两个指针，分别指向前一个结点和后一个结点。在本申请实施例中，为了区分起见，可以将两个指针分别称为前向指针和后向指针，其中，前向指针是指向前一个结点的指针，后向指针是指向后一个结点的指针。所以，从双向链表中的任意一个结点开始，都可以很方便地访问它的前一个结点和后一个结点。而且在双向链表中，结点的插入、删除操作只涉及到指针的修改，时间复杂度是O(1)。其中，O(f(n))是时间复杂度函数，可以定量的描述算法f(n)的运行时间。
另外，在本申请实施例中，所述第一队列也可以为单向链表，与双向链表相比，单向链表的特点是链表的链接方向是单向的，对链表的访问要通过顺序读取从头部开始，所以，从单向链表中的任意一个结点开始，只可以固定地访问其前一个结点，或固定地访问其后一个结点。
综上分析可知，在本申请实施例中，利用双向链表作为第一队列，效果更好，但是也可以利用优先级队列或单向链表作为第一队列，对此本申请实施例不加以限定。
步骤140，监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则进入步骤150。
在本申请实施例中，可以创建一个监控进程，用以监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值。监控进程可以在本步骤之前，或者是本步骤之前的任一步骤之前设定，对此本申请实施例不加以限定。
由前述，在本申请实施例中，在接收到对一应用程序接口的调用请求后，即会创建一个针对该调用请求的死锁检测结点，在调用请求结束后会相应地删除针对该调用请求的死锁检测结点，而若到当前时刻针对该调用请求的死锁检测结点未被删除，则从其创建结束到当前时刻的时间即为该死锁检测结点的存在时间。
步骤150，确定相应被调用的应用程序接口死锁。
在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后将死锁检测结点插入第一队列，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
实施例二
参照图2，示出了本申请的一种应用程序接口死锁监控方法实施例的步骤流程图，具体可以包括如下步骤：
步骤210，接收客户端对一应用程序接口的调用请求。
步骤220，在调用应用程序接口时，在应用程序接口上下文环境数据结构中创建死锁检测结点。
在本申请实施例中，会将死锁检测结点创建于对应API的上下文环境数据结构中，从而死锁检测结点的生命周期与对应的API上下文环境数据结构相同，而且死锁检测结点的内存空间可以分配在上下文环境中，从而避免频繁调用函数为死锁检测结点单独分配、释放内存空间，另外死锁检测结点与上下文环境的内存空间相连续，还可以避免产生内存碎片。另外，不同的API上下文环境是不同的，但其中的死锁检测结点的结构是相同的。因此，在API上下文环境数据结构中创建死锁检测结点，既可以解决用同一个容器管理所有API调用的问题，又解决了方便地获取API相关信息的问题。API死锁监测结点在上下文环境中的位置如图2A所示。
因此，在本申请实施例中，API上下文环境数据结构包括死锁检测结点以及其他的API相关字段。其中，其他的API相关字段可以包括与API相关的其他的可存在与其上下文环境数据结构中的任何字段，对此本申请实施例不加以限定。
在本申请实施例中，所述死锁检测结点的数据结构如图2B所示，包括：
双向链表结点参数、死锁时间阈值参数、时间轮哈希索引参数、时间轮指针槽位参数。
其中，双向链表结点参数是指用以连接当前死锁检测结点的各个双 向链结点的参数，例如各个双向链表结点中的指针等。
死锁时间阈值参数，是指可以接受的等待系统响应的时间阈值参。
时间轮哈希索引参数是指当前死锁检测结点所属时间轮的索引参数，例如时间轮标号等。在本申请实施例中，为了降低检监控进程之间的竞争强度，可以将各死锁检测结点分配到不同的时间轮。具体的分配方法包括哈希(Hash)算法，所谓哈希算法，是一种单向密码体制，即它是一个从明文到密文的不可逆的映射，只有加密过程，没有解密过程。同时，哈希函数可以将任意长度的输入经过变化以后得到固定长度的输出，哈希函数的这种单向特征和输出数据长度固定的特征使得它可以生成消息或者数据。其中，时间轮(Timing Wheel)是一种数据结构，其主体是一个循环列表(circular buffer)，每个列表中包含一个称之为槽位(slot)的结构，如图2C所示为一个时间轮的示意图。时间轮的工作原理可以类比于时钟，如图2C中指针(箭头)按某一个方向按固定频率轮动，每一次跳动称为一个槽位(tick)，指针当前所指向的槽位为当前选定的槽位。这样可以看出时间轮有三个重要的属性参数，分别为一整个时间轮的槽位个数、时间轮周期以及每个槽位的持续时间，其中时间轮周期为槽位个数与每个槽位持续时间的乘积。例如，当一整个时间轮的槽位个数为60，一个槽位的持续时间为1秒，这就和现实中时钟的秒针走动完全类似了。
时间轮指针槽位参数是指当前死锁检测结点所在时间轮中的具体槽位参数，例如槽位标号等。
步骤230，对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应哈希计算结果的时间轮。
如前述，在本申请实施例中，需要将各死锁检测结点分配到相应地时间轮。可以通过对各死锁检测结点按照时间轮的个数进行哈希计算， 并根据计算结果将死锁检测结点分配到对应哈希计算结果的时间轮。例如，利用哈希算法计算各死锁检测结点针对某个参数的哈希值，然后基于时间轮的个数，根据计算出来的哈希值，按照一定规则将死锁检测结点分配到对应其哈希值的时间轮。其中，参数可以为可利用的且互相唯一的死锁检测结点的相关参数，例如死锁检测结点的内存地址。具体的规则可以包括：直接寻址法、数字分析法、平方取中法、折叠法、随机数法、除留余数法等。
在本申请另一优选的实施例中，步骤230包括：
子步骤231，获取死锁检测结点的内存地址的哈希值的哈希值。
在本申请实施例中，以死锁检测结点的内存地址为基础，获取死锁检测结点的内存地址的哈希值。具体的计算死锁检测结点的内存地址的哈希值的方法，可以利用可以采用的上述任何一种哈希算法，对此本申请不加以限定。
子步骤232，将所述哈希值对时间轮的数量取余数。
因为时间轮的数量是一定的，可以根据需求设定。为了实现根据哈希值将死锁检测结点分配到不同的时间轮中，所以哈希值与时间轮之间必然存在一定的对应关注，例如哈希值为某固定值对应于某一固定时间轮，当然也可以为其他的对应关系，对此本申请不加以限定。优选地，可以将哈希值对时间轮的数量取余，获得的余数可以为零到时间轮的数量减一之间的整数，也就是说余数可能的取值的数量等于时间轮的数量，从而可以预置余数与时间轮的对应关系，此时为尽量平均各时间轮中死锁检测结点的数量，避免数据混乱，余数与时间轮是一一对应的，当然也可以存在多个余数对应一个时间轮，或者一个余数对应多个时间轮的情况，对此本申请不加以限定。
子步骤233，根据余数与时间轮的对应关系，将死锁检测结点分配 到相应的时间轮中。
在确定了余数与时间轮的对应关系并且获取对应死锁检测结点的余数后，则可以相应地将死锁检测结点分配到对应的时间轮中。
步骤240，根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位。
在本申请实施例中，同一个时间轮中每个槽位的持续时间是一致的。在实际应用中，可以设定时间轮中某一个槽位为起始槽位，例如，本申请实施例可以以当前时间轮指针所在的槽位为初始槽位，则指针从初始槽位移动到初始槽位的下一个槽位需要经过一个持续时间，而若指针从初始槽位移动到初始槽位之后的第N(N大于1，且小于时间轮的槽位个数)个槽位，则需要经过N个持续时间。
另外，若死锁时间阈值大于整个时间轮周期，则可以将死锁时间阈值对时间轮周期取余，将取得的余数作为对应该死锁时间阈值的新的死锁时间阈值，然后按照上述方法，计算原始死锁时间阈值对应的死锁检测结点的槽位。
所以在本申请实施例中，可以根据各死锁监测结点对应的死锁时间阈值，计算经过各死锁时间阈值后，对应时间轮的指针从初始槽位可以移动到指向的槽位，则为该死锁时间阈值对应的死锁检测结点所属的槽位。
例如，针对某一时间轮A，其槽位个数为10，分别标号为1-10，每个槽位的持续时间为2秒。经步骤230后分配到时间轮A的死锁检测结点包括死锁检测结点a、死锁检测结点b。其中，死锁检测结点a的死锁时间阈值为3秒，死锁检测结点b的思索时间阈值为6秒，当前时间轮中指针所在的槽位的标号为5。
则可以判断出，经过3秒后，时间轮的指针从当前槽位移动到其之后 的第二个槽位，因此，死锁检测结点a所在的槽位标号为7；经过4秒后，时间轮的指针从当前时间所在的槽位移动到其之后的第三个槽位，此时死锁检测结点b所在的槽位标号为8。
在本申请另一优选的实施例中，所述时间轮的每个槽位配置有自旋(Spin)锁；所述自旋锁在第一队列被操作之前添加，以及在第一队列被操作完毕之后释放。当第一队列为双向链表时，自旋锁在双向链表被操作之前添加，以及在双向链表被操作完毕之后释放。自旋锁的目的是为了保证对链双向链表操作的安全性，在对双向链表进行插入、删除和遍历等操作时，自在该双向链表中添加自旋锁，在执行完对应操作后再释放自旋锁。
步骤250，将所述死锁检测结点插入所述槽位中的第一队列；所述第一队列为双向链表或单向链表。
在本申请实施例中，第一队列为双向链表或单向链表。其中，双向链表也叫双链表，是链表的一种，它的每个数据结点中都有两个指针，分别指向前一个结点和后一个结点。如图2D所示为双向链表的数据结构，图2E为用双向链表串联API死锁监测结点的示意图。在本申请实施例中，为了区分起见，可以将两个指针分别称为前向指针和后向指针，其中，前向指针是指向前一个结点的指针，后向指针是指向后一个结点的指针。所以，从双向链表中的任意一个结点开始，都可以很方便地访问它的前一个结点和后一个结点。而且在双向链表中，结点的插入、删除操作只涉及到指针的修改，时间复杂度是O(1)。其中，O(f(n))是时间复杂度函数，可以定量的描述算法f(n)的运行时间。
图2F为在双向链表中插入死锁检测结点的示意图。其中，假设双向链表有五个结点，其中虚线部分为地址值，地址值是为了描述方便随机设定的值，在实际应用中，可以根据情况设定其他值，对此本申请实施 例不加以限定。这些地址值都会被放到某个变量当中，只要对变量进行赋值传递就能实现链表的构建。从图2F中很容易看出蓝色的箭头组成了一个单链表，红色的箭头又组成了一个单链表(逆向的)。设p指向双向链表中某结点，s指向待插入的新结点，将*s插入到*p的前面，插入时需要更改两个指针变量。如图2F所示，将q结点中原本指向p的后向指针指向s结点，同时将s结点的后向指针指向p结点的，在反向上，将p结点中原本指向q结点的前向指针指向s结点的，将s结点的前向指针指向q结点，从而实现了将s结点插入到双向链表的p结点之前。
在本申请实施例中，死锁检测结点相当于图2F中所述的结点的一种。因此，将死锁检测结点插入所述槽位中的双向链表的具体过程与前述一致。
另外，在本申请另一个优选的实施例中，所述第一队列也可以为单向链表，与双向链表相比，单向链表的特点是链表的链接方向是单向的，对链表的访问要通过顺序读取从头部开始，所以，从单向链表中的任意一个结点开始，只可以固定地访问其前一个结点，或固定地访问其后一个结点。相较于单向链表，利用双向链表作为第一队列，效果更好，但是也可以利用单向链表作为第一队列，对此本申请实施例不加以限定。
步骤260，定期将时间轮的指针移动到下一个槽位。
如前述，在实际应用中，时间轮的每个槽位具有一定的持续时间，从指针开始在某一槽位时刻开始，经过一个固定时间，指针则会移动到该槽位的后一个槽位。在本申请实施例中，可以创建一个监控进程，按照每个槽位的持续时间为单位，定期地将时间轮的指针移动到下一个槽位。
步骤270，对于指针指向的槽位，判断所述槽位中的第一队列的各死 锁检测结点的死锁时间阈值是否超过一个时间轮周期；如果一死锁检测结点的当前的死锁时间阈值超过一个时间轮周期，则进入步骤280；如果一死锁检测结点的当前的死锁时间阈值不超过一个时间轮周期，则进入步骤290。
如前述，在本申请实施例中，时间轮中每个槽位中所包含的死锁检测结点对应的死锁时间阈值可能大于一个时间轮周期，对于此类死锁检测检点，可能需要经过至少一个时间轮周期后，才可以判断出其存在时间是否超过死锁时间阈值，相对而言，会耗费比较多的时间。所以在本申请实施例中，对于指针指向的槽位，会判断槽位中的第一队列的各死锁检测结点的死锁时间阈值是否超过一个时间轮周期，若一死锁检测结点的当前的死锁时间阈值超过一个时间轮周期，则当前的死锁时间阈值减去一个时间轮周期所得到的结果，作为所述死锁检测结点的新的死锁时间阈值，然后等待进入下一个时间轮周期，再执行步骤270进行判断。
在本申请实施例中，本步骤仍可以由上述的监控进程执行。
步骤280，将当前的死锁时间阈值减去一个时间轮周期所得到的结果，作为所述死锁检测结点的新的死锁时间阈值。
在本申请实施例中，本步骤可以由上述的监控进程执行。
步骤290，确定相应被调用的应用程序接口死锁。
在本申请另一优选的实施例中，在步骤290之后，还包括：
步骤2110，删除第一队列中相应的死锁检测结点，并通知调用请求所对应的客户端对所述应用程序接口的调用死锁。
对于确认为死锁的应用程序接口，不需要继续的执行上述步骤再次判断，所以会直接删除第一队列中相应的死锁监测结点，在本申请实施例中，可以创建一个执行删除操作的进程，相应地删除第一队列中对应确认为死锁的应用程序接口的死锁检测结点。另外，在本申请实施例 中，为了避免给调用该应用程序接口的客户端造成不必要的损失，例如客户端持续等待应用程序接口响应而浪费时间等。在本申请实施例中，还可以通知调用请求所对应的客户端对所述应用程序接口的调用死锁，具体地，可以利用任何一种现有技术实现通知调用请求所对应的客户端对所述应用程序接口的调用死锁，对此本申请实施例不加以限定。
或，步骤2120，删除第一队列中相应的死锁检测结点，并重启客户端对所述应用程序接口的调用请求。
在本申请实施例中，对于已经确认为死锁的应用程序接口，在删除第一队列中相应的死锁检测结点的同时，还可以重新启动客户端对该应用程序接口的调用请求，然后再次执行步骤210以及后续的步骤。
在实际应用中，可以调用abort函数强制终止对死锁应用程序接口调用的进程，然后系统会重新启动被强制终止的该进程，进而会重新启动客户端对死锁的应用程序接口的调用请求，避免死锁对上层业务造成严重影响。
需要说明的是，上述的利用abort函数的调用请求重启方式是一种比较激进的故障恢复方式，在本申请实施例中，可以默认该重启方式不开启，当然也可以根据需求默认开启，对此本申请实施例不加以限定。
在本申请另一优选的实施例中，在步骤2120之前，还包括：
步骤2130，接收客户端对重启全局标识的打开请求；所述重启全局标识允许在确定相应被调用的应用程序接口死锁后，重启客户端对所述应用程序接口的调用请求。
在本申请实施例中，可以提供一个重启全局标志，用于指示当发生API死锁时，直接重新启动该用户进程。其中，用户进程中包括了对死锁API的调用，因此，此时重启全局标识可以重启客户端对发生死锁的应用程序接口的调用请求。
此时在本申请实施例中，在执行步骤2120之前，首先会接收客户端对重启全局标识的打开请求。
步骤2140，根据所述打开请求，打开所述重启全局标识。
如步骤2130所述，在根据所述打开请求，打开重启全局标识，则会重启客户端对发生死锁的应用程序接口的调用请求。
具体地，可以通过调用abort函数，对调用了死锁API的用户进程进行关闭。而在系统中，当一用户进程被异常关闭时，在其他进程的作用下，也即可以设置一个监控异常关闭的第一进程，该第一进程监控到对应客户端的用户进程关闭后，将该异常关闭的用户进程重新启动。进而可以实现重启客户端对发生死锁的应用程序接口的调用请求。
在本申请另一优选的实施例中，步骤2110，包括：
子步骤2111，获取死锁的应用程序接口的信息。
在本申请实施例中，对于步骤2110中所述的通知调用请求所对应的客户端对所述应用程序接口的调用死锁，首先，需要获取死锁的应用程序的信息，例如应用程序接口的名称，功能等等。
子步骤2112，将所述死锁的应用程序接口的信息序列化为字符串返回给客户端；所述客户端接收到所述字符串后，对所述字符串进行反序列化，得到死锁的应用程序接口的信息。
在本申请实施例中，对于获取到的死锁的应用程序接口的信息，可以将其序列化为字符串后再返回值客户端。其中，序列化(Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程。在本申请实施例中，对象的状态信息包括死锁的应用程序接口的信息，转换的形式为字符串。
相应的，在客户端接收到上述字符串后，会对字符串进行反序列化，即执行序列化的逆过程，将字符串恢复为未序列化之前的死锁的应用程 序接口信息。
在本申请实施例中，客户端还可以调用死锁API信息反馈接口，通过死锁API信息反馈接口将死锁的API的信息反馈给客户端。该死锁API信息反馈接口反馈的信息是：每种类型的API在当前时刻死锁的次数。该死锁API信息反馈接口按如下形式定义：
返回码类型函数名(序列化字符串)
其中，返回码类型是一个整数，标示本次查询成功或失败的原因；序列化字符串是输出参数，其将死锁API的信息的序列化字符串输出，如果没有API死锁，则为空串。死锁API信息反馈接口返回后，客户端检查到返回码成功，并且字符串不为空时，说明存在API死锁，则可以先将字符串反序列化，得到一个查询系统内部状态的数据结构，该内部状态的数据结构如图2G，包含一个死锁监测结果map<API名，死锁次数>,该map的key是API函数名，value是当前时刻死锁次数。另外，考虑到死锁API信息反馈接口的可扩展性，如果有新增的功能时，可以在图2G的数据结构中，增加字段“用户传入参数”或“传出结果”用于扩展功能，而对它序列化成字符串可以做到不改变函数接口，保证兼容性。
在本申请另一优选的实施例中，在步骤220之前，还包括：
步骤2150，接收客户端针对所述应用程序接口配置的时间长度阈值。
在实际应用中，根据各个应用程序接口不同，以及调用各应用程序接口的客户端不同等原因，各应用程序接口的时间长度阈值可能会有所不同。所以在本申请实施例中，在步骤220之前，可以接收客户端针对应用程序接口配置的时间长度阈值。
在本申请实施例中，接收到的时间长度阈值即为后续的死锁检测结 点所包括的死锁时间阈值。
在本申请实施例中，在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后将死锁检测结点插入第一队列，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
另外，在本申请中，基于死锁时间阈值，时间轮周期以及槽位个数等参数，将死锁检测结点按照一定规则插入到位于不同时间轮的槽位中的双向链表或单向链表中，鉴于双向链表和单向链表插入和删除的便捷特性，同时可以预置多个时间轮同时运行，从而可以进一步地提高死锁监控的效率以及有效性。进一步地，双向链表中的结点可以访问与之相邻的前后两个方向上的结点，而单向链表中的结点只可以访问与之相邻的前向结点或者是与之相邻的后向结点，因此相对而言，利用双向链表作为第一队列比单向链表的效率会更高。
实施例三
参照图3，示出了本申请的一种应用程序接口死锁监控方法实施例的步骤流程图，具体可以包括如下步骤：
步骤310，接收客户端对一应用程序接口的调用请求。
步骤320，创建针对所述调用请求的死锁检测结点。
步骤330，计算所述死锁检测结点的优先级；所述死锁检测结点的优先级为截止时间；所述截止时间为检测结点创建时间与死锁时间阈值之 和。
在本申请实施例中，用以存储死锁检测结点的第一队列为优先级队列。其中，优先级队列(priority queue)是0个或多个元素的集合，每个元素都有一个优先级，对于优先级相同的元素，可按先进先出次序处理或按任意优先级进行。对于优先级队列而言，只可以按照优先级顺序依次访问其中的各个元素，每次从优先级队列中取出的是当前优先级队列中具有最高优先级的元素。优先级队列是将元素按照优先级顺序进行存储的队列，所以需要计算死锁检测结点的优先级。在本申请中，以截止时间作为死锁检测结点的优先级，截止时间越短，优先级越高。其中，截止时间为检测结点创建时间与死锁时间阈值之和。当然，考虑到创建时间区别不明显，截止时间也可以只包括死锁时间阈值，对此本申请不加以限定。
所以在本发明实施例中，若要将死锁检测结点插入到优先级队列中，首先需要计算死锁检测结点的优先级，然后根据优先级，将该死锁检测结点插入到优先级队列中。例如，若当前死锁监测结点的优先级高于优先级队列中全部的死锁监测结点的优先级，则可以将当前死锁监测结点置于优先级队列的首部；若当前死锁监测结点的优先级未高于优先级队列中全部的死锁监测结点的优先级，则将该死锁检测结点插入到优先级队列中，优先级大于当前死锁检测结点的各死锁检测结点中优先级最小的死锁检测结点之后。
步骤340，根据所述死锁检测结点的优先级，将所述死锁检测结点插入优先级队列。
对于优先级队列，用户请求调用一API时，会在优先级队列中插入对应的死锁检测结点，退出API时，在优先级队列中删除对应的死锁检测结点。对优先级队列的插入、删除操作，时间复杂度是O(logN)，N是系统 正在处理的请求数目。
因为优先级队列是按照优先级进行排序存储的，在获取了死锁检测结点的优先级后，根据其优先级，将死锁检测结点插入到其所属槽位中的优先级队列中高于该死锁检测结点的优先级且优先级最小的死锁检测结点之后。需要注意的是，若在优先级队列中插入一个死锁检测结点，此时在优先级小于该死锁检测结点在优先级队列中的存储位置都需要相应地下移一个死锁检测结点的位置。因此，在将多个死锁检测结点插入优先级队列的过程中，已存入优先级队列中的死锁检测结点的位置可能会被多次调整。所以相对而言，利用优先级队列存放死锁检测结点的方法相对于实施例二中利用双向链表存放死锁检测结点的方法的效率会低一些。
另外，在本申请的另一优选的实施例中，也可以按照利用多个优先级队列存储死锁检测结点。那么，首先需要利用前述的哈希算法，将死锁检测结点分配到不同的优先级队列，然后进一步执行步骤330，然后按照本步骤根据死锁检测结点的优先级，将死锁检测结点插入其所属优先级队列中的对应位置。
需要说明的是，若死锁检测结点对应的应用程序接口在截止时间内响应，则在优先级列表中会自动删除该死锁检测结点。
步骤350，检测优先级队列首部的死锁检测结点的截止时间是否到达；如果优先级队列首部的检测结点的截止时间到达，则进入步骤360。
如前述，优先级队列中的优先级越高的死锁检测结点的截止时间越短，所以，检测优先级队列首部的死锁检测结点的截止时间是否到达，如果优先级队列首部的死锁检测结点的截止时间到达，则可以确定相应被调用的应用程序接口死锁，然后可以将该死锁检测结点从优先级队列中删除。而若优先级队列首部的死锁检测结点的截止时间未到达，则继 续等待直到该死锁检测结点被删除或该死锁检测结点的截止时间到达。
在判断完当前优先级队列首部的死锁检测结点的截止时间是否到达后，该死锁检测结点可以从优先级队列中删除，然后其后一位死锁检测结点则成为优先级队列首部的死锁检测结点，然后继续执行本步骤。
步骤360，确定相应被调用的应用程序接口死锁。
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。
在本申请实施例中，在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后计算死锁检测结点的优先级，并根据死锁检测结点的优先级将死锁检测结点插入优先级队列中，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
另外，在本申请实施例中，按照死锁检测结点的截止时间，获取各死锁检测结点的优先级，然后将各死锁检测结点按照优先级从高到低的顺序插入优先级队列中，同样可以进一步提高死锁检测的精确性以及效率，但是相对而言，实施例二所述的利用双向链表或者单向链表存放死 锁检测结点的死锁检测方案比本实施例的效率更高。
实施例四
参照图4，示出了本申请的一种应用程序接口死锁监控装置实施例的结构框图，具体可以包括如下模块：
接收模块410，适于接收客户端对一应用程序接口的调用请求。
创建模块420，适于创建针对所述调用请求的死锁检测结点。
插入模块430，适于将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。
监控模块440，适于监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则进入确认模块450。
确认模块450，适于确定相应被调用的应用程序接口死锁。
在本申请实施例中，在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后将死锁检测结点插入第一队列，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
实施例五
参照图5，示出了本申请的一种应用程序接口死锁监控装置实施例的结构框图，具体可以包括如下模块：
接收模块510，适于接收客户端对一应用程序接口的调用请求。
创建模块520，适于创建针对所述调用请求的死锁检测结点。具体包括：
创建子模块521，适于在调用应用程序接口时，在应用程序接口上下文环境数据结构中创建死锁检测结点。
死锁检测结点分配模块530，适于对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应哈希计算结果的时间轮。具体包括：
哈希值获取子模块531，适于获取死锁检测结点的内存地址的哈希值。
取余子模块532，适于将所述哈希值对时间轮的数量取余数。
死锁检测结点分配子模块533，适于根据余数与时间轮的对应关系，将死锁检测结点分配到相应的时间轮中。
槽位计算模块540，适于根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位。
插入模块550，适于将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。具体包括：
第一插入子模块551，适于将所述死锁检测结点插入所述槽位中的第一队列。
监控模块560，适于监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则进入确认模块。具体包括：
指针移动子模块561，适于定期将时间轮的指针移动到下一个槽位。
死锁时间判断子模块562，适于指针指向的槽位，判断所述槽位中的第一队列的各死锁检测结点的死锁时间阈值是否超过一个时间轮周期；如果一死锁检测结点的当前的死锁时间阈值超过一个时间轮周期，则进入死锁时间阈值更新子模块；如果一死锁检测结点的当前的死锁时间阈值不超过一个时间轮周期，则进入确认模块。
死锁时间阈值更新子模块563，适于将当前的死锁时间阈值减去一个时间轮周期所得到的结果，作为所述死锁检测结点的新的死锁时间阈值。
确认模块570，适于确定相应被调用的应用程序接口死锁。
在本申请另一优选的实施例中，在确认模块570之后，还包括：
删除通知模块580，适于删除第一队列中相应的死锁检测结点，并通知调用请求所对应的客户端对所述应用程序接口的调用死锁。
或，删除重启模块590，适于删除第一队列中相应的死锁检测结点，并重启客户端对所述应用程序接口的调用请求。
在本申请另一优选的实施例中，在删除通知模块580之前，还包括：
打开请求接收模块590，适于接收客户端对重启全局标识的打开请求；所述重启全局标识允许在确定相应被调用的应用程序接口死锁后，重启客户端对所述应用程序接口的调用请求。
重启全局标识开启模块5110，适于根据所述打开请求，打开所述重启全局标识。
在本申请另一优选的实施例中，所述删除通知模块580，包括：
应用程序接口信息获取子模块581，适于获取死锁的应用程序接口的信息。
序列化子模块582，适于将所述死锁的应用程序接口的信息序列化为 字符串返回给客户端；所述客户端接收到所述字符串后，对所述字符串进行反序列化，得到死锁的应用程序接口的信息。
在本申请另一优选的实施例中，在创建模块之前，还包括：
时间长度阈值接收模块5120，适于接收客户端针对所述应用程序接口配置的时间长度阈值。
在本申请实施例中，在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后将死锁检测结点插入第一队列，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
另外，在本申请中，基于死锁时间阈值，时间轮周期以及槽位个数等参数，将死锁检测结点按照一定规则插入到位于不同时间轮的槽位中的双向链表或单向链表中，鉴于双向链表和单向链表插入和删除的便捷特性，同时可以预置多个时间轮同时运行，从而可以进一步地提高死锁监控的效率以及有效性。进一步地，双向链表中的结点可以访问与之相邻的前后两个方向上的结点，而单向链表中的结点只可以访问与之相邻的前向结点或者是与之相邻的后向结点，因此相对而言，利用双向链表作为第一队列比单向链表的效率会更高。
实施例六
参照图6，示出了本申请的一种应用程序接口死锁监控装置实施例的结构框图，具体可以包括如下模块：
接收模块610，适于接收客户端对一应用程序接口的调用请求。
创建模块620，适于创建针对所述调用请求的死锁检测结点。
插入模块630，适于将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。在本申请实施例中，所述第一队列为优先级队列，则插入模块630，具体包括：
优先级计算子模块631，适于计算所述死锁检测结点的优先级；所述死锁检测结点的优先级为截止时间；所述截止时间为检测结点创建时间与死锁时间阈值之和。
第二插入子模块632，适于根据所述死锁检测结点的优先级，将所述死锁检测结点插入优先级队列。
监控模块640，适于监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则进入确认模块650。具体包括：
截止时间检测模块641，适于检测优先级队列首部的死锁检测结点的截止时间是否到达；如果优先级队列首部的检测结点的截止时间到达，则进入确认模块650。
确认模块650，适于确定相应被调用的应用程序接口死锁。
在本申请实施例中，在接收客户端对一应用程序接口的调用请求后会创建针对调用请求的死锁检测结点，然后计算死锁检测结点的优先级，并根据死锁检测结点的优先级将死锁检测结点插入优先级队列中，其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点。进一步监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值，如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。从而可以基于 死锁监控结点，通过监控利用死锁监控结点的存在时间，实现对API的死锁监控，相对于背景技术中的死锁检测方法，本申请所述的应用程序接口死锁监控方法适用性更强，而且精确度较高。
另外，在本申请实施例中，按照死锁检测结点的截止时间，获取各死锁检测结点的优先级，然后将各死锁检测结点按照优先级从高到低的顺序插入优先级队列中，同样可以进一步提高死锁检测的精确性以及效率，但是相对而言，实施例二所述的利用双向链表或者单向链表存放死锁检测结点的死锁检测方案比本实施例的效率更高。
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介 质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处 理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺 序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种应用程序接口死锁监控方法和一种应用程序接口死锁监控装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (30)

  1. 一种应用程序接口死锁监控方法，其特征在于，包括：
    接收客户端对一应用程序接口的调用请求；
    创建针对所述调用请求的死锁检测结点；
    将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点；
    监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；
    如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则确定相应被调用的应用程序接口死锁。
  2. 根据权利要求1所述的方法，其特征在于，所述将所述死锁检测结点插入第一队列的步骤之前，还包括：
    根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位；
    则所述将所述死锁检测结点插入第一队列的步骤包括：将所述死锁检测结点插入所述槽位中的第一队列。
  3. 根据权利要求2所述的方法，其特征在于，所述监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值的步骤，包括：
    定期将时间轮的指针移动到下一个槽位；
    对于指针指向的槽位，判断所述槽位中的第一队列的各死锁检测结点的死锁时间阈值是否超过一个时间轮周期；
    如果一死锁检测结点的当前的死锁时间阈值超过一个时间轮周期，则将当前的死锁时间阈值减去一个时间轮周期所得到的结果，作为所述死锁检测结点的新的死锁时间阈值；
    如果一死锁检测结点的当前的死锁时间阈值不超过一个时间轮周期，则确定相应被调用的应用程序接口死锁。
  4. 根据权利要求2或3所述的方法，其特征在于，在根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位的步骤之前，还包括：
    对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应哈希计算结果的时间轮。
  5. 根据权利要求4所述的方法，其特征在于，所述对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应的时间轮的步骤，包括：
    获取死锁检测结点的内存地址的哈希值；
    将所述哈希值对时间轮的数量取余数；
    根据余数与时间轮的对应关系，将死锁检测结点分配到相应的时间轮中。
  6. 根据权利要求1所述的方法，其特征在于，在确定相应被调用的应用程序接口死锁的步骤之后，还包括：
    删除第一队列中相应的死锁检测结点，并通知调用请求所对应的客户端对所述应用程序接口的调用死锁；
    或，删除第一队列中相应的死锁检测结点，并重启客户端对所述应用程序接口的调用请求。
  7. 根据权利要求6所述的方法，其特征在于，所述删除第一队列中相应的死锁检测结点，并重启客户端对所述应用程序接口的调用请求的步骤之前，还包括：
    接收客户端对重启全局标识的打开请求；所述重启全局标识允许在确定相应被调用的应用程序接口死锁后，重启客户端对所述应用程序接口的调用请求；
    根据所述打开请求，打开所述重启全局标识。
  8. 根据权利要求6所述的方法，其特征在于，所述通知调用请求所对应的客户端对所述应用程序接口的调用死锁的步骤，包括：
    获取死锁的应用程序接口的信息；
    将所述死锁的应用程序接口的信息序列化为字符串返回给客户端；所述客户端接收到所述字符串后，对所述字符串进行反序列化，得到死锁的应用程序接口的信息。
  9. 根据权利要求1所述的方法，其特征在于，在创建针对所述调用请求的死锁检测结点之前，还包括：
    接收客户端针对所述应用程序接口配置的时间长度阈值。
  10. 根据权利要求2所述的方法，其特征在于，所述时间轮的每个槽 位配置有自旋锁；所述自旋锁在第一队列被操作之前添加，以及在第一队列被操作完毕之后释放。
  11. 根据权利要求1-10其中之一所述的方法，其特征在于，
    所述第一队列包括双向链表或单向链表。
  12. 根据权利要求11所述的方法，其特征在于，
    当所述第一队列为双向链表时，所述死锁检测结点的数据结构包括：
    双向链表结点参数、死锁时间阈值参数、时间轮哈希索引参数、时间轮指针槽位参数。
  13. 根据权利要求12所述的方法，其特征在于，所述创建针对所述调用请求的死锁检测结点的步骤，包括：
    在调用应用程序接口时，在应用程序接口上下文环境数据结构中创建死锁检测结点。
  14. 根据权利要求1所述的方法，其特征在于，
    所述第一队列为优先级队列，则所述将所述死锁检测结点插入第一队列的步骤包括：
    计算所述死锁检测结点的优先级；所述死锁检测结点的优先级为截止时间；所述截止时间为检测结点创建时间与死锁时间阈值之和；
    根据所述死锁检测结点的优先级，将所述死锁检测结点插入优先级队列。
  15. 根据权利要求14所述的方法，其特征在于，所述监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值的步骤，包括：
    检测优先级队列首部的死锁检测结点的截止时间是否到达；
    如果优先级队列首部的检测结点的截止时间到达，则确定相应被调用的应用程序接口死锁。
  16. 一种应用程序接口死锁监控装置，其特征在于，包括：
    接收模块，适于接收客户端对一应用程序接口的调用请求；
    创建模块，适于创建针对所述调用请求的死锁检测结点；
    插入模块，适于将所述死锁检测结点插入第一队列；其中，当所述调用请求对应用程序接口的调用结束时，删除第一队列中相应的死锁检测结点；
    监控模块，适于监控第一队列中各死锁检测结点的存在时间是否超过死锁时间阈值；如果检测到任一死锁检测结点的存在时间超过死锁时间阈值，则进入确认模块；
    确认模块，适于确定相应被调用的应用程序接口死锁。
  17. 根据权利要求16所述的装置，其特征在于，在所述插入模块之前，还包括：
    槽位计算模块，适于根据当前的死锁时间阈值和时间轮中指针所在的槽位，以及整个时间轮周期，计算对应所述死锁检测结点的槽位；
    则所述插入模块包括：插入子模块，适于将所述死锁检测结点插入 所述槽位中的第一队列。
  18. 根据权利要求17所述的装置，其特征在于，所述监控模块，包括：
    指针移动子模块，适于定期将时间轮的指针移动到下一个槽位；
    死锁时间判断子模块，适于指针指向的槽位，判断所述槽位中的第一队列的各死锁检测结点的死锁时间阈值是否超过一个时间轮周期；如果一死锁检测结点的当前的死锁时间阈值超过一个时间轮周期，则进入死锁时间阈值更新子模块；如果一死锁检测结点的当前的死锁时间阈值不超过一个时间轮周期，则进入确认模块；
    死锁时间阈值更新子模块，适于将当前的死锁时间阈值减去一个时间轮周期所得到的结果，作为所述死锁检测结点的新的死锁时间阈值。
  19. 根据权利要求17或18所述的装置，其特征在于，在所述槽位计算模块之前，还包括：
    死锁检测结点分配模块，适于对死锁检测结点按照时间轮的个数进行哈希计算，并根据计算结果将所述死锁检测结点分配到对应哈希计算结果的时间轮。
  20. 根据权利要求19所述的装置，其特征在于，所述死锁检测结点分配模块，包括：
    哈希值获取子模块，适于获取死锁检测结点的内存地址的哈希值；
    取余子模块，适于将所述哈希值对时间轮的数量取余数；
    死锁检测结点分配子模块，适于根据余数与时间轮的对应关系，将 死锁检测结点分配到相应的时间轮中。
  21. 根据权利要求16所述的装置，其特征在于，在所述确认模块之后，还包括：
    删除通知模块，适于删除第一队列中相应的死锁检测结点，并通知调用请求所对应的客户端对所述应用程序接口的调用死锁；
    或，删除重启模块，适于删除第一队列中相应的死锁检测结点，并重启客户端对所述应用程序接口的调用请求。
  22. 根据权利要求21所述的装置，其特征在于，在所述删除重启模块之前，还包括：
    打开请求接收模块，适于接收客户端对重启全局标识的打开请求；所述重启全局标识允许在确定相应被调用的应用程序接口死锁后，重启客户端对所述应用程序接口的调用请求；
    重启全局标识开启模块，适于根据所述打开请求，打开所述重启全局标识。
  23. 根据权利要求21所述的装置，其特征在于，所述删除通知模块，包括：
    应用程序接口信息获取子模块，适于获取死锁的应用程序接口的信息；
    序列化子模块，适于将所述死锁的应用程序接口的信息序列化为字符串返回给客户端；所述客户端接收到所述字符串后，对所述字符串进行反序列化，得到死锁的应用程序接口的信息。
  24. 根据权利要求16所述的装置，其特征在于，在所述创建模块之前，还包括：
    时间长度阈值接收模块，适于接收客户端针对所述应用程序接口配置的时间长度阈值。
  25. 根据权利要求17所述的装置，其特征在于，所述时间轮的每个槽位配置有自旋锁；所述自旋锁在第一队列被操作之前添加，以及在第一队列被操作完毕之后释放。
  26. 根据权利要求16-25其中之一所述的装置，其特征在于，
    所述第一队列包括双向链表或单向链表。
  27. 根据权利要求26所述的装置，其特征在于，
    当所述第一队列为双向链表时，所述死锁检测结点的数据结构包括：
    双向链表结点参数、死锁时间阈值参数、时间轮哈希索引参数、时间轮指针槽位参数。
  28. 根据权利要求27所述的装置，其特征在于，所述创建模块，包括：
    创建子模块，适于在调用应用程序接口时，在应用程序接口上下文环境数据结构中创建死锁检测结点。
  29. 根据权利要求26所述的装置，其特征在于，
    所述第一队列为优先级队列，则所述插入模块，包括：
    优先级计算子模块，适于计算所述死锁检测结点的优先级；所述死锁检测结点的优先级为截止时间；所述截止时间为检测结点创建时间与死锁时间阈值之和；
    插入子模块，适于根据所述死锁检测结点的优先级，将所述死锁检测结点插入优先级队列。
  30. 根据权利要求29所述的装置，其特征在于，所述监控模块，包括：
    截止时间检测模块，适于检测优先级队列首部的死锁检测结点的截止时间是否到达；如果优先级队列首部的检测结点的截止时间到达，则进入确认模块。
PCT/CN2017/077448 2016-03-30 2017-03-21 一种应用程序接口死锁监控方法和装置 Ceased WO2017167062A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610195050.9 2016-03-30
CN201610195050.9A CN107291558B (zh) 2016-03-30 2016-03-30 一种应用程序接口死锁监控方法和装置

Publications (1)

Publication Number Publication Date
WO2017167062A1 true WO2017167062A1 (zh) 2017-10-05

Family

ID=59963462

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/077448 Ceased WO2017167062A1 (zh) 2016-03-30 2017-03-21 一种应用程序接口死锁监控方法和装置

Country Status (3)

Country Link
CN (1) CN107291558B (zh)
TW (1) TWI738722B (zh)
WO (1) WO2017167062A1 (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111782414A (zh) * 2020-05-12 2020-10-16 北京皮尔布莱尼软件有限公司 一种延时消息处理方法及系统
CN111858075A (zh) * 2020-06-30 2020-10-30 广东浪潮大数据研究有限公司 一种死锁检测的方法、系统、设备及可读存储介质
CN112015397A (zh) * 2020-09-07 2020-12-01 深圳职业技术学院 环路检测方法及系统
CN112039701A (zh) * 2020-08-27 2020-12-04 中国平安财产保险股份有限公司 接口调用监控方法、装置、设备及存储介质
CN112905352A (zh) * 2021-01-29 2021-06-04 北京深演智能科技股份有限公司 节点死锁处理的方法和装置
CN113852700A (zh) * 2021-09-26 2021-12-28 五八同城信息技术有限公司 一种虚拟号码处理方法和装置
CN114327923A (zh) * 2022-01-20 2022-04-12 南方电网数字电网研究院有限公司 一种通用死锁检测方法及装置
CN115168005A (zh) * 2022-07-07 2022-10-11 北京明略昭辉科技有限公司 一种延时任务的处理方法、处理装置和电子设备
CN115495210A (zh) * 2022-09-06 2022-12-20 武汉船舶通信研究所（中国船舶重工集团公司第七二二研究所） 一种Linux系统下定时器的实现方法及装置
CN116107766A (zh) * 2022-12-15 2023-05-12 中国航空工业集团公司西安航空计算技术研究所 一种多核操作系统的自旋锁死锁检测方法

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111221697B (zh) * 2018-11-23 2024-02-27 阿里巴巴集团控股有限公司 调用监听方法、操作检测方法、装置及计算设备
CN110554932A (zh) * 2019-08-02 2019-12-10 恒鸿达科技有限公司 一种api模块异常检测方法
CN110569131B (zh) * 2019-08-22 2022-03-15 北京华捷艾米科技有限公司 一种信号量管理系统及信号量管理方法
CN113760508A (zh) * 2021-08-18 2021-12-07 成都安恒信息技术有限公司 一种基于时间轮的脚本下发调度方法
CN114185623B (zh) * 2021-12-20 2024-04-19 中国工商银行股份有限公司 一种应用启动过程中死锁的处理方法及装置
CN118012721B (zh) * 2024-04-09 2024-08-06 深圳市纷享互联科技有限责任公司 数据同步检测方法、系统及介质
CN120111543B (zh) * 2025-01-03 2025-12-05 广州爱浦路网络技术有限公司 基于Redis的UPF高可用方法、装置、设备及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101324A1 (en) * 2005-10-31 2007-05-03 Microsoft Corporation Instrumentation to find the thread or process responsible for an application failure
CN102222015A (zh) * 2010-04-13 2011-10-19 三星电子（中国）研发中心 检测多线程程序中的死锁的方法及系统
CN103246552A (zh) * 2012-02-14 2013-08-14 腾讯科技（深圳）有限公司 防止线程出现阻塞的方法和装置
CN104636259A (zh) * 2015-03-18 2015-05-20 厦门雅迅网络股份有限公司 一种基于运行期动态跟踪的函数执行超时与死锁检测方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200841189A (en) * 2006-12-27 2008-10-16 Ibm Technique for accurately detecting system failure
CN102053861B (zh) * 2009-10-30 2014-03-12 国际商业机器公司 并行程序中死锁检测的方法和系统
CN102222016B (zh) * 2010-04-16 2013-12-04 国际商业机器公司 程序死锁检测方法和系统
CN102073588B (zh) * 2010-12-28 2013-11-20 北京邮电大学 一种基于代码静态分析的多线程死锁检测方法及系统
US9619303B2 (en) * 2012-04-11 2017-04-11 Hewlett Packard Enterprise Development Lp Prioritized conflict handling in a system
US9042222B2 (en) * 2012-11-28 2015-05-26 Broadcom Corporation Deadlock recovery for distributed devices
CN103399818B (zh) * 2013-08-13 2016-05-18 中国科学技术大学苏州研究院 操作系统中的死锁检测方法
CN103761148B (zh) * 2014-01-26 2017-04-05 北京京东尚科信息技术有限公司 集群定时调度任务的控制方法
TWI556612B (zh) * 2014-04-29 2016-11-01 鼎捷軟件股份有限公司 適用於遠端程序呼叫的逾時控制單元與遠端程序呼叫方法
CN105426234B (zh) * 2015-10-30 2019-02-19 小米科技有限责任公司 数据库死锁检测方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070101324A1 (en) * 2005-10-31 2007-05-03 Microsoft Corporation Instrumentation to find the thread or process responsible for an application failure
CN102222015A (zh) * 2010-04-13 2011-10-19 三星电子（中国）研发中心 检测多线程程序中的死锁的方法及系统
CN103246552A (zh) * 2012-02-14 2013-08-14 腾讯科技（深圳）有限公司 防止线程出现阻塞的方法和装置
CN104636259A (zh) * 2015-03-18 2015-05-20 厦门雅迅网络股份有限公司 一种基于运行期动态跟踪的函数执行超时与死锁检测方法

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111782414A (zh) * 2020-05-12 2020-10-16 北京皮尔布莱尼软件有限公司 一种延时消息处理方法及系统
CN111782414B (zh) * 2020-05-12 2024-04-19 北京皮尔布莱尼软件有限公司 一种延时消息处理方法及系统
CN111858075A (zh) * 2020-06-30 2020-10-30 广东浪潮大数据研究有限公司 一种死锁检测的方法、系统、设备及可读存储介质
CN112039701B (zh) * 2020-08-27 2023-08-15 中国平安财产保险股份有限公司 接口调用监控方法、装置、设备及存储介质
CN112039701A (zh) * 2020-08-27 2020-12-04 中国平安财产保险股份有限公司 接口调用监控方法、装置、设备及存储介质
CN112015397A (zh) * 2020-09-07 2020-12-01 深圳职业技术学院 环路检测方法及系统
CN112015397B (zh) * 2020-09-07 2023-09-26 深圳职业技术学院 环路检测方法及系统
CN112905352A (zh) * 2021-01-29 2021-06-04 北京深演智能科技股份有限公司 节点死锁处理的方法和装置
CN113852700A (zh) * 2021-09-26 2021-12-28 五八同城信息技术有限公司 一种虚拟号码处理方法和装置
CN114327923A (zh) * 2022-01-20 2022-04-12 南方电网数字电网研究院有限公司 一种通用死锁检测方法及装置
CN115168005A (zh) * 2022-07-07 2022-10-11 北京明略昭辉科技有限公司 一种延时任务的处理方法、处理装置和电子设备
CN115495210A (zh) * 2022-09-06 2022-12-20 武汉船舶通信研究所（中国船舶重工集团公司第七二二研究所） 一种Linux系统下定时器的实现方法及装置
CN116107766A (zh) * 2022-12-15 2023-05-12 中国航空工业集团公司西安航空计算技术研究所 一种多核操作系统的自旋锁死锁检测方法

Also Published As

Publication number Publication date
TW201737085A (zh) 2017-10-16
CN107291558B (zh) 2020-11-24
CN107291558A (zh) 2017-10-24
TWI738722B (zh) 2021-09-11

Similar Documents

Publication Publication Date Title
WO2017167062A1 (zh) 一种应用程序接口死锁监控方法和装置
US11086665B2 (en) Scheduling services for quantum computing
AU2018243075B2 (en) Service processing and consensus method and device
TWI706659B (zh) 量子金鑰分發方法及裝置
WO2019024674A1 (zh) 智能合约处理方法及装置
US11675622B2 (en) Leader election with lifetime term
CN108108127A (zh) 一种文件读取方法及系统
CN109255057B (zh) 区块生成方法、装置、设备及存储介质
CN110727675A (zh) 一种链表的处理方法及装置
CN104298541A (zh) 云存储系统的数据分布算法及其装置
CN111553652B (zh) 业务处理方法及装置
US20160306841A1 (en) Collection record for overlapping data stream collections
US9766929B2 (en) Processing of data stream collection record sequence
CN108614772A (zh) 一种并发检测堆缓冲区溢出的架构及方法
CN107766127A (zh) 事务消息处理方法、装置、设备及系统
KR20080038301A (ko) 차단 로컬 센스 동기화 배리어
CN110888739B (zh) 延迟任务的分布式处理方法与装置
CN109344630B (zh) 区块生成方法、装置、设备和存储介质
CN104239218B (zh) 一种实时软件压力测试用例生成方法及装置
CN111367785A (zh) 基于sdn的故障检测方法、装置和服务器
WO2024066005A1 (zh) 重放区块链交易的方法及装置
CN112732453B (zh) 跨线程消息处理方法、装置、系统和计算机可读存储介质
CN111476663B (zh) 一种数据处理方法、装置、节点设备及存储介质
US9734461B2 (en) Resource usage calculation for process simulation
CN113835920A (zh) 内存异常监测方法、装置及计算机存储介质

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17773092

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17773092

Country of ref document: EP

Kind code of ref document: A1