Cross-thread monitoring method and device for application program performance and electronic equipment

Abstract

The invention provides a cross-thread monitoring method and device for application program performance and electronic equipment, when a target application program performance monitoring task is executed, whether cross-thread operation exists in the execution process of the target application program performance monitoring task is dynamically detected, if the cross-thread operation exists, the set membership among all threads is further obtained, and the performance of the application program is monitored according to the set membership. If the parent thread needing to wait for the child thread exists, a configuration updating thread is created, and transmission configuration parameters between the parent thread and the child thread are modified through the configuration updating thread, so that the subsequent parent thread determines whether the tracking context needs to be transmitted to the child thread or not based on the transmission configuration parameters. Therefore, the transmission of the tracking context is upgraded from static configuration to dynamic configuration, cross-thread operation tracking logic is automatically injected without invasion, the integrity of the tracking context in a cross-thread operation scene can be guaranteed, the transmission efficiency of the tracking context is improved, the duration of waiting for the sub-thread by the parent thread can be shortened, and the transmission efficiency of the sub-thread is improved. And invalid overhead of the system is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software, and particularly relates to a cross-thread monitoring method and device for application program performance and electronic equipment. BACKGROUND

[0002] An application program refers to a computer program designed to complete a specific task such as e-commerce transaction, social network, data analysis and the like. In order to ensure the normal operation of the application program, the performance of the application program can be monitored by APM (Application Performance Monitoring). The code, service and data of the application program are usually stored in multiple nodes of a distributed system. For example, different services such as "user service", "order service" and "payment service" of an e-commerce platform are deployed in different servers, and the application program realizes cross-node interaction through the API framework provided by the distributed system.

[0003] However, in a distributed system, especially in a multi-thread environment, each Java thread has an independent call stack and local variables, which makes the context of the parent thread unable to be directly inherited by the child thread. At this time, the distributed application program performance monitoring scheme faces challenges in tracking the transmission of the context between the parent and child threads.

[0004] In order to solve the challenges in tracking the transmission of the context between the parent and child threads in the distributed application program performance monitoring scheme, the prior art usually manually injects context tracking code by the developer, which undoubtedly increases the development complexity and maintenance cost. SUMMARY

[0005] Therefore, the embodiments of the present application provide a cross-thread monitoring method and device for application program performance and electronic equipment to automatically and non-invasively inject cross-thread operation tracking logic and improve the transmission efficiency of the tracking context.

[0006] In a first aspect, the embodiments of the present application provide a cross-thread monitoring method for application program performance, and the method comprises the following steps. performing a target application program performance monitoring task, and dynamically detecting whether there is a cross-thread operation in the execution process of the target application performance monitoring task; if the cross-thread operation exists, acquiring the parent-child relationship between threads and determining whether there is a target parent thread that needs to wait for a child thread; if the target parent thread exists, creating a configuration update thread, and modifying the transmission configuration parameter between the target parent thread and the child thread through the configuration update thread, so that the target parent thread determines whether to transmit the tracking context to the child thread based on the transmission configuration parameter.

[0007] In a second aspect, the embodiments of the present application provide a cross-thread monitoring device for application performance, wherein the device comprises: a detection module configured to perform a target application performance monitoring task and dynamically detect whether a cross-thread operation exists in an execution process of the target application performance monitoring task; a thread analysis module configured to, if the cross-thread operation exists, acquire a parent-child relationship between threads and determine whether a target parent thread exists which needs to wait for a child thread; a configuration update module configured to, if the target parent thread exists, create a configuration update thread and modify a transfer configuration parameter between the target parent thread and the child thread through the configuration update thread, so that the target parent thread determines whether to transfer a tracing context to the child thread based on the transfer configuration parameter.

[0008] In a third aspect, the embodiments of the present application provide an electronic device, comprising a processor and a memory storing a program, wherein the program comprises instructions which, when executed by the processor, cause the processor to perform the cross-thread monitoring method for application performance according to the first aspect.

[0009] In a fourth aspect, the embodiments of the present application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the cross-thread monitoring method for application performance according to the first aspect.

[0010] The present application has the following beneficial effects: The present application provides a cross-thread monitoring method, device and electronic device for application performance. When a target application performance monitoring task is performed, it is dynamically detected whether a cross-thread operation exists in an execution process of the target application performance monitoring task. If the cross-thread operation exists, the parent-child relationship between threads is further acquired. If a parent thread exists which needs to wait for a child thread, a configuration update thread is created and the transfer configuration parameter between the parent thread and the child thread is modified through the configuration update thread, so that the parent thread determines whether to transfer a tracing context to the child thread based on the transfer configuration parameter. In this way, the transfer of the tracing context is upgraded from static configuration to dynamic configuration, the cross-thread operation tracing logic is automatically and non-invasively injected, the integrity of the tracing context in the cross-thread operation scenario is guaranteed, the efficiency of the tracing context transfer is improved, the time length of the parent thread waiting for the child thread is reduced, and the system invalid overhead is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0011] More details, features and advantages of the present application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 Fig. 1 shows a flow diagram of a method for cross-thread monitoring of application performance according to an embodiment of the present application; Figure 2 Fig. 2 shows another flow diagram of a method for cross-thread monitoring of application performance according to an embodiment of the present application; Figure 3 Fig. 3 shows a structure diagram of a device for cross-thread monitoring of application performance according to an embodiment of the present application; Figure 4 Fig. 4 shows a structure diagram of an exemplary electronic device that can be used to implement embodiments of the present application. DETAILED DESCRIPTION

[0012] Embodiments of the present application will be described in more detail with reference to the drawings. Although certain embodiments of the present application are shown in the drawings, it is understood that the present application can be embodied in various forms and should not be interpreted in a limited sense as set forth in the embodiments set forth herein. Rather, these embodiments are provided so that the present application can be more thoroughly and completely understood.

[0013] It should be understood that each of the steps recited in the method embodiments of the present application can be performed in different orders and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the steps shown. The scope of the present application is not limited in this respect.

[0014] The term "comprising" and variations thereof as used herein are used in the inclusive sense and mean "including but not limited to". The term "based on" means "based, at least in part, on". The term "one embodiment" means "at least one embodiment". The term "another embodiment" means "at least one additional embodiment". The term "some embodiments" means "at least some embodiments". Related definitions are given throughout the detailed description. It should be noted that the concepts mentioned in the present application are merely used to distinguish different apparatuses, modules or units, and are not intended to limit the functions performed by these apparatuses, modules or units or the order or interdependence of these functions.

[0015] It should be noted that the terms "one", "more than one" or "at least one" used in the present application are illustrative and not limiting, and those skilled in the art should understand that, unless otherwise explicitly stated in the context, it should be understood as "one or more".

[0016] With the wide application of distributed systems and microservice frameworks, APM has become an important means to ensure system performance and reliability. Among them, the common distributed tracking scheme is based on OpenTracing implementation. OpenTracing is a set of standardized specifications for distributed system tracking, which is used to unify the API and data model of different distributed tracking systems, and helps developers to implement end-to-end performance monitoring in microservice architecture. Among them, OpenTracing mainly records the propagation path (also known as propagation chain) of requests in the system through Span and Trace. Specifically, the OpenTracing monitoring performance workflow can include: 1. Data collection: Buried points and create Span in code, where Span can be understood as span, which represents an independent unit of work of OpenTracing, such as a function call, a database query. The data associated with it includes: operation name, start / end time, duration, label, log, reference, label is used to record business attributes, log is used to record key events (such as error information), reference is used to associate other Spans (such as child Span relationship).

[0017] 2. Cross-service tracking: Write Span Context into data packet header, such as HTTP Header, downstream services create child Span by parsing the data packet header and then create child Span through the Span Context carried in the message data packet header in the message queue, such as Kafka queue, to obtain the entire tracking chain. Among them, all related Spans can be linked by TraceID, and then a complete user request link can be recorded through a tree structure, such as the whole process from front-end request to back-end microservice.

[0018] Among them, Span Context can be called span context, which can also be called tracking context. In this application, tracking context is a noun, not a verb. The content of the tracking context can include TraceID, Span ID and other tracking metadata. Span Context is the carrier of various tracking metadata, used to pass tracking information between services. Among them, the Spans of different services in the distributed system can be associated with the same Trace, such as through HTTP packet header Header, message queue attribute transmission, etc.

[0019] 3. Data aggregation and storage: Receive Span data source and store it in the corresponding database.

[0020] 4. Performance analysis and visualization: The complete request chain generated by the user can be retrieved from the database by TraceID, and then the time consumption proportion of each Span is analyzed to locate the existing problems, such as slow database query, service call delay, etc. Performance indicators such as overall service response time, call frequency and error rate of each microservice, resource consumption, etc. can be generated according to the analysis results.

[0021] In summary, in the process of distributed tracking, it is necessary to ensure that the tracking context of the parent thread can be inherited by the child thread (such as the Trace ID and Span ID of the parent thread need to be passed to the child thread) to form a complete call chain. After the child thread is executed, the completion time of the Span can be correctly recorded and associated with the parent Span.

[0022] However, the transfer of tracking context (such as the aforementioned Span Context in OpenTracing) between parent and child threads is challenging. For example, when using ThreadPoolExecutor or New Thread to create threads, it is difficult to pass the tracking context between parent and child threads. The main challenges are the asynchronous nature of thread scheduling and the thread isolation of context storage, which are manifested in the following aspects: 1) Each Java thread has an independent call stack (Call Stack) and local variables, so the tracking context of the parent thread cannot be inherited by the child thread by default.

[0023] 2) The child thread created by ThreadPoolExecutor thread pool may be scheduled by different thread executors, and the execution time and thread are not determined.

[0024] This results in: ThreadLocal is thread-isolated, and the child thread cannot obtain the ThreadLocal value of the parent thread; secondly, the threads in the thread pool are reused, and the original tracking context may be lost when executing tasks; or in asynchronous callback, such as in the CompletableFuture asynchronous change model, the callback function may be executed on a different thread, resulting in the loss of tracking context. In order to overcome such problems, existing technologies usually require developers to manually inject tracking code, increasing the development complexity and maintenance cost.

[0025] In addition to the increased development complexity and maintenance costs caused by manually injecting tracing code by the developer in the prior art described above, manually injecting tracing code requires that the tracing context of the parent thread be passed to the child thread regardless of whether the child thread task needs to be traced, which indiscriminately associates the context and can introduce unnecessary performance overhead, especially when the parent thread does not wait for the child thread task to complete, the passing of the tracing context is meaningless and increases performance loss.

[0026] On this basis, the prior art proposes that the JavaAgent technology can be used to dynamically modify the bytecode when the class is loaded in the Java virtual machine (JVM), which makes it possible to automatically inject the tracing logic of the tracing context. However, this scheme still has the following problems: it is difficult to generate a semantically rich code representation by directly parsing the bytecode, so it is challenging to analyze whether the parent thread waits for the child thread task under complex synchronization scenarios (such as Future delivery and CountDownLatch), and there is a lack of asynchronous analysis and decompilation mechanisms, which makes it impossible to flexibly adjust the corresponding tracing strategy in actual application.

[0027] Therefore, the present application provides a cross-thread monitoring method and device for application program performance and electronic equipment. In a first aspect, the present application provides a cross-thread monitoring method for application program performance. The method is applied to any electronic equipment with cross-thread monitoring function for application program performance, including but not limited to personal mobile terminals, computers or servers, etc. As shown in the figure, the method comprises the following steps: Figure 1 S11, performing a target application program performance monitoring task, and dynamically detecting whether there is a cross-thread operation in the execution process of the target application performance monitoring task; S12, if the cross-thread operation exists, obtaining the parent-child relationship between threads and determining whether there is a target parent thread that needs to wait for a child thread; S13, if the target parent thread exists, creating a configuration update thread, and modifying the transmission configuration parameter between the target parent thread and the child thread through the configuration update thread, so that the target parent thread determines whether to pass the tracing context to the child thread based on the transmission configuration parameter.

[0028] ​The method provided in the application upgrades the transmission of the tracing context from static configuration to dynamic configuration by dynamically detecting whether there is cross-thread operation in the execution process of the target application performance monitoring task when performing the target application performance monitoring task, further obtaining the parent-child relationship between threads if there is cross-thread operation, creating a configuration update thread and modifying the transmission configuration parameter between the parent thread and the child thread through the configuration update thread if there is a parent thread that needs to wait for a child thread, so that the parent thread determines whether it needs to transmit the tracing context to the child thread based on the transmission configuration parameter. In this way, the transmission of the tracing context is upgraded from static configuration to dynamic configuration, the cross-thread operation tracing logic is automatically and non-invasively injected, the integrity of the tracing context in the cross-thread operation scenario is guaranteed, the efficiency of the transmission of the tracing context is improved, the time length of the parent thread waiting for the child thread is reduced, and the system invalid overhead is reduced.

[0029] The steps S11 to S13 will be described in detail below in combination with specific examples: In the application, the target application performance monitoring task can be an APM task developed by a developer in advance as needed, and the application program performance is monitored by executing the APM task. Specifically, the distributed tracing association of cross-thread operations is realized through the APM task. As an example, the target application performance monitoring task is the monitoring task submitted by the ThreadPoolExecutor in the Java application or the monitoring task constructed by new Thread in the Java application under the OpenTracing specification mentioned above, and the distributed tracing association of cross-thread operations is realized through the monitoring tasks.

[0030] Further, the target application performance monitoring task refers to a business execution unit implemented by the ThreadPoolExecutor or created by the new Thread and implementing the Runnable or Callable interface, and the cross-thread monitoring of the application performance is implemented through the business execution unit. That is, in the present application, the execution step S11 executes the target application performance monitoring task, which can be the execution of the business execution unit implemented by the ThreadPoolExecutor or created by the new Thread and implementing the Runnable or Callable interface. Among them, the ThreadPoolExecutor is a core class for implementing a thread pool in the Java standard library, which is referred to as a preset thread core class in the present application. By reusing thread resources, managing thread life cycles and controlling development degrees, the performance and stability of multi-threaded applications are ensured. In other words, the business execution unit created by the ThreadPoolExecutor needs to meet the task parameters and task execution logic rules set by the ThreadPoolExecutor to be normally executed.

[0031] In order to be able to dynamically detect whether the target application performance monitoring task has cross-thread operation, the present application modifies the task execution logic rules set in the ThreadPoolExecutor, especially modifies the task detection rules, so that the task created by the ThreadPoolExecutor supports cross-thread operation and supports dynamic detection of the task. Based on this, in some possible embodiments, before the execution step S11, the method further includes the following steps S10-1 and S10-2 to modify the task detection rules of the ThreadPoolExecutor: S10-1, in response to the JavaAgent start operation in the virtual machine, dynamically modifying the byte code of the thread start method and / or the thread running method in the preset thread core class, and adding dynamic detection execution logic in the execution logic of the thread start method and / or the thread running method; S10-2, executing the thread start method or the thread running method, dynamically detecting the target application performance monitoring task, and determining whether there is cross-thread operation in the execution process of the target application performance monitoring task.

[0032] Wherein, the virtual machine is a Java virtual machine JVM, and the JavaAgent is a special Jar file in Java, which is a bytecode enhancement technology and allows Java programs to modify or monitor Java classes in the code during program execution. In step S10-1, if the JavaAgent in the JVM is started, the thread starting method and / or the thread running method in the preset thread core class can be modified through the JavaAgent. Wherein, the preset thread core class can be the ThreadPoolExecutor, and the preset thread core class can also be the Thread class. The thread starting method in the preset thread core class can be the submit method in the ThreadPoolExecutor, and the thread running method in the preset thread core class can be the execute method in the ThreadPoolExecutor.

[0033] Therefore, as an embodiment, when performing the above step S10-1, the ASM (a Java bytecode operation framework) or ByteBuddy (another Java bytecode operation framework) framework can be used to modify the submit and execute methods of the ThreadPoolExecutor and / or the constructor method (such as Thread(Runnable) and run method) of the Thread class through the JavaAgent at the JVM startup, so as to modify the execution logic of the ThreadPoolExecutor and / or the Thread class, and add a dynamic detection execution logic in the execution logic of the thread starting method and / or the thread running method.

[0034] Wherein, the dynamic detection execution logic is set according to actual needs. As an embodiment, the dynamic detection execution logic can be simply divided into: intercepting the task submission of the target application performance monitoring task, intercepting the task execution of the target application performance monitoring task, detecting cross-thread operation, and asynchronously uploading files (such as uploading class files abnormally). Wherein, the class file is a Java bytecode file used to store compiled Java classes or interfaces. In the embodiment of the present application, the class file refers to the file generated after the class implementing the monitoring logic is compiled.

[0035] Specifically, the ASM or ByteBuddy framework can be used to modify the bytecode of the following key methods: For the ThreadPoolExecutor.submit(Runnable task) method, the execution logic of intercepting the task submitted by the thread pool is added; For the ThreadPoolExecutor.execute(Runnable command) method, the execution logic of intercepting the execution of the task of the thread pool is added; For the Thread.start() method, the execution logic of intercepting the start operation of the thread created by new Thread is added; For the constructor method (such as Thread(Runnable target)) of the Thread class, the execution logic of capturing the Runnable task instance passed in is added.

[0036] Among them, the newly added execution logic will automatically trigger the capture and cross-thread operation detection of the task instance when these methods are executed, without modifying the business code.

[0037] By selecting the embodiment of the present application, the bytecode of the thread start method and / or the thread running method can be dynamically modified through JavaAgent, so as to achieve non-invasive setting of the dynamic detection execution logic of the thread without modifying the business code. Since it modifies the class at runtime, it can achieve dynamic modification of the dynamic detection execution logic without restarting the application, and is suitable for any type of Java application and is not limited by the framework.

[0038] As an implementation mode, the above-mentioned dynamic detection execution logic includes cross-thread operation detection logic, which can be implemented by the following steps when executing the above-mentioned step S10-2: When the target application performance monitoring task is submitted, the cross-thread operation detection logic is executed to obtain the task instance of the target application performance monitoring task; According to the task instance, it is determined whether the target application performance monitoring task has cross-thread operation.

[0039] Among them, the cross-thread operation detection logic specifically includes: a. Obtain the key information of the task instance, wherein the key information of the task instance includes: task object, parent thread context, task class identifier. Among them, the task object includes: obtaining the passed-in Runnable or Callable instance, such as task.getClass().getName(). The parent thread context information includes: recording the parent thread information of the task submitted currently, including the thread ID and call stack information of the parent thread. The character class identifier is used as a unique identifier for distinguishing different tasks.

[0040] Wherein, the detection of whether there is cross-thread operation can be performed by executing the captureTask method to detect whether the worker thread executing the task instance and the thread (i.e. parent thread) submitting the task are the same thread, if not, it can be determined that there is cross-thread operation. Since the new Thread core class creates a new thread that is necessarily different from the parent thread when creating a task, if the task is created by new Thread and the thread start method start in new Thread is called, it can be directly determined that the target application performance monitoring task has cross-thread operation.

[0041] As another implementation, the parent thread ID can also be obtained by the Thread.getId() method, and compared with the worker thread ID of the thread pool (which can be obtained by the getThreadFactory() of the thread pool), if they are consistent, there is no cross-thread operation, if they are not consistent, there is cross-thread operation.

[0042] If it is determined that the target application performance monitoring task has cross-thread operation, the corresponding target application performance monitoring task can be marked as "cross-thread operation task" and stored in a temporary buffer area, which can be ThreadLocal or a memory queue.

[0043] On the basis of determining that there is cross-thread operation in step S11, the method provided by the application further comprises: S2, if there is the cross-thread operation, triggering an asynchronous analysis process, wherein the asynchronous analysis process comprises: S21, asynchronously uploading the class file corresponding to the target application performance monitoring task to a backend server, and generating source code based on the class file by the backend server using a decompilation tool; S22, calling each middleware in the large language model intelligent component to analyze the source code, and obtaining the parent-child relationship between threads and determining whether there is a target parent thread that needs to wait for a child thread.

[0044] The asynchronous analysis process can be divided into task class file acquisition, asynchronous uploading, and source code analysis. Wherein, when executing the above step S21, the class byte stream of the task instance can be extracted through the InstrumentationAPI interface provided by JavaAgent, and then the corresponding class file can be generated based on the calss byte stream. Specifically, the class byte stream, task class name, parent thread call stack information, and other information can be summarized and sorted to generate a class file, and further uploaded to the backend server in an asynchronous manner through HTTP Hypertext Transfer Protocol or a message queue (such as Kafka queue). In this way, the class file uploading thread can be prevented from blocking the business thread.

[0045] Further, the class file is decompiled into Java source code by the backend server using a decompilation tool. Among them, the backend server can decompile the class file into Java source code by using Fernflower (a decompilation tool) or CFR (another decompilation tool). Then, the class name, method signature, field information and the like related to the target application performance monitoring task in the source code are extracted, and a JSON format structured representation is generated, so as to perform step S12 or step S22, based on the JSON format structured representation, to obtain the parent-child relationship between threads and determine whether there is a target parent thread that needs to wait for a child thread.

[0046] Specifically, information extraction can be performed on the structured representation (which can also be understood as structured data), and key information related to thread call strong association is extracted from the structured data: synchronization method call situation, thread pool usage situation, context transfer situation. Among them, the synchronization method call situation can be obtained by identifying synchronization operations such as Future.get(), CountDownLatch.await(), the thread pool usage situation can be obtained by detecting thread pool submission methods such as ExecutorService.submit(), and the context transfer situation can be obtained by checking context transfer tools such as ThreadLocal, InheritableThreadLocal.

[0047] Specifically, the parent-child relationship between threads and whether there is a target parent thread that needs to wait for a child thread can be obtained by performing the above step S22, by calling each middleware in the large language model intelligent component to analyze the source code or analyze the structured data. Among them, the large language model is referred to as LLM (Large Language Model, large language model LLM), such as GPT-4, and the large language model intelligent component refers to a component developed based on the LLM model and having source code analysis capability.

[0048] As an implementation, the large language model intelligent component can include several middlewares, each of which performs its own function to analyze the source code. Among them, each middleware can include: a code extraction middleware (hereinafter referred to as a code extraction Agent), a semantic analysis middleware (hereinafter referred to as a semantic analysis Agent), a synchronization pattern recognition middleware (hereinafter referred to as a synchronization pattern recognition Agent), and a decision middleware (hereinafter referred to as a decision Agent). By code extraction, source code analysis of the class file by each middleware, the parent-child relationship between threads of the target application performance monitoring task and whether there is a target parent thread that needs to wait for a child thread can be determined.

[0049] Specifically, the input of the code extraction middleware is the class name of the task object (such as Runnable or Callable) and the call stack of the parent thread. The agent extraction middleware is configured to obtain the class file and upload it to the backend server for decompilation, generate a structured code representation from the backend server, and then obtain the readable Java source code from the backend server. Finally, the structured code representation of the target application performance monitoring task is output, specifically the decompiled source code, method signature, and call stack information. As an implementation, the code extraction middleware can output the entire code extraction process through a large language model to set the output format. For example, the code extraction middleware corresponding to the code extraction process can output the following format: **Task**: Decompile the uploaded class file into Java source code and generate a structured representation.

[0050] **Input**: - Class file byte stream: {class_file_bytes} - Call stack information: {call_stack} **Instructions**: 1. Use a decompilation tool (such as Fernflower or CFR) to convert the class file into Java source code.

[0051] 2. Extract the class name, method signature, and method body from the source code.

[0052] 3. Combine the call stack information to generate a structured JSON representation with the following format: { "class_name": "<class_name>", "methods": [ { "signature": "<method_signature>", "body": "<method_body_source_code>" } ], "call_stack": "<call_stack_info>" } **Output**: - Structured JSON representation containing decompiled source code and call stack information.

[0053] Further, the semantic analysis Agent is used to extract information from the decompiled source code, including method calls, variable passing, and control flow information. Then, based on the extracted content, a semantic context is constructed to provide a foundation for subsequent synchronization pattern recognition Agents.

[0054] The input of the semantic analysis Agent is the structured code representation generated by the code extraction Agent, which includes the source code and call stack.

[0055] The specific execution process of the semantic analysis Agent includes: 1) Use LLM (Transformer-based code analysis model) to parse the decompiled source code.

[0056] 2) Identify method call chains and track the definition, assignment, and passing paths of variables such as Future and CountDownLatch.

[0057] 3) Analyze control flow and detect conditional branches, loops, and exception handling structures.

[0058] 4) Pay special attention to the passing of Future objects (such as passing to the upper caller through return value or parameter).

[0059] 5) Generate a semantic context to describe the logical structure and dependency of the code.

[0060] The final output of the semantic analysis Agent is the semantic context, which includes method call chains, variable flow, and control flow graphs. The semantic context can be represented in JSON or AST format.

[0061] As an implementation, the semantic analysis middleware can output the entire semantic analysis process through a large language model with a specified output format. For example, the semantic analysis middleware corresponding to the semantic analysis process can output the following format: **Task**: Parse Java source code, extract method calls, variable passing, and control flow information, and generate a semantic context.

[0062] **Input**: - Structured code representation: { "class_name": "<class_name>", "methods": [ { "signature": "<method_signature>", "body": "<method_body_source_code> " } ], "call_stack": "<call_stack_info> " } **instruction**: 1. Parse the source code and identify all method calls, including method names, parameters, and return values.

[0063] 2. Track the definition, assignment, and transfer path of variables (such as Future and CountDownLatch).

[0064] 3. Analyze control flow and identify conditional branches, loops, and exception handling structures.

[0065] 4. Generate semantic context in the following format: { "method_calls": [ { "method_name": " <name>", "parameters": [" <param1> ", " <param2>"], "return_type": " <type>", "caller": "<caller_method>" } ], "variable_flows": [ { "variable_name": " <name>", "string": "type", <type>", "definition": "<line_number>", "passes_to": ["<method_or_class>"] } ], "control_flow": { "branches": [" <condition1> ", " <condition2>"], "loops": [" <loop1> ", " <loop2>"] } } **Output**: - Semantic context JSON, including method call chain, variable flow and control flow information.

[0066] Furthermore, the synchronization pattern recognition agent detects whether there is a synchronization pattern in the Java source code, and then determines whether the parent thread is waiting for the child thread task based on the synchronization pattern. Specifically, the input of the synchronization pattern recognition agent is the semantic context generated by the semantic analysis agent, and then the following processing flow is performed based on the semantic context: 1) Use the pre-trained Large Language Model (LLM) model (for Java synchronization mode) to analyze the semantic context.

[0067] 2) Detect direct waiting mode: such as Future.get(), Thread.join(), CountDownLatch.await().

[0068] 3) Detect indirect wait patterns, such as when a Future object is passed to an upper-level caller and Future.get() is called.

[0069] 4) Check other synchronization tools, such as CyclicBarrier.await() and Semaphore.acquire().

[0070] 5) Analyze the context of synchronization operations (such as in loops or conditional branches) to ensure accuracy.

[0071] 6) Generate a synchronization pattern report that lists all detected synchronization operations and their call paths.

[0072] The output of the synchronization mode recognition agent is a synchronization mode report, which includes the detected synchronization operations and context information.

[0073] As an implementation method, the synchronization pattern recognition agent can output the entire synchronization pattern recognition process in an output format set by the large language model. For example, the synchronization pattern recognition process corresponding to the synchronization pattern recognition agent can be output in the following format: **Task**: Detect synchronization patterns in Java code to determine whether the parent thread is waiting for the child thread task.

[0074] **enter**: - Semantic context: { "method_calls": [ { "method_name": "get_user_info" <name>", "parameters": [" <param1> ", " <param2> "return_type": " <type>", "caller": "<caller_method>" } ], "variable_flows": [ { "variable_name": " <name>", "string": "type", <type>", "definition": "<line_number>", "passes_to": ["<method_or_class>"] } ], "control_flow": { "branches": [" <condition1> ", " <condition2>], "loops": [ "loops": [" <loop1> ", " <loop2>] } } **Instructions**: 1. Detect synchronization-related method calls such as Future.get(), Thread.join(), CountDownLatch.await(), CyclicBarrier.await(), Semaphore.acquire().

[0075] 2. Analyze the passing path of Future objects and check if Future.get() is called in the upper caller.

[0076] 3. Identify the context of synchronization operations, such as calls in loops, conditional branches, or exception handling.

[0077] 4. Generate a synchronization pattern report in the following format: { "sync_operations": [ { "type": "<Future.get|Thread.join|CountDownLatch.await>", "method": "<method_name>", "context": "<loop|branch|try-catch>", "call_path": "<caller_method_chain>" } ] } **Output**: - A synchronization pattern report JSON listing all synchronization operations and their contexts.

[0078] Based on the synchronization pattern report, the decision Agent determines whether the parent thread depends on the result of the child thread task, thereby determining whether there is a target parent thread that needs to wait for the child thread. Further, in some possible embodiments, the method provided by the present application further comprises: If the target parent thread exists, associate the target parent thread with the target child thread that the target parent thread needs to wait for, and execute the configuration update thread.

[0079] Specifically, the decision Agent synthesizes the synchronization pattern report, judges whether the parent thread depends on the result of the child thread task, and decides whether cross-thread context association is needed. Among them, the input of the decision Agent is the synchronization pattern report generated by the synchronization pattern recognition Agent, and then whether cross-thread context association is needed is decided by executing the following process: 1) Use LLM to analyze the synchronization pattern report comprehensively to evaluate whether the parent thread is waiting for the child thread task.

[0080] 2) Apply decision rules: if Future.get(), Thread.join() or CountDownLatch.await() is detected, mark as direct waiting. If Future is passed to the upper caller and Future.get() is called, mark as indirect waiting. If CountDownLatch.await() is used and the counter is related to the child thread task, mark as waiting. If there is no synchronization operation or the child thread runs independently, mark as no need to associate.

[0081] 3) Use the reasoning ability of LLM to output the final decision combined with the confidence score (such as based on the context and frequency of synchronization operations).

[0082] 4) Return a Boolean value to decide whether to modify the tracking configuration.

[0083] Among them, the decision Agent outputs a Boolean value, which identifies whether the tracking context needs to be associated through different Boolean values. As an example, True can be returned to identify the need to associate the tracking context, and False can be returned to identify the need not to associate the tracking context.

[0084] As an embodiment, the decision Agent can output the entire decision process through a large language model setting output format. As an example, the decision process corresponding to the decision Agent can be output in the following format: **Task**: Synthesize synchronization pattern report, judge whether the parent thread depends on the result of the child thread task, and decide whether cross-thread context association is needed.

[0085] **Input**: - Synchronization pattern report: { "sync_operations": [ { "type": "<Future.get|Thread.join|CountDownLatch.await>", "method": "<method_name>", "context": "<loop|branch|try-catch>", "call_path": "<caller_method_chain>" } ] } **Instructions**: 1. Analyze synchronization pattern reports, identify direct waits (e.g., Future.get(), Thread.join()) and indirect waits (e.g., Future passed to a method that calls Future.get()).

[0086] 2. Evaluate the context of synchronization operations, check if they are related to the child thread task (e.g., CountDownLatch's counter).

[0087] 3. Apply decision rules: - If there are direct or indirect waits, mark as needing association.

[0088] - If there are no synchronization operations or the child thread runs independently, mark as not needing association.

[0089] 4. Calculate a confidence score (0-1) based on the frequency of synchronization operations and the reliability of the context.

[0090] 5. Output a boolean value and a confidence score in the following format: { "needs_tracing":<true|false>, "confidence":<0.0-1.0> } **Output**: - A JSON object containing a boolean value indicating whether association is needed and a confidence score.

[0091] Further, the decision Agent can output a boolean value and a confidence score indicating whether there is a target parent thread and whether the corresponding child thread needs to be traced and associated with the target parent thread. Based on this, when performing the above step S13, the following steps can be implemented: Create a configuration update thread and start the configuration update thread to enable the target parent thread to associate with the tracing context of the child thread during the next parent thread task execution.

[0092] Wherein, if the decision Agent outputs True, the specific output needs_tracing=true, a new thread needs to be started to modify the tracing configuration parameter of the target application performance monitoring task, wherein the tracing configuration parameter is located in the global configuration table of the target application performance monitoring task. Modifying the tracing configuration parameter can be setting a tracing flag for the task type of the target application performance monitoring task in the global configuration table. Then the modified tracing configuration parameter is stored in the thread-safe ConcurrentHashMap, and the task class name that needs to be associated is recorded.

[0093] As an implementation, the configuration update thread is configured as an asynchronous thread, so that the tracing configuration parameter update can be executed through an asynchronous thread, and it can be ensured that the configuration update thread does not block the business main thread of the application.

[0094] Wherein, the target parent thread is associated with the tracing context of the child thread at the next parent thread task execution, including: At the next execution of the target application performance monitoring task, the global configuration table is checked. If the task class name in the global configuration table has been marked as needing to be associated, the tracing context SpanContext is serialized into Map format through the Inject method of OpenTracing, and is attached to the custom field of the parent thread task. Further, before the execution of the child thread task, specifically through the execute method or the run method, if the child thread task contains the tracing context SpanContext, the Extract method is used to restore it, create a child Span and associate the corresponding parent Span.

[0095] Finally, after the execution of the child thread task is completed, the Span data of each Span is collected, including the execution time and the operation name, and then a complete user request link under the target application performance monitoring task is reported to the OpenTracing compatible tracing system (such as Jaeger, Zipkin).

[0096] The following is a code example for implementing the method of the present application, for reference only, and not as the only implementation code: import io.opentracing.SpanContext; import java.lang.instrument.Instrumentation; import java.util.concurrent.ConcurrentHashMap; import java.util.function.Consumer; public class CrossThreadTracer { private static final ConcurrentHashMap<String, Boolean>traceConfig =new ConcurrentHashMap<>(); private static Instrumentation instrumentation; public static void setInstrumentation(Instrumentation inst) { instrumentation = inst; } public static void interceptSubmit(Runnable task, Tracer tracer) { String taskId = task.getClass().getName(); if (traceConfig.getOrDefault(taskId, false)&&tracer.activeSpan()!=null) { Span parentSpan = tracer.activeSpan(); SpanContext context = parentSpan.context(); return new TaskWrapper(task, context); } if (isCrossThreadOperation(task)) { LLMAgentPipeline.asyncAnalyzeTask(task, result ->{ if (result.isParentWaiting()) { new Thread(() ->traceConfig.put(taskId, true)).start(); } }); } return task; } public static void interceptExecute(Runnable task, Tracer tracer) { if (task instanceof TaskWrapper) { TaskWrapper wrapper = (TaskWrapper) task; SpanContext context = wrapper.getContext(); Span childSpan = tracer.buildSpan("childTask").asChildOf(context).start(); tracer.scopeManager().activate(childSpan); } } static class LLMAgentPipeline { static void asyncAnalyzeTask(Runnable task, Consumer <llmanalysisresult>callback) { new Thread(() ->{ CodeData codeData = CodeExtractionAgent.extract(task); SemanticContext context = SemanticAnalysisAgent.analyze(codeData); SyncPatterns patterns = SyncPatternAgent.detect(context); LLMAnalysisResult result = DecisionAgent.decide(patterns); callback.accept(result); }).start(); } } static class CodeExtractionAgent { static CodeData extract(Runnable task) { Class<?>taskClass = task.getClass(); byte[] classFile = getClassFile(taskClass); String sourceCode = BackendService.uploadAndDecompile(classFile); String callStack = getCallStack(); return new CodeData(sourceCode, callStack); } private static byte[] getClassFile(Class<?>clazz) { try { String className = clazz.getName().replace('.', ' / '); return instrumentation.getClassFile(className); } catch (Exception e) { throw new RuntimeException("Failed to get class file", e); } } private static String getCallStack() { return Thread.currentThread().getStackTrace().toString(); } } static class SemanticAnalysisAgent { static SemanticContext analyze(CodeData codeData) { String prompt = String.format( "Task: Parse Java source code, extract method calls, variable transfer and control flow information, and generate semantic context.\n" + "Input:\n" + "- Structured code representation:\n" + "{\n" + "\"class_name\": \"%s\",\n" + "\"source_code\": \"%s\",\n" + "\"call_stack\": \"%s\"\n" + "}\n" + "Command:\n" + "1. Parse the source code and identify all method calls, including method names, parameters, and return values.\n" + "2. Track the definition, assignment, and transfer path of variables (such as Future and CountDownLatch).\n" + "3. Analyze control flow and identify conditional branches, loops, and exception handling structures.\n" + "4. Generate semantic context in the following format:\n" + "{\n" + "\"method_calls\": [{\"method_name\": \" <name>\", \"parameters\": [\" <param1>"], "return_type": " <type>\", \"caller\": \"<caller_method>\"}],\n" + "\"variable_flows\": [{\"variable_name\": \" <name>\", \"type\": \" <type>\"\", \"definition\": \"<line_number>\", \"passes_to\": [\"<method_or_class>\"]}]},\n" + "\"control_flow\": {\"branches\": [\" <condition1>"], "loops": [ <loop1>"]}\n" + "}\n" + "Output:\n" + "- Semantic context JSON containing method call chains, variable flow, and control flow information.", codeData.getClassName(), codeData.getSourceCode(),codeData.getCallStack() ); return BackendService.callLLM(prompt, SemanticContext.class); } } static class SyncPatternAgent { static SyncPatterns detect(SemanticContext context) { String prompt = String.format( "Task: Detect synchronization patterns in Java code and determine if parent threads are waiting for child thread tasks.\n" + "Input:\n" + "- Semantic context:\n" + "%s\n" + "Instructions:\n" + "1. Detect synchronization-related method calls such as Future.get(), Thread.join(), CountDownLatch.await(), CyclicBarrier.await(), Semaphore.acquire().\n" + "2. Analyze the transfer path of Future objects and check if Future.get() is called in the upper caller.\n" + "3. Identify the context of synchronization operations, such as calls within loops, conditional branches, or exception handling.\n" + "4. Generate a synchronization pattern report in the following format:\n" + "{\n" + "\"sync_operations\": [{\"type\": \"<Future.get|Thread.join|CountDownLatch.await>\", \"method\": \"<method_name>\", \"context\": \"<loop|branch|try-catch>\", \"call_path\": \"<caller_method_chain>\"}]\n" + "}\n" + "Output:\n" + "- Sync pattern report JSON listing all synchronization operations and their contexts.", context.toJson() ); return BackendService.callLLM(prompt, SyncPatterns.class); } } static class DecisionAgent { static LLMAnalysisResult decide(SyncPatterns patterns) { String prompt = String.format( "Task: Consolidate sync pattern report and determine if parent thread is waiting for child thread tasks, decide if cross-thread context association is needed.\n" + "Input:\n" + "- Sync pattern report:\n" + "%s\n" + "Instructions:\n" + "1. Analyze the sync pattern report, identify direct waits (e.g. Future.get(), Thread.join()) and indirect waits (e.g. Future passed to another method that calls Future.get()).\n" + "2. Evaluate the context of the synchronization operations, check if they are related to child thread tasks (e.g. CountDownLatch's counter).\n" + "3. Apply decision rules:\n" + "- If there are direct or indirect waits, flag for association.\n" + "- If no synchronization operations or subthreads run independently, marked as not needing association.\n" + "4. Calculate a confidence score (0-1) based on the frequency of synchronization operations and contextual reliability.\n" + "5. Output a boolean value and confidence in the following format:\n" + "{\n" + "\"needs_tracing\":<true|false>,\n" + "\"confidence\":<0.0-1.0>\n" + "}\n" + "Output:\n" + "- JSON object containing a boolean value for whether association is needed and a confidence score.", patterns.toJson() ); return BackendService.callLLM(prompt, LLMAnalysisResult.class); } } static class LLMAnalysisResult { private boolean needsTracing; private double confidence; boolean isParentWaiting() { return needsTracing; } } static class CodeData { private String sourceCode; private String callStack; CodeData(String sourceCode, String callStack) { this.sourceCode = sourceCode; this.callStack = callStack; } String getClassName() { return "TaskClass";} / / Simplified String getSourceCode() { return sourceCode;} String getCallStack() { return callStack;} } static class SemanticContext { String toJson() { return "{}";} / / Simplified } static class SyncPatterns { String toJson() { return "{}";} / / Simplified } static class BackendService { static String uploadAndDecompile(byte[] classFile) { String prompt = String.format( "Task: Decompile the uploaded class file into Java source code and generate a structured representation.\n" + "Input:\n" + "- class file byte stream: %s\n" + "- Call stack information: %s\n" + "Command:\n" + "1. Use a decompiler tool (such as Fernflower or CFR) to convert the class file into Java source code.\n" + "2. Extract class names, method signatures, and method bodies from source code.\n" + "3. Combine the call stack information to generate a structured JSON representation in the following format:\n" + "{\n" + "\"class_name\": \"<class_name> \",\n" + "\"methods\": [{\"signature\": \"<method_signature>\", \"body\": \"<method_body_source_code>\"}],\n" + "\"call_stack\": \"<call_stack_info>\"\n" + "}\n" + "Output:\n" + "- Structured JSON representation containing the decompiled source code and call stack information.", Base64.getEncoder().encodeToString(classFile), getCallStack() ); return callLLM(prompt, String.class); } static <t>T callLLM(String prompt, Class <t>responseType) { / / Simulate LLM call to backend service if (responseType == String.class) { return (T) " / * Decompiled source code * / "; } else if (responseType == SemanticContext.class) { return (T) new SemanticContext(); } else if (responseType == SyncPatterns.class) { return (T) new SyncPatterns(); } else if (responseType == LLMAnalysisResult.class) { LLMAnalysisResult result = new LLMAnalysisResult(); result.needsTracing = true; / / Simplified result.confidence = 0.9; / / Simplified return (T) result; } return null; } private static String getCallStack() { return Thread.currentThread().getStackTrace().toString(); } } } The execution flow diagram of the above code can be referred to as Figure 2 As shown in the schematic diagram, the dynamic detection logic bytecode is injected in advance before the target application performance monitoring task is executed, including: injecting the bytecode of ThreadPoolExecute / Thread class in advance, and changing the execution logic of ThreadPoolExecute / Thread. Further, the main thread creates an initial independent work unit Span, and further intercepts the task submission of the Span created by the main thread, including two ways of interception: submit or Thread.start interception, and based on the interception result, it is analyzed and detected whether there is cross-thread operation. The specific cross-thread operation detection can refer to the related description of the previous step S11, which will not be repeated here. If there is no cross-thread operation, it indicates that the tracking context information does not need to be associated, and the main thread task can be directly continued to be executed without associating the tracking context. If there is cross-thread operation, it indicates that the tracking context needs to be associated.

[0097] Further, the class file of the target application performance monitoring task is obtained by the middleware code extraction Agent in the LLM large language model, and the class file is uploaded to the backend asynchronously, the backend uses a decompilation tool to generate the corresponding source code, and further uses each middleware Agent of LLM to analyze whether the parent thread and the child thread need to be associated. The source code is analyzed by executing the above step S22 to determine the parent-child relationship between threads and the target parent thread that needs to wait for the child thread. If no association is needed, the tasks of respective threads can be continued to be executed. If association is needed, a configuration update thread is started to modify the tracking configuration parameters, and further, in the next task execution, the tracking configuration parameters are checked to determine whether the parent-child threads have been enabled. If not, the tracking contexts between them do not need to be associated.

[0098] If enabled, the tracking context SpanContext is captured and attached to the task, at this time the child thread is started, and the child thread task execution or Thread run is intercepted, then the SpanContext is captured and the corresponding independent work unit Span is restored, then the child Span is created, the child thread task is executed by the child Span, and finally the tracking data is collected and uploaded to produce the complete request chain generated by the user using the application, so as to analyze the performance of the application.

[0099] In the embodiment of the present application, cross-thread monitoring can be divided into two categories: ThreadPoolExecutor task submission cross-thread monitoring and new Thread construction cross-thread monitoring. Among them: The whole process of ThreadPoolExecutor task submission cross-thread monitoring can be divided into: 1. Environment preparation: Deploy JavaAgent, configure OpenTracing tracer (e.g. Jaeger). Inject bytecode in advance for ThreadPoolExecutor's submit and execute methods.

[0100] 2. Task submission: Intercept the submit method and detect if the task is submitted to the thread pool. If cross-thread operations are triggered, use Instrumentation to obtain the class file of the task and upload it asynchronously to the backend.

[0101] 3. Asynchronous analysis: The backend decompiles the class file into source code, and the LLM Agent analyzes whether the parent thread is waiting for the child thread task (e.g. through Future.get() or CountDownLatch.await()).

[0102] 4. Configuration update: If association is needed, start a new thread to update the tracing configuration (set the task class name's tracing flag).

[0103] 5. Context association: In the next task submission, if the configuration has been updated, capture the SpanContext and attach it to the task. Restore the SpanContext in the execute method and create a child Span.

[0104] 6. Data collection: After the child thread execution is completed, report the tracing data through Jaeger.

[0105] The full flow of cross-thread monitoring for new Thread construction can be: 1. Environment preparation: Deploy JavaAgent, inject bytecode in advance for the constructor method and run method of the Thread class.

[0106] 2. Task submission: Intercept Thread.start, detect cross-thread operations, use Instrumentation to obtain the class file of Runnable, and upload it asynchronously to the backend.

[0107] 3. Asynchronous analysis: The backend decompiles the source code, and the LLM Agent analyzes whether the parent thread is waiting for the child thread (e.g. through Thread.join()).

[0108] 4. Configuration update: If association is needed, start a new thread to update the tracing configuration.

[0109] 5. Context association: In the next Thread.start, if the configuration has been updated, capture the SpanContext and attach it to the task, and restore the SpanContext in the run method.

[0110] 6. Data collection: report tracing data through Jaeger.

[0111] In the embodiment of the application, through dynamic detection and LLM Agent analysis, context association is only performed when the parent thread waits for the task of the child thread, indiscriminate tracking transmission is avoided, unnecessary performance overhead is reduced, and the embodiment is particularly suitable for high-concurrency multi-thread scenarios.

[0112] In the embodiment of the application, through early bytecode injection, asynchronous LLM Agent analysis and dynamic configuration update, combined with the OpenTracing specification, cross-thread tracing context transmission in the ThreadPoolExecutor and new Thread scenarios is implemented. The class file is obtained through Instrumentation, the source code is generated through backend decompilation, combined with LLM Agent collaborative analysis, whether the parent thread waits for the task of the child thread is accurately judged, the complex synchronization scenario is handled, the performance overhead is significantly reduced, the degree of automation of the scheme is high, and the scheme is suitable for complex distributed system monitoring scenarios.

[0113] Based on the method provided in the first aspect, in the second aspect, the application provides a cross-thread monitoring device for application performance, wherein, as shown in the Figure 3 The device 30 comprises: The detection module 301 is configured to perform a target application performance monitoring task, and dynamically detect whether there is a cross-thread operation in a target application performance monitoring task execution process. The thread analysis module 302 is configured to, if the cross-thread operation exists, acquire a parent-child relationship between threads, and determine whether there is a target parent thread that needs to wait for a child thread. The configuration update module 303 is configured to, if the target parent thread exists, create a configuration update thread, and modify a transmission configuration parameter between the target parent thread and the child thread through the configuration update thread, so that the target parent thread determines whether to transmit a tracing context to the child thread based on the transmission configuration parameter.

[0114] The names of the messages or information exchanged between the plurality of devices in the embodiment of the application are only used for illustrative purposes, and are not used to limit the scope of the messages or information.

[0115] In a third aspect, the example embodiments of the application further provide an electronic device, comprising: at least one processor; and a memory connected in communication with the at least one processor. The memory stores a computer program capable of being executed by the at least one processor, and the computer program, when executed by the at least one processor, is configured to cause the electronic device to perform the method according to the embodiments of the application.

[0116] The exemplary embodiments of the present application further provide a non-transitory computer readable storage medium storing a computer program, wherein the computer program, when executed by a processor of a computer, causes the computer to perform the method according to the embodiments of the present application.

[0117] The exemplary embodiments of the present application further provide a computer program product comprising a computer program, wherein the computer program, when executed by a processor of a computer, causes the computer to perform the method according to the embodiments of the present application.

[0118] Reference Figure 4 will now be described, which is an example of a hardware device that can be applied to various aspects of the present application. The electronic device is intended to represent a wide variety of digital electronic computer devices such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device can also represent a variety of mobile devices such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown here, their connections, and their functions, as well as their relationships to one another, are merely exemplary and are not intended to limit the implementations of the present application described and / or claimed herein.

[0119] As Figure 4 shown, the electronic device 400 includes a computing unit 401 that can perform various appropriate actions and processes in accordance with a computer program stored in a read-only memory (ROM 402) or a computer program loaded into a random access memory (RAM 403) from the storage unit 408. In the RAM 403, various programs and data required for the operation of the electronic device 400 can also be stored. The computing unit 401, the ROM 402, and the RAM 403 are connected to each other through a bus 404. An input / output interface (I / O interface 405) is also connected to the bus 404.

[0120] A plurality of components in the electronic device 400 are connected to the I / O interface 405, including: an input unit 406, an output unit 407, a storage unit 408, and a communication unit 409. The input unit 406 can be any type of device that can input information to the electronic device 400, and can receive inputted digital or character information, and generate key signal inputs related to user settings and / or function controls of the electronic device. The output unit 407 can be any type of device that can present information, and can include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 408 can include, but is not limited to, a magnetic disk, an optical disk. The communication unit 409 allows the electronic device 400 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and can include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver, and / or a chipset, such as a Bluetooth™ device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0121] The computing unit 401 can be various general and / or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 401 performs various methods and processes described above. For example, in some embodiments, the aforementioned cross-thread monitoring of application performance method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 400 via the ROM 402 and / or the communication unit 409. In some embodiments, the computing unit 401 can be configured to perform the aforementioned cross-thread monitoring of application performance method by any other appropriate means, such as by means of firmware.

[0122] Program code for carrying out methods of the present application can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, causes the functions / operations specified in the flow charts and / or block diagrams to be implemented. The program code can be entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine or entirely on a remote machine or server.

[0123] In the context of this application, a machine-readable medium can be a tangible medium that can contain or store program code for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more lines of electrical connections, portable computer disks, hard disk drives, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), optical fibers, portable compact disc read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0124] As used in this application, the terms "machine-readable medium" and "computer- readable medium" refer to any computer program product, apparatus and / or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal that can be used to provide machine instructions and / or data to a programmable processor.

[0125] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0126] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0127] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.< / t> < / t> < / type> < / name> < / type> < / name> < / llmanalysisresult> < / loop1> < / condition1> < / type> < / name> < / type> ​ < / param1> < / name> < / loop1> < / condition1> < / type> < / name> < / type> < / param1> < / name>

Claims

1. A cross-thread monitoring method for application performance, characterized in that: The method comprises: Executing a target application performance monitoring task, and dynamically detecting whether there is a cross-thread operation during the execution of the target application performance monitoring task; If the cross-thread operation exists, obtaining the parent-child relationship between the threads and determining whether there is a target parent thread that needs to wait for the child thread; If the target parent thread exists, a configuration update thread is created, and the transfer configuration parameters between the target parent thread and the child thread are modified by the configuration update thread, so that the target parent thread determines whether to transfer the tracking context to the child thread based on the transfer configuration parameters.

2. The method according to claim 1, characterized in that Before executing the step of executing the target application performance monitoring task, the method further includes: In response to a JavaAgent startup operation in a virtual machine, dynamically modifying the bytecode of a thread startup method and / or a thread running method in a preset thread core class, and adding dynamic detection execution logic to the execution logic of the thread startup method and / or the thread running method; The thread startup method or the thread running method is executed to dynamically detect the target application performance monitoring task to determine whether there is a cross-thread operation during the execution of the target application performance monitoring task.

3. The method according to claim 2, characterized in that The dynamic detection execution logic includes: cross-thread operation detection logic, the execution of the thread startup method or the thread running method, dynamic detection of the target application performance monitoring task, and determination of whether cross-thread operation occurs during the execution of the target application performance monitoring task, including: When the target application performance monitoring task is submitted, executing the cross-thread operation detection logic to obtain a task instance of the target application performance monitoring task; According to the task instance, it is determined whether the target application performance monitoring task has a cross-thread operation.

4. The method according to claim 1, wherein The method further comprises: If the cross-thread operation exists, triggering the asynchronous analysis process, wherein the asynchronous analysis process includes: Asynchronously uploading the class file corresponding to the target application performance monitoring task to the backend server, and the backend server using a decompilation tool to generate source code based on the class file; The middleware in the large language model intelligent component is called to analyze the source code, obtain the parent-child relationship between threads, and determine whether there is a target parent thread that needs to wait for the child thread.

5. The method according to claim 1, wherein The method further comprises: If the target parent thread exists, the target parent thread is associated with the target child thread that the target parent thread needs to wait for, and the configuration update thread is executed.

6. The method according to claim 1, characterized in that The step of enabling the target parent thread to determine whether to transfer the tracing context to the child thread based on the transfer configuration parameter includes: The configuration update thread is started to associate the target parent thread with the tracking context of the child thread when the parent thread task is executed next time.

7. The method according to claim 1, characterized in that The configuration update thread is configured as an asynchronous thread.

8. A cross-thread monitoring device for application performance, characterized in that: The device comprises: A detection module is used to execute a target application performance monitoring task and dynamically detect whether there is a cross-thread operation during the execution of the target application performance monitoring task; A thread analysis module is used to obtain the parent-child relationship between threads if the cross-thread operation exists, and to determine whether there is a target parent thread that needs to wait for the child thread; A configuration update module is used to create a configuration update thread if the target parent thread exists, and to modify the transfer configuration parameters between the target parent thread and the child thread through the configuration update thread, so that the target parent thread determines whether to transfer the tracking context to the child thread based on the transfer configuration parameters.

9. An electronic device, characterized in that: The electronic device comprises: a processor and a memory storing a program; wherein the program comprises instructions, which, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images