Method for endless loop detection of server application thread

Abstract

The invention discloses a method for endless loop detection of server application threads, which comprises the following steps of: acquiring a CPU (Central Processing Unit) occupancy ratio of the server application threads, and screening out an application thread A of which the CPU occupancy is not less than a first preset value; obtaining all server application thread objects, and traversing a server application thread list; if the name of the server application thread is matched with the application thread A, continuing stack comparison: comparing stack similarity, and screening out an application thread B of which the stack similarity is not less than a second preset value; the application thread B is a thread suspected to be endless loop. According to the method, the stack path is converted into the method calling graph, and the stack similarity is accurately calculated by utilizing the graph editing distance, so that the limitation of the prior art is overcome. According to the method, the endless loop thread can be positioned more accurately, and the detection precision can be remarkably improved, the false alarm rate can be reduced and the system performance and stability can be improved by reserving the complete stack call context and sequence information.

Description

Technical Field

[0001] The present invention relates to the field of computers, and in particular to a method for detecting dead loops of application threads at a server end. Background Art

[0002] In modern Internet and enterprise applications, server-side applications developed in programming languages ​​such as Java often encounter high-concurrency operating environments, especially when processing a large number of user requests, data calculations, or complex system integration. Reasonable scheduling and management of threads is an important technical means to ensure the stable operation of applications, but thread dead loop problems often occur, which directly leads to excessive CPU resource consumption, and ultimately causes system performance degradation or crashes.

[0003] Existing methods for detecting thread dead loops (such as performance monitoring, static code analysis, stack similarity calculation, etc.) have certain limitations in complex concurrent environments, and it is difficult to accurately identify dead loop threads without affecting performance.

[0004] Among them, performance monitoring tools are widely used for thread dead loop detection, which mainly identify potential dead loop threads by monitoring the system's runtime performance indicators, such as CPU usage and memory consumption. When the CPU usage of a thread exceeds the set threshold for a long time, the monitoring tool will issue an alarm. However, this type of method has obvious limitations: high CPU usage does not necessarily mean that the thread is stuck in an infinite loop, but may also be caused by normal computing-intensive tasks, resulting in a high false alarm rate.

[0005] Predicting potential thread dead loops through static code analysis is performed during the code development phase or compilation phase, and attempts to predict possible dead loops by analyzing the code structure and logic. The advantage of static analysis is that it can identify certain problems before the system runs, avoiding performance problems caused by runtime dead loops. However, this method has limited coverage and it is difficult to accurately predict dead loops that may be triggered in complex runtime environments, especially in dynamic data-driven scenarios.

[0006] Existing stack similarity calculation methods are widely used for thread dead loop detection. The core idea is to identify threads stuck in dead loops by analyzing thread stack information and finding similar or repeated stack patterns. In existing methods, function call information is usually extracted from the stack recorded when the fault occurs, and a simplified stack is generated. Subsequently, the correlation between faults is judged by comparing the similarities between the simplified stacks or their substacks. Although this simplified stack-based method reduces the noise information in the stack to a certain extent, it mainly relies on the function name for comparison and fails to fully retain the call order and context information of the stack, resulting in low accuracy of similarity calculation. In a complex multi-threaded environment, the false alarm rate is high, and it is impossible to accurately distinguish similar but essentially different thread behaviors. In addition, the method handles the stack in a simple way and lacks in-depth analysis of complex stack relationships. Especially when facing large-scale concurrent or cross-module call applications, its performance is insufficient.

[0007] In general, the existing performance monitoring, static analysis and stack similarity calculation methods all have certain deficiencies in detecting thread dead loop problems. Although the performance monitoring method can detect problems quickly, its accuracy is not high and the false alarm rate is high; the static analysis method is difficult to cover all operating scenarios in a dynamic environment; the similarity calculation method based on simplified stack fails to retain the complete stack call sequence and context information, resulting in insufficient accuracy in complex scenarios. Therefore, the existing technology cannot take into account both efficiency and accuracy when detecting thread dead loop problems, and urgently needs to be improved and optimized. Summary of the invention

[0008] The purpose of the present invention is to overcome the shortcomings and deficiencies of the prior art and provide a method for detecting dead loops in server-side application threads. The method converts the stack path into a method call graph and uses the graph edit distance to accurately calculate the stack similarity, aiming to overcome the limitations of the prior art. The present invention can not only locate the dead loop thread more accurately, but also significantly improve the detection accuracy, reduce the false alarm rate, and improve the system performance and stability by retaining the complete stack call context and sequence information.

[0009] The purpose of the present invention is achieved through the following technical solutions:

[0010] A method for detecting a dead loop of a server application thread comprises the following steps:

[0011] S1. Obtain the CPU occupancy ratio of the server application thread, and select the application thread A whose CPU occupancy is not less than a first preset value;

[0012] S2. After filtering out the application thread A, obtain all server-side application thread objects and traverse the server-side application thread list;

[0013] If the server application thread name does not match application thread A, remove it;

[0014] If the server application thread name matches application thread A, continue stack comparison: within time period T, capture application thread stack information several times, compare stack similarities, and select application thread B whose stack similarity is not less than a second preset value; application thread B is the thread suspected of being in an infinite loop.

[0015] The stack similarity is calculated by a graph-based stack similarity algorithm:

[0016] Extracting method call sequences of the first stack and the second stack of application thread A, and constructing method call graphs of the first stack and the second stack;

[0017] Calculate the edit distance and node similarity of the method call graphs of the first stack and the second stack;

[0018] The stack similarity is obtained by weightedly averaging the edit distance and node similarity of the method call graphs of the first stack and the second stack.

[0019] When constructing the method call graphs of the first stack and the second stack, the extracted method call sequences of the first stack and the second stack are converted into a directed graph, each method call is a vertex, and the order relationship of the method calls is a directed edge.

[0020] The edit distance between the method call graphs of the first stack and the second stack is defined as follows:

[0021]

[0022] Among them, G S1 , G S2 is the method call graph of the first stack and the second stack, e i represents the i-th editing operation, c(e i ) represents the editing operation e i The cost is , and k is the total number of editing operations.

[0023] The node similarity sim(N1, N2) of the method call graphs of the first stack and the second stack is defined as:

[0024]

[0025] Among them, N1 and N2 are the method call graph G of the first stack respectively. S1 , the method call graph G of the second stack S2 A collection of nodes.

[0026] At the same time, the present invention provides:

[0027] A server comprises a processor and a memory, wherein the memory stores at least one program, and the program is loaded and executed by the processor to implement the above-mentioned method for detecting dead loops of application threads on the server side.

[0028] A computer-readable storage medium stores at least one program, which is loaded and executed by a processor to implement the above-mentioned method for detecting dead loops of server-side application threads.

[0029] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0030] 1. The present invention can accurately locate the thread and code position where the dead loop occurs, reducing the debugging time of developers.

[0031] 2. The present invention uses an efficient data processing algorithm to quickly process and analyze a large amount of thread information, thereby improving detection efficiency and reducing resource consumption.

[0032] 3. The present invention combines the CPU occupancy ratio and the stack comparison method, reduces the false alarms caused by single indicator judgment, and improves the accuracy of problem diagnosis.

[0033] 4. The present invention avoids problems such as application freezes and high CPU usage by timely discovering and solving thread dead loop problems, thereby significantly improving computing efficiency or end-user experience.

[0034] 5. The present invention is not only applicable to application platforms developed using the Java language, but can also be extended to other platforms and applications that require thread management and performance optimization. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 The present invention is a flowchart of a method for detecting dead loops in server-side application threads.

[0036] Figure 2 Flowchart for computing stack similarity for the graph-based stack similarity algorithm.

[0037] Figure 3 Take a screenshot of the process's stat information.

[0038] Figure 4 This is a screenshot of the stat information of the main thread.

[0039] Figure 5 This is a screenshot of the stat information of the child thread.

[0040] Figure 6 This is a screenshot of the first crawl thread.

[0041] Figure 7 This is a screenshot of the second crawl thread.

[0042] Figure 8 This is a screenshot of the third crawl thread. DETAILED DESCRIPTION

[0043] The present invention is further described in detail below in conjunction with embodiments and drawings, but the embodiments of the present invention are not limited thereto.

[0044] A method for detecting dead loops in server application threads, the complete steps are as follows:

[0045] 1. Get the thread CPU usage ratio.

[0046] Obtain the CPU time consumed by processes and threads by reading the stat file in the system proc directory. Calculate the user-mode CPU usage of threads to identify threads that may have performance issues.

[0047] (1) Stat information of the process.

[0048] By reading the stat file under the system proc directory, you can get the CPU time consumed by the process and thread, such as Figure 3 .

[0049] The process ID is: 15315. The process user state CPU time consumed 260958, and the kernel state CPU time consumed 30749. For the infinite loop, the CPU usage is mainly reflected in the user state, so only pay attention to the CPU usage in the user state.

[0050] (2) Stat information of the main thread.

[0051] like Figure 4 , the process ID is: 15315, which is the same as the process ID. The main thread user state CPU time consumption is 1, and the kernel state CPU time consumption is 0. The main thread user state CPU occupancy ratio can be considered that the CPU usage at the system level is very small or almost non-existent.

[0052] (3) Stat information of child threads.

[0053] like Figure 5 , the child thread ID is: 15625. The thread user state CPU time consumption is 17, and the kernel state CPU time consumption is 1. The child thread user state CPU accounts for 17 / 1=17%.

[0054] To calculate the CPU usage of each thread in a certain period of time, you only need to calculate the difference between the CPU usage of the process and the thread. Usually, threads with a CPU usage of more than 10% can be marked as high-time threads.

[0055] 2. Thread stack comparison.

[0056] Another feature of an infinite loop thread is that when a loop point appears, the bottom of the thread stack is always the same. For example:

[0057] like Figure 6 , first crawl.

[0058] like Figure 7 , second crawl.

[0059] like Figure 8 , the third crawl.

[0060] like Figures 6 to 8 ,For the three stacks captured by the thread within a certain time interval, it can be found that the stacks are very similar, so it can be used as the key suspect of the dead loop.

[0061] 3. CPU usage and stack comparison are integrated

[0062] CPU usage solution: Through the stat file, you can identify the threads with high CPU usage. However, the stat file only provides limited information such as the thread name, which is difficult to directly correspond to the specific code, making it impossible to accurately analyze the root cause of high CPU usage.

[0063] Stack comparison scheme: It can obtain stack information, but when the thread is blocked (such as reading IO or cross-process communication), the stack similarity is also very high, so the false alarm rate is relatively high. Therefore, only by combining the two schemes can we more accurately obtain the stack information of the thread with high CPU usage, thereby greatly improving the analyzability of the detection results.

[0064] Fusion solution: To improve the accuracy of detection results, it is key to combine CPU usage analysis with stack comparison. The core of the combination is to use thread names. Since the output of both solutions contains thread names, thread names can be used for correlation matching to accurately locate the stack information of threads with high CPU usage. This combination method can significantly improve the effectiveness and accuracy of problem analysis.

[0065] like Figure 1 , the complete version of the dead loop thread detection mechanism is described in detail as follows:

[0066] (1) Start monitoring: Start CPU usage monitoring.

[0067] (2) Get CPU time: Get the CPU time of the process and thread from the stat file.

[0068] (3) Wait and get the CPU time again: After waiting for a while, get the CPU time of the process and thread again.

[0069] (4) Calculate and determine the CPU time: Calculate the CPU time of all threads and determine whether it exceeds the threshold.

[0070] If it exceeds the threshold, mark it as a high CPU thread and save the information.

[0071] (5) Get and traverse thread objects: Get all application thread objects and traverse the thread list.

[0072] If the thread name matches a high CPU thread, continue with stack comparison.

[0073] If there is no match, remove the thread from consideration.

[0074] (6) Stack comparison: Continuously obtain the stacks of the remaining threads within a certain period of time and compare the stack similarities.

[0075] If the similarity is below a threshold, the thread is removed from consideration.

[0076] (7) Output results: Output the detection results, combined with CPU usage and thread stack information, and finally output the thread suspected of dead loop.

[0077] 4. Graph-based stack similarity algorithm.

[0078] The present invention provides an innovative algorithm for calculating the similarity of stack connection graphs - a graph-based stack similarity algorithm, which converts the stack into a method call graph and uses the graph edit distance to calculate the similarity of the graph, thereby achieving accurate comparison of stack path graphs.

[0079] Figure 2 The process of the graph-based stack similarity algorithm is described, which extracts method call sequences, constructs method call graphs, calculates graph edit distances, and finally outputs the similarity score of the stack path graph.

[0080] (1) Extract method call sequence:

[0081] Extract the method call sequence of stack 1 and stack 2.

[0082] (2) Constructing the method call graph:

[0083] According to the extracted method call sequences, the method call graphs of stack 1 and stack 2 are constructed respectively.

[0084] (3) Calculate graph edit distance:

[0085] Compute the edit distance of the method call graphs of stack 1 and stack 2.

[0086] (4) Determine whether there are identical nodes:

[0087] If there are identical nodes, calculate the edit distance and the result is x.

[0088] If there are no identical nodes, calculate the edit distance and the result is y.

[0089] (5) Calculate the similarity score:

[0090] Based on the edit distance results, calculate the similarity score.

[0091] (6) Output similarity score:

[0092] Output the final similarity score.

[0093] The graph-based stack similarity algorithm calculates the stack similarity, which specifically includes the following steps:

[0094] Step 1: Extract method call sequence;

[0095] For each stack path, extract the method call sequence. Given a stack path S, the extracted method call sequence is expressed as:

[0096] M S =m1,m2,...,m n ;

[0097] Where m i Represents the i-th method call.

[0098] Example: Stack Path 1:

[0099] com.text.sqlite.SQLiteCursor.fill(SourceFile:77);

[0100] com.text.AbstractCursor.getMoveToPosition(SourceFile:23);

[0101] com.text.AbstractCursor.moveToNext(Unknown source:4);

[0102] data.queryHistory(SourceFile:106);

[0103] kj$3.run(SourceFile:189);

[0104] java.util.concurrent.Executors$RunnableAdapter.call(Executors.ja va:428);

[0105] java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278);

[0106] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133);

[0107] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607);

[0108] java.lang.Thread.run(Thread.java:761).

[0109] Extracted method call sequence:

[0110] M S1 ={com.newtext.sqlite.SQLiteCursor.fill,com.newtext.AbstractCursor.getMoveToPosition,com.newtext.AbstractCursor.moveToNext,data.queryHistory,kj$3.run,java.util.concurrent.Executors$RunnableAdapter.call,java.util.concurrent.FutureTask.runAndReset,java.util.concurrent.ThreadPoolExecutor.runWorker,java.util.concurrent.ThreadPoolExecutor$Worker.run,java.lang.Thread.run};

[0111] Example: Stack trace 2:

[0112] com.text.sqlite.SQLiteCursor.getColumnNames(SourceFile:196);

[0113] com.text.AbstractCursor.getColumnCount(SourceFile:146);

[0114] b3k.fillWithCursor(SourceFile:59);

[0115] data.queryHistory(SourceFile:107);

[0116] kj$3.run(SourceFile:189);

[0117] java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428);

[0118] java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278);

[0119] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133);

[0120] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607);

[0121] java.lang.Thread.run(Thread.java:761).

[0122] Extracted method call sequence:

[0123] M S2={com.text.sqlite.SQLiteCursor.getColumnNames,com.text.AbstractCursor.getColumnCount,b3k.fillWithCursor,data.queryHistory,kj$3.run,java.util.concurrent.Executors$RunnableAdapt er.call,java.util.concurrent.FutureTask.runAndReset,java.util.concurrent.ThreadPoolExecutor.runWorker,java.util.concurrent.ThreadPoolExecutor$Worker.run,java.lang.Thread.run}.

[0124] Step 2: Build the method call graph

[0125] The extracted method call sequence is converted into a directed graph. Each method call is a vertex, and the order relationship of method calls is a directed edge.

[0126] Given a sequence of method calls:

[0127] M S =m1,m2,...,m n ;

[0128] The constructed directed graph is represented as:

[0129] G S =(V, E);

[0130] in:

[0131] V=v1,v2,...,v n , v i , v i Indicates method call m i .

[0132] E=(v i , v i+1 )|1≤i<n, indicating the order of method calls.

[0133] Example:

[0134] Method call sequence:

[0135] M S1 ={com.text.sqlite.SQLiteCursor.fill,...};

[0136] M S2 ={(com.text.sqlite.SQLiteCursor.getColumnNames,...)};

[0137] Constructed directed graph:

[0138] V S1 = {v com.text.sqlite .SQLiteCursor.fillWindow,...};

[0139] E S1 ={(v com.text.sqlite .SQLiteCursor.fillWindow,...;

[0140] V S2 = {v com.text.sqlite .SQLiteCursor.getColumnNames,...};

[0141] E S2 ={(v com.text.sqlite .SQLiteCursor.getColumnNames,...)};

[0142] Step 3: Calculate graph edit distance

[0143] The call graphs of two stack paths are compared to calculate the Graph Edit Distance (GED), which measures the minimum number of edit operations (addition, deletion, and replacement of vertices and edges) required to transform one graph into another.

[0144] Given two graphs G S1 =(V S1 , E S1 ) and G S2 =(V S2 , E S2 ), the graph edit distance is defined as:

[0145]

[0146] Among them, e i represents the i-th editing operation, c(e i ) represents the editing operation e i The cost is , and k is the total number of editing operations.

[0147] Assume that the cost of adding, deleting, and replacing operations is 1:

[0148] (1) Replace the vertex com.text.sqlite.SQLiteCursor.fill with the vertex com.text.sqlite.SQLiteCursor.getColumnNames.

[0149] (2) Replace com.text.AbstractCursor.getMoveToPosition with com.text.AbstractCursor.getColumnCount.

[0150] (3) Replace the vertex com.text.AbstractCursor.moveToNext with the vertex b3k.fillWithCursor.

[0151] There are 3 operations in total, GED = 3. In the example, the method call graphs of stack 1 and stack 2 both contain 10 method calls (vertices), so |V S1 |=10,|V S2 |=10, to get the normalized edit distance

[0152] Step 4: Calculate node similarity

[0153] Compute two graphs G S1 and G S2 The similarity of the nodes in G. S1 and G S2 The node similarity sim(N1,N2) can be defined as:

[0154]

[0155] Get node similarity

[0156] Step 5: Calculate the comprehensive similarity score;

[0157] Taking into account the graph edit distance and node similarity, we calculate the final similarity score S. We use a weighted average method to combine these two indicators:

[0158]

[0159] Wherein, α and β are weight coefficients, satisfying α+β=1.

[0160] The normalized value of the graph edit distance is 0.7, and the node similarity is 0.7. According to the rule of thumb, we choose α = 0.5 and β = 0.5:

[0161] S=0.5(1-0.3)+0.5*0.7=0.7;

[0162] The overall similarity score is 0.7, which means that the stack trace graphs are 70% similar. By adjusting the values ​​of α and β, the similarity calculation results can be optimized according to specific needs and application scenarios. The higher the overall similarity score, the greater the probability that the thread is an infinite loop.

[0163] The present invention obtains the CPU time consumption of processes and threads by reading the stat file in the system proc directory, and calculates the user-state CPU occupancy ratio of threads to identify threads that may have performance problems.

[0164] The present invention continuously obtains thread stack information within a certain time interval, compares the similarity of the stacks, and identifies the dead loop thread.

[0165] The present invention combines CPU occupancy analysis with stack comparison, performs correlation matching through thread names, and accurately locates stack information of threads with high CPU occupancy.

[0166] The present invention proposes an innovative algorithm for calculating stack path similarity, which realizes accurate comparison of stack paths by converting stack paths into method call graphs and calculating the similarity of graphs using graph edit distance.

[0167] A server comprises a processor and a memory, wherein the memory stores at least one program, and the program is loaded and executed by the processor to implement the above-mentioned method for detecting dead loops of application threads on the server side.

[0168] A computer-readable storage medium stores at least one program, which is loaded and executed by a processor to implement the above-mentioned method for detecting dead loops of server-side application threads.

[0169] The methods and algorithms of the present invention are not limited to one programming language. No matter whether Python, Java, C++, Go, Rust or other programming languages ​​are used, as long as the above methods and algorithms are implemented, they belong to the protection scope of the present invention.

[0170] The above embodiments are preferred implementation modes of the present invention, but the implementation modes of the present invention are not limited to the above embodiments. Any other changes, modifications, substitutions, combinations, and simplifications that do not deviate from the spirit and principles of the present invention should be equivalent replacement methods and are included in the protection scope of the present invention.

Claims

1. A method for detecting dead loops in server application threads, characterized in that: The following steps are involved: S1. Obtain the CPU occupancy ratio of the server application thread, and select the application thread A whose CPU occupancy is not less than a first preset value; S2. After filtering out the application thread A, obtain all server-side application thread objects and traverse the server-side application thread list; If the server application thread name does not match application thread A, remove it; If the server application thread name matches application thread A, continue stack comparison: within time period T, capture application thread stack information several times, compare stack similarities, and select application thread B whose stack similarity is not less than a second preset value; application thread B is the thread suspected of being in an infinite loop.

2. The method for detecting dead loops in server application threads according to claim 1, characterized in that: The stack similarity is calculated by a graph-based stack similarity algorithm: Extracting method call sequences of the first stack and the second stack of application thread A, and constructing method call graphs of the first stack and the second stack; Calculate the edit distance and node similarity of the method call graphs of the first stack and the second stack; The stack similarity is obtained by weightedly averaging the edit distance and node similarity of the method call graphs of the first stack and the second stack.

3. The method for detecting dead loop of application thread on the server side according to claim 1, characterized in that: When constructing the method call graphs of the first stack and the second stack, the extracted method call sequences of the first stack and the second stack are converted into a directed graph, each method call is a vertex, and the order relationship of the method calls is a directed edge.

4. The method for detecting dead loop of application thread on the server side according to claim 1, characterized in that: The edit distance between the method call graphs of the first stack and the second stack is defined as follows: Among them, G S1 , G S2 is the method call graph of the first stack and the second stack, e i represents the i-th editing operation, c(e i ) indicates an edit operation i The cost is , and k is the total number of editing operations.

5. The method for detecting dead loop of application thread on the server side according to claim 1, characterized in that: The node similarity sim(N1, N2) of the method call graphs of the first stack and the second stack is defined as: Among them, N1 and N2 are the method call graph G of the first stack respectively. S1 , the method call graph G of the second stack S2 A collection of nodes.

6. A server, comprising a processor and a memory, characterized in that: At least one program is stored in the memory, and the program is loaded and executed by the processor to implement the method for detecting dead loops of server application threads as described in any one of claims 1 to 5.

7. A computer-readable storage medium, wherein at least one program is stored in the storage medium, characterized in that: The program is loaded and executed by a processor to implement the method for detecting dead loops in server application threads as described in any one of claims 1 to 5.

Images