Call chain analysis method, system, device, storage medium and program product
By constructing a call graph through static analysis, integrating dynamic data collection and a large language model, the complexity of static-dynamic integration and the problem of asynchronous link recovery in call chain analysis are solved, generating an efficient and complete call chain with business semantics.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA MERCHANTS SECURITIES CO LTD
- Filing Date
- 2026-04-30
- Publication Date
- 2026-07-28
AI Technical Summary
Existing technologies for call chain analysis suffer from problems such as complex rules for merging static and dynamic data, difficulties in recovering asynchronous links, and a lack of business semantics, making it impossible to generate call chains that can be directly used for business analysis and visualization.
A static call graph is constructed using a static analysis strategy, combined with dynamic analysis to collect relevant runtime data, and a pre-trained large language model is used for link completion, link repair, and semantic optimization to output the fused call chain.
It achieves efficient integration of static and dynamic data, accurately completes missing call chains, repairs broken chains, and endows call chains with business semantics, generating high-quality call chains that can be directly used for business analysis and visualization.
Smart Images

Figure CN122470486A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of program call chain analysis technology, and in particular to call chain analysis methods, systems, devices, storage media, and program products. Background Technology
[0002] Program call chain analysis is a core method for system performance optimization and fault diagnosis, with current mainstream technologies being static analysis and dynamic analysis. These two technologies differ significantly in their underlying principles and application scenarios, and each also has unavoidable limitations.
[0003] Static analysis generates control flow graphs and call graphs by parsing source code or bytecode, which can cover potential paths, but it cannot accurately handle runtime logic such as reflection calls, dynamic proxies, configuration-driven methods, and runtime conditional branches. It has a high false positive rate and lacks business semantics, making it difficult to apply directly.
[0004] Dynamic analysis collects method calls, thread information, and call stacks through runtime instrumentation to generate actual execution chains. However, path coverage is limited, the false negative rate is high, the chain is prone to breakage in asynchronous and cross-thread scenarios, and the data noise is large, making it difficult to map business logic.
[0005] Current research attempts to integrate static graphs and dynamic links, but problems remain, such as complex merging rules, difficulties in recovering asynchronous links, and a lack of business semantics.
[0006] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention
[0007] The main purpose of this application is to provide a call chain analysis method, system, device, storage medium, and program product, which aims to solve the technical problems of complex dynamic and static fusion analysis merging rules, difficulty in asynchronous link recovery, and lack of business semantics in the prior art.
[0008] To achieve the above objectives, this application proposes a call chain analysis method, which includes: The target program is analyzed using a static analysis strategy to construct a static call graph; By employing dynamic analysis strategies, runtime-related data is collected during the execution of the target program, generating dynamic link data. Combining the static call graph and the dynamic link data, a pre-trained large language model is used to perform link completion, link repair, and semantic optimization, outputting a fused call chain.
[0009] In one embodiment, the step of parsing the target program and constructing a static call graph using a static analysis strategy includes: The source code or bytecode of the target program is parsed to generate parsing results, which include one or more of the following: method call edges, class information, method parameter types, return types, and call confidence. Based on the analysis results, a static call graph covering the potential execution paths of the target program is constructed.
[0010] In one embodiment, the step of collecting runtime-related data during the execution of the target program using a dynamic analysis strategy to generate dynamic link data includes: Collect method call information of the target program during its execution. The method call information includes one or more of the following: method entry point, method exit point, timestamp, thread information, and call context. Context propagation is performed on asynchronous tasks, thread pools, message queues, and time-driven chains to obtain the processing results; Based on the method call information and the processing result, dynamic link data of the actual execution of the target program is generated.
[0011] In one embodiment, the step of combining the static call graph and the dynamic link data, performing link completion, link repair, and semantic optimization processing through a pre-trained large language model, and outputting the fused call chain includes: Align the static call graph and the dynamic link data; Based on the aligned static call graph and dynamic link data, noise filtering, missing edge completion, cross-thread link recovery and semantic reduction are performed by a pre-trained large language model to obtain pre-processed link data. The preprocessed link data is subjected to consistency verification to obtain the fused call chain.
[0012] In one embodiment, the step of obtaining preprocessed link data by performing missing edge completion, cross-thread link recovery, and semantic reduction processing through a pre-trained large language model based on the aligned static call graph and dynamic link data includes: Based on the aligned static call graph, dynamic link data, and the class meta information, method comments, and code context of the target program, input data is formed and then input into the pre-trained large language model. The input data is filtered for noise using the pre-trained large language model to remove data from the framework layer and proxy layer methods, thus obtaining the first processed data. Using the pre-trained large language model, inference reflection, proxy, asynchronous tasks and event-driven invocation are performed based on the input data to obtain the second processed data; Using the pre-trained large language model, cross-thread link recovery is performed based on the input data to restore broken links in asynchronous and thread switching scenarios, and obtain third-processed data. Using the pre-trained large language model, the link nodes are aggregated into business methods based on the input data to obtain the fourth processing data; The first processed data, the second processed data, the third processed data, and the fourth processed data are integrated to obtain the preprocessed link data.
[0013] In one embodiment, after the step of combining the static call graph and the dynamic link data, performing link completion, link repair, and semantic optimization processing through a pre-trained large language model, and outputting the fused call chain, the method includes: Based on the fused call chain, a semantic call chain diagram and a corresponding analysis report are generated.
[0014] Furthermore, to achieve the above objectives, this application also proposes a call chain analysis system, which includes: The static analysis module is used to parse the target program and construct a static call graph using static analysis strategies. The dynamic analysis module is used to collect runtime-related data during the execution of the target program through dynamic analysis strategies and generate dynamic link data. The fusion processing module is used to combine the static call graph and the dynamic link data, and perform link completion, link repair and semantic optimization processing through a pre-trained large language model to output the fused call chain.
[0015] In addition, to achieve the above objectives, this application also proposes a call chain analysis device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the call chain analysis method as described above.
[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the call chain analysis method described above.
[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the call chain analysis method described above.
[0018] This application proposes a call chain analysis method, system, device, storage medium, and program product. The method includes: parsing the target program using a static analysis strategy to construct a static call graph; collecting runtime-related data during the target program's execution using a dynamic analysis strategy to generate dynamic link data; combining the static call graph and dynamic link data, performing link completion, link repair, and semantic optimization processing using a pre-trained large language model, and outputting a fused call chain. This solution replaces complex manual merging rules with a pre-trained large language model, simplifying the static-dynamic fusion process and reducing fusion difficulty; simultaneously, leveraging the reasoning capabilities of the large language model, it achieves missing edge completion in scenarios such as reflection and proxy, and link recovery in asynchronous and cross-thread scenarios, solving the link breakage problem; and through semantic optimization processing, it aggregates link nodes into business methods, endowing the call chain with business semantics, ultimately achieving high efficiency, completeness, and business relevance in call chain analysis. Attached Figure Description
[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 This is a flowchart illustrating the call chain analysis method of this application in Embodiment 1. Figure 2 This is a flowchart illustrating Embodiment 2 of the call chain analysis method of this application; Figure 3 This is a system functional module architecture diagram of the call chain analysis method provided in Embodiment 1 of this application; Figure 4 A simplified flowchart of the call chain analysis method provided in Embodiment 1 of this application; Figure 5 This is a schematic diagram of the module structure of the call chain analysis system in an embodiment of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the call chain analysis method in this application embodiment.
[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation
[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.
[0024] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.
[0025] The main solution of this application embodiment is as follows: the target program is parsed and a static call graph is constructed through a static analysis strategy; the running-related data during the running process of the target program is collected and dynamic link data is generated through a dynamic analysis strategy; the static call graph and dynamic link data are combined and the link completion, link repair and semantic optimization are performed through a pre-trained large language model, and the fused call chain is output.
[0026] In this embodiment, for ease of description, the following description will take the call chain analysis system as the execution subject.
[0027] Existing technologies suffer from several core defects: static analysis generates too many false positives and cannot accurately reflect the business call chain; dynamic analysis has incomplete coverage and is prone to link breakage in asynchronous, thread switching, and event-driven scenarios; static and dynamic analysis are difficult to integrate effectively and lack a unified semantic representation; reflection and proxy calls caused by complex frameworks are difficult to complete, and there is a lack of methods for cross-thread call chain recovery and business semantic reduction. As a result, existing methods cannot generate call chains that can be directly used for business analysis and visualization, and it is difficult to meet the actual needs of system performance optimization, fault diagnosis, and business analysis.
[0028] This application provides a solution comprising: parsing a target program using a static analysis strategy to construct a static call graph; collecting runtime-related data during the target program's execution using a dynamic analysis strategy to generate dynamic link data; combining the static call graph and the dynamic link data, performing link completion, link repair, and semantic optimization processing using a pre-trained large language model to output a fused call chain. This solution effectively reduces the false alarm rate of static analysis, compensates for the coverage defects of dynamic analysis, solves the link breakage problem in asynchronous and cross-thread scenarios, achieves efficient fusion and unified semantic representation of static and dynamic analysis, completes reflection and proxy call links, completes cross-thread link recovery and business semantic reduction, and finally generates a call chain that can be directly used for business analysis and visualization. This solution comprehensively solves the core problems in existing technologies and improves the accuracy, completeness, and practicality of call chain analysis.
[0029] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of performing the above functions. The following description uses a personal computer as an example to illustrate this embodiment and the subsequent embodiments.
[0030] Based on this, embodiments of this application provide a call chain analysis method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the call chain analysis method of this application.
[0031] In this embodiment, the call chain analysis method includes steps S10 to S30: Step S10: The target program is parsed using a static analysis strategy to construct a static call graph; It should be noted that a static call graph is a graphical model constructed based on the source code or bytecode of the target program through syntax parsing and semantic abstraction. It is used to describe the potential call relationships between various types and methods in the program and includes all theoretically executable call paths in the program.
[0032] Understandably, since existing static analysis techniques can only simply parse the code structure and cannot filter effective call paths in conjunction with business logic, they are prone to generating a large amount of redundant call information. Therefore, step S10 is executed to parse the target program through a systematic static analysis strategy, which avoids the problem of redundant and invalid static call graphs caused by incomplete or inaccurate parsing. This provides comprehensive and reliable basic data support for subsequent static and dynamic fusion and reduces the complexity of subsequent fusion processing.
[0033] In one feasible embodiment, step S10 may include steps S11-S12: Step S11: Parse the source code or bytecode of the target program to generate a parsing result. The parsing result includes one or more of the following: method call edge, class information, method parameter type, return type, and call confidence. In this embodiment, the parsing process can adopt a combination of lexical analysis, syntax analysis, and semantic analysis. First, the source code or bytecode of the target program is lexically split to extract basic syntactic units such as classes, methods, and parameters. Then, an abstract syntax tree is constructed through syntax analysis. Finally, the calling relationships between classes and methods are mined through semantic analysis to generate parsing results containing key information such as method call edges, class information, method parameter types, return types, and call confidence.
[0034] Among them, the call confidence is used to characterize the reliability of the call relationship obtained by parsing. It can be quantitatively calculated based on factors such as code syntax correlation and call frequency, and provides a reference for subsequent link completion and consistency verification.
[0035] Step S12: Based on the parsing results, construct a static call graph that covers the potential execution paths of the target program.
[0036] In this embodiment, the method call edges in the parsing results are used as the core relationships, and class information, method parameter types, and return types are used as supplementary attributes. The parsed classes and methods are used as nodes in the static call graph, and the method call relationships are used as edges between nodes. Valid call relationships are filtered by combining call confidence to construct a static call graph that covers all potential execution paths of the target program. At the same time, ambiguous call relationships (such as calls to undefined interface implementations) found during the parsing process are marked to provide a basis for subsequent completion by combining dynamic link data and large language models.
[0037] Through the above steps, a systematic and accurate construction of the static call graph is achieved. This ensures that the static call graph fully covers the potential execution paths of the target program. Furthermore, by refining the parsing results and introducing call confidence, the reliability and practicality of the static call graph are improved. This effectively solves the problems of excessive false alarms and inaccurate reflection of business call chains in existing static analysis, laying a solid foundation for subsequent integration with dynamic link data and subsequent processing steps.
[0038] Step S20: Through dynamic analysis strategy, collect operation-related data during the execution of the target program and generate dynamic link data; It should be noted that dynamic link data refers to the actual running state of the target program, which is a set of relevant data obtained through runtime acquisition methods to describe the actual execution path of the program. It records information such as the actual method call order, thread changes and execution context that occur during program execution. It is the core data that reflects the actual running status of the program and complements the static call graph.
[0039] Understandably, existing dynamic analysis technologies are prone to issues such as lost call context and broken links in asynchronous, context-switching, and event-driven scenarios. Furthermore, the collected data often contains a large amount of redundant noise from large frameworks and proxy layers, making it difficult to accurately reflect the business execution link. Therefore, step S20, through a systematic collection and processing flow, achieves accurate collection and optimization of the target program's runtime data. This avoids problems such as broken dynamic links and invalid data caused by incomplete data collection and lost context, thereby providing real, complete, and reliable dynamic data support for subsequent integration with the static call graph.
[0040] In one feasible embodiment, step S20 may include steps S21 to S23: Step S21: Collect method call information of the target program during its operation. The method call information includes one or more of the following: method entry point, method exit point, timestamp, thread information, and call context. In this embodiment, a dynamic analysis module in the form of a JVM Agent is used to perform the data collection operation. By using runtime instrumentation technology, the data collection logic is injected when the target program starts. During the data collection process, the execution status of each method in the target program is captured in real time, and the time nodes of the method entry and exit points, the identifier and status of the current execution thread, and the context information of the method call (such as the relationship between the caller and the callee) are recorded. At the same time, the timing of each method call is aligned by combining the timestamp, so as to ensure that the collected method call information has timing and correlation, and to provide a foundation for the subsequent link construction.
[0041] Step S22: Perform context propagation processing on asynchronous tasks, thread pools, message queues, and time-driven chains to obtain the processing results; Meanwhile, for scenarios prone to chain breaks, such as asynchronous tasks, thread pools, message queues, and event-driven processes, a context pass-through mechanism is used to embed the context information of method calls (such as call chain identifiers, thread contexts, business identifiers, etc.) into asynchronous tasks, message bodies, or events, thereby enabling cross-thread and cross-component context passing.
[0042] For example, when executing asynchronous tasks in a thread pool, the call context information of the original thread is encapsulated and passed to the newly started thread. When sending a message in the message queue, the call context information is carried in the message header to ensure the continuity of the call chain in asynchronous scenarios and avoid chain breakage. This processing result provides a guarantee for the generation of a complete dynamic chain in the future.
[0043] Step S23: Based on the method call information and the processing result, generate dynamic link data of the actual execution of the target program.
[0044] In this embodiment, the collected method call information is sorted chronologically, and combined with the context propagation results, the scattered method call information is linked together according to the execution sequence and contextual relationships to construct a complete dynamic execution link. At the same time, the collected redundant data is initially screened, invalid duplicate call records are removed, and key execution link information is retained. Finally, dynamic link data that can accurately reflect the actual execution path of the target, including chronological relationships, thread information and contextual relationships, is generated, laying the foundation for subsequent alignment and fusion processing with the static call graph.
[0045] Through the above steps, non-intrusive and comprehensive collection and accurate processing of dynamic link data are achieved, effectively solving the problems of incomplete coverage of existing dynamic analysis and link breakage in asynchronous and cross-thread scenarios. At the same time, it reduces redundant data interference, improves the integrity and reliability of dynamic link data, complements the static call graph, and provides strong support for subsequent fusion processing through large language models and output of high-quality call chains.
[0046] Step S30: Combining the static call graph and the dynamic link data, perform link completion, link repair and semantic optimization processing through a pre-trained large language model, and output the fused call chain.
[0047] It should be noted that this large language model is trained using massive amounts of program code data, call chain sample data, business semantic annotation data, and dynamic and static fusion scenario data. Its internal structure includes an input layer, an encoding layer, an inference layer, and an output layer. The input layer receives static call graphs, dynamic link data, and auxiliary data related to the target program and performs format standardization processing. The encoding layer extracts features and performs semantic encoding on the input data. The inference layer performs inference operations based on the encoded features to complete, repair, and optimize the link. The output layer outputs a standardized and semantically fused call chain, possessing powerful code semantic understanding, call relationship inference, and link optimization capabilities.
[0048] Understandably, existing static and dynamic fusion analysis methods rely on manually designed complex merging rules, which cannot effectively handle complex call scenarios such as reflection and proxy, and are difficult to achieve cross-thread link recovery and business semantic reduction. This results in insufficient integrity and semantics of the fused call chain, making it unsuitable for direct business analysis. Therefore, step S30 is executed to replace manual merging rules with a pre-trained large language model to fuse static call graphs and dynamic link data. This avoids problems such as low fusion efficiency, inaccurate link completion, and semantic loss caused by cumbersome manual rule design and poor adaptability. As a result, efficient fusion of static and dynamic data is achieved, accurately completing missing call links, repairing broken links, and giving the call chain business semantics, thereby improving the accuracy, completeness, and practicality of the fused call chain.
[0049] In one feasible embodiment, step S30 may include steps S31 to S33: Step S31: Align the static call graph and the dynamic link data; In this embodiment, the alignment process uses the class and method information of the target program as the core benchmark. It associates and matches the method nodes and call edges in the static call graph with the method call records in the dynamic link data, establishing correspondences based on features such as method name, parameter type, return type, and call context. Potential call relationships that exist in the static call graph but not in the dynamic link data are marked as links to be completed. Call relationships that exist in the dynamic link data but are not parsed in the static call graph are marked as links to be verified. This ensures accurate alignment between static and dynamic data, providing a unified data foundation for subsequent fusion processing of large language models and avoiding deviations in fusion results due to data misalignment.
[0050] Step S32: Combining the aligned static call graph and dynamic link data, noise filtering, missing edge completion, cross-thread link recovery, and semantic reduction are performed using a pre-trained large language model to obtain pre-processed link data. Understandably, the aligned static call graph still contains redundant call information, and the dynamic link data contains noise from the framework layer and proxy layer. Furthermore, even after fusion, issues such as reflection, missing proxy calls, broken cross-thread links, and lack of business semantics still exist. Existing manual processing methods are inefficient and have poor adaptability, failing to meet the requirements for accurate fusion. Therefore, step S32 is executed to systematically process the aligned data using a pre-trained large language model. This avoids problems such as incomplete noise filtering, inaccurate link completion, missing semantics, and unrecoverable cross-thread links caused by cumbersome manual processing and insufficient reasoning capabilities. This achieves deep fusion and optimization of static and dynamic data, effectively compensating for the respective deficiencies of static and dynamic analysis, and providing high-quality and highly reliable preprocessed data support for subsequent consistency verification and the final output of the fused call chain.
[0051] In another embodiment, step S32 may further include steps a1 to a6: Step a1: Based on the aligned static call graph, dynamic link data, and the class meta information, method comments, and code context of the target program, input data is formed, and the input data is input into the pre-trained large language model; In this embodiment, the class meta information includes basic information such as the class structure, inheritance relationship, and interface implementation of the target program. Method comments and code context are used to assist the large language model in understanding business logic and calling scenarios. The above data is integrated with the aligned static call graph and dynamic link data, and the format is standardized to ensure the integrity and standardization of the input data. This enables the large language model to accurately capture call relationship features and business semantics, providing comprehensive input support for subsequent processing.
[0052] Step a2: The input data is filtered for noise using the pre-trained large language model to remove data from the framework layer and proxy layer methods, thus obtaining the first processed data. In this embodiment, the pre-trained large language model identifies and filters redundant information in the input data based on the framework layer and proxy layer method features learned during training. It focuses on removing noisy data such as framework calls and proxy calls that have no business significance, and only retains the core call information related to business logic to obtain the first processed data. This effectively reduces the amount of data for subsequent processing, improves the accuracy of link processing, and solves the problem of high noise in existing dynamic analysis data.
[0053] Step a3: Using the pre-trained large language model, perform inference reflection, proxy, asynchronous tasks and event-driven invocation based on the input data to obtain the second processed data; In this embodiment, a pre-trained large language model is combined with class meta information, code context, and potential call relationships in the static call graph of the input data. Through semantic reasoning capabilities, reflection calls, proxy calls, asynchronous task calls, and event-driven calls that were not parsed by static analysis or collected by dynamic analysis are inferred. The missing call edges in the static and dynamic data are filled in, and second-processed data containing complete call relationships is obtained. This effectively solves the technical problem that reflection and proxy calls are difficult to fill in under complex frameworks.
[0054] Step a4: Using the pre-trained large language model, cross-thread link recovery is performed based on the input data to restore broken links in asynchronous and thread switching scenarios, and obtain third-processed data. In this embodiment, a pre-trained large language model is used to combine thread information, call context, and context propagation processing results in the input data to identify link breakpoints in asynchronous tasks, thread pools, message queues, and event-driven scenarios. Through call relationship reasoning and context association, the broken link nodes are connected to restore the complete cross-thread call chain and obtain third-party processing data, thus completely solving the problem of link breakpoints in asynchronous, thread switching, and event-driven scenarios.
[0055] Step a5: Using the pre-trained large language model, the link nodes are aggregated into business methods based on the input data to obtain the fourth processing data; In this embodiment, a pre-trained large language model is used to combine method annotations, code context, and business semantic features in the input data to classify and aggregate scattered method nodes in the call chain. Method nodes that are functionally related and belong to the same business process are aggregated into business methods, and the call chain is given business semantics to obtain the fourth processing data. This solves the problem that the existing call chain lacks a unified semantic representation and cannot reflect business logic.
[0056] Step a6: Integrate the first processed data, the second processed data, the third processed data, and the fourth processed data to obtain the preprocessed link data.
[0057] In this embodiment, a time-series alignment and relational association approach is used to integrate the first processed data (denoised core data), the second processed data (completed call relationships), the third processed data (restored cross-thread links), and the fourth processed data (semantic aggregated data). This process eliminates data redundancy and contradictory information, ensuring that the integrated data has a coherent time sequence, clear call relationships, and explicit business semantics. Ultimately, high-quality preprocessed link data is obtained, providing a reliable foundation for consistency verification.
[0058] Step S33: Perform consistency verification on the preprocessed link data to obtain the fused call chain.
[0059] In this embodiment, the core of consistency verification is to verify the consistency between the static call graph and the relevant information in the dynamic link data in the preprocessed link data. The focus is on verifying the potential call relationships marked in the static call graph and the actual executed call relationships in the dynamic link data, the corresponding information of the statically parsed method parameter types / return types and the dynamically collected information, and the matching of the completed call edges with the actual business logic and context. Links with inconsistent static and dynamic information are accurately identified and marked. For the identified inconsistent links, the reasoning ability of the pre-trained large language model and the class meta-information and code context of the target program are combined.
[0060] If the inconsistency is caused by a false alarm from static analysis, the redundant call link is removed; if the inconsistency is caused by omissions or errors in dynamic data collection, it is corrected based on the inference results of the large language model; if the inconsistency is caused by dynamic changes in business logic, the actual execution information in the dynamic link data is retained and the reasons for the differences are marked to ensure that the verified link data conforms to both the static potential call logic and the actual running state of the program.
[0061] Through the above steps, a comprehensive consistency verification and optimization of the preprocessed link data is completed, effectively eliminating redundant and erroneous links with inconsistent static and dynamic information, correcting link deviations, and ensuring that the final output fused call chain has both the path comprehensiveness of the static call graph and the execution authenticity of the dynamic link data. At the same time, it has clear business semantics and complete cross-thread links, completely solving the problems of poor link consistency and insufficient accuracy after fusion in existing methods. Finally, a high-quality call chain that can be directly used for business analysis, fault diagnosis and visualization is generated, fully meeting the actual needs of system performance optimization and business analysis.
[0062] The above-described method uses a static analysis strategy to parse the target program and construct a static call graph. A dynamic analysis strategy collects runtime-related data during the target program's execution, generating dynamic link data. Combining the static call graph and dynamic link data, a pre-trained large language model is used for link completion, link repair, and semantic optimization, outputting a fused call chain. This solution replaces complex manual merging rules with a pre-trained large language model, simplifying the static-dynamic fusion process and reducing fusion difficulty. Simultaneously, leveraging the reasoning capabilities of the large language model, it achieves missing edge completion in scenarios such as reflection and proxy, and link recovery in asynchronous and cross-thread scenarios, solving the link breakage problem. Furthermore, through semantic optimization, link nodes are aggregated into business methods, endowing the call chain with business semantics, ultimately achieving high efficiency, completeness, and business relevance in call chain analysis.
[0063] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 After step S30, the call chain analysis method further includes step S301: Step S301: Based on the fused call chain, generate a semantic call chain diagram and a corresponding analysis report.
[0064] In this embodiment, based on the fused complete call chain, and combining the business semantics, call sequence, dependency relationships, and thread association information of the link nodes, a visual topology rendering is performed to generate a semantic call chain diagram with clear hierarchy, identifiable nodes, and explicit relationships. Simultaneously, relying on multi-dimensional indicators such as link integrity, abnormal call nodes, cross-thread interaction relationships, high-frequency dependent components, and invalid redundant calls, static analysis features, dynamic runtime data, and LLM semantic reduction results are integrated to form a standardized analysis report. The semantic call chain diagram can intuitively display the overall program call architecture and business flow path. The analysis report can quantitatively present link defects, performance risks, asynchronous interaction risks, and invalid call distribution, providing intuitive and actionable data support for subsequent system fault location, performance optimization, architecture analysis, and business process review.
[0065] The above-described embodiments and methods enable the visualization and structured analysis of the fusion call chain, addressing the shortcomings of existing technologies that struggle to directly produce business-readable and visually displayable call chains. This reduces the cost of manual analysis and enhances the practicality and applicability of call chain analysis results.
[0066] For example, to help understand the implementation flow of the call chain analysis method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 3 , Figure 3A system functional module architecture diagram for a call chain analysis method is provided, specifically: This system consists of five core functional modules that work together to automate the production and analysis of complete call chains. The static analysis module parses the source code or bytecode of the target program and constructs a static call graph; the dynamic analysis module collects dynamic link data such as method calls and thread contexts during actual program execution using a non-intrusive runtime instrumentation method.
[0067] The static analysis module and the dynamic analysis module synchronously transmit the generated static call graph and dynamic link data to the data acquisition and storage module, respectively, to complete the structured unified storage, index management and data preprocessing alignment, providing a reliable data foundation for subsequent fusion inference.
[0068] The aligned and stored static call graph, dynamic link data, and native call graph features output by the static analysis module are input into the fusion and LLM inference module. This module relies on the semantic understanding and reasoning capabilities of the pre-trained large language model to sequentially complete noise filtering, missing call edge completion, cross-thread asynchronous link recovery, business semantic reduction, and dynamic and static data consistency verification, resulting in a complete, accurate, and semantic fused call chain.
[0069] Finally, the complete call chain after fusion processing is input into the visualization and reporting module, which renders an intuitive and readable semantic call chain topology diagram and generates a structured analysis report from multiple dimensions such as chain integrity, anomaly points, architectural dependencies, and performance risks, supporting the entire process of business architecture sorting, fault location, and system performance optimization.
[0070] The above architecture achieves a complementary advantage of static full coverage and dynamic authenticity. By replacing traditional manual hard-coded rules with LLM intelligent fusion, the automation, accuracy, and business implementation value of call chain analysis are greatly improved.
[0071] For example, to help understand the implementation flow of the call chain analysis method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 4 , Figure 4 A simplified flowchart of a call chain analysis method is provided, specifically: First, static analysis is performed to generate a static call graph and obtain all potential call paths of the program. Then, dynamic analysis is carried out to collect dynamic link data during the actual operation of the program.
[0072] Next comes the data alignment phase, where the static call graph and dynamic link data are matched one-to-one using method IDs, class information, and context. After alignment, the static call graph, dynamic link data, and code context information are input into the large language model for LLM inference processing.
[0073] LLM inference processing synchronous execution has five core processing capabilities: First, noise filtering, eliminating redundant and invalid links in the framework layer and proxy layer; second, missing edge completion, intelligently completing missing call relationships in reflection, proxy, and asynchronous task scenarios; third, cross-thread link recovery, repairing broken call links in asynchronous, thread switching, and event-driven scenarios; fourth, semantic reduction, completing the aggregation of business methods of link nodes and giving the link business semantics; and fifth, consistency verification, verifying links where static and dynamic data contradict or are inconsistent.
[0074] After verification and correction are completed, the merged complete call chain is output, and finally, a corresponding analysis report is generated based on the complete call chain until the process ends.
[0075] The above process, through the fusion of deep alignment of static and dynamic data with intelligent reasoning of large language models, avoids the drawbacks of traditional manual rules, such as high complexity, incomplete links, and lack of business semantics. It efficiently outputs complete, accurate, and business-readable call chains, adapting to the end-to-end analysis needs of complex distributed business scenarios.
[0076] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the call chain analysis method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.
[0077] This application also provides a call chain analysis system; please refer to [link / reference]. Figure 5 The call chain analysis system includes: Static analysis module 10 is used to parse the target program and construct a static call graph through static analysis strategies. The dynamic analysis module 20 is used to collect runtime-related data during the execution of the target program through dynamic analysis strategies and generate dynamic link data. The fusion processing module 30 is used to combine the static call graph and the dynamic link data, and perform link completion, link repair and semantic optimization processing through a pre-trained large language model to output the fused call chain.
[0078] The call chain analysis system provided in this application, employing the call chain analysis method described in the above embodiments, can solve the technical problems in the prior art, such as complex dynamic and static fusion analysis merging rules, difficulty in asynchronous link recovery, and lack of business semantics. Compared with the prior art, the beneficial effects of the call chain analysis system provided in this application are the same as those of the call chain analysis method provided in the above embodiments, and other technical features of the call chain analysis system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.
[0079] This application provides a call chain analysis device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the call chain analysis method in Embodiment 1 above.
[0080] The following is for reference. Figure 6 The diagram illustrates a structural schematic of a call chain analysis device suitable for implementing embodiments of this application. The call chain analysis device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and fixed terminals such as digital TVs and desktop computers. Figure 6 The call chain analysis device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.
[0081] like Figure 6 As shown, the call chain analysis device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the call chain analysis device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the call chain analysis device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows call chain analysis devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.
[0082] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.
[0083] The call chain analysis device provided in this application, employing the call chain analysis method in the above embodiments, can solve the technical problems in the prior art such as complex dynamic and static fusion analysis merging rules, difficulty in asynchronous link recovery, and lack of business semantics. Compared with the prior art, the beneficial effects of the call chain analysis device provided in this application are the same as those of the call chain analysis method provided in the above embodiments, and other technical features in this call chain analysis device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.
[0084] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.
[0085] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0086] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the call chain analysis method in the above embodiments.
[0087] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.
[0088] The aforementioned computer-readable storage medium may be included in the call chain analysis device; or it may exist independently and not assembled into the call chain analysis device.
[0089] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the call chain analysis device, the call chain analysis device: parses the target program and constructs a static call graph through a static analysis strategy; collects runtime-related data during the execution of the target program and generates dynamic link data through a dynamic analysis strategy; combines the static call graph and the dynamic link data, performs link completion, link repair, and semantic optimization processing through a pre-trained large language model, and outputs a fused call chain.
[0090] Computer program code for performing the operations of this application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, and C++, and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0091] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0092] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.
[0093] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described call chain analysis method. This solves the technical problems in the prior art, such as complex dynamic and static fusion analysis merging rules, difficulty in asynchronous link recovery, and lack of business semantics. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the call chain analysis method provided in the above embodiments, and will not be repeated here.
[0094] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the call chain analysis method described above.
[0095] The computer program product provided in this application can solve the technical problems of complex dynamic and static fusion analysis merging rules, difficulty in asynchronous link recovery, and lack of business semantics in the prior art. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the call chain analysis method provided in the above embodiments, and will not be repeated here.
[0096] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.
Claims
1. A call chain analysis method, characterized in that, The call chain analysis method includes: The target program is analyzed using a static analysis strategy to construct a static call graph; By employing dynamic analysis strategies, runtime-related data is collected during the execution of the target program, generating dynamic link data. Combining the static call graph and the dynamic link data, a pre-trained large language model is used to perform link completion, link repair, and semantic optimization, outputting a fused call chain.
2. The call chain analysis method as described in claim 1, characterized in that, The steps of parsing the target program and constructing a static call graph using a static analysis strategy include: The source code or bytecode of the target program is parsed to generate parsing results, which include one or more of the following: method call edges, class information, method parameter types, return types, and call confidence. Based on the analysis results, a static call graph covering the potential execution paths of the target program is constructed.
3. The call chain analysis method as described in claim 1, characterized in that, The step of collecting runtime-related data during the execution of the target program and generating dynamic link data through dynamic analysis strategies includes: Collect method call information of the target program during its execution. The method call information includes one or more of the following: method entry point, method exit point, timestamp, thread information, and call context. Context propagation is performed on asynchronous tasks, thread pools, message queues, and time-driven chains to obtain the processing results; Based on the method call information and the processing result, dynamic link data of the actual execution of the target program is generated.
4. The call chain analysis method as described in claim 1, characterized in that, The steps of combining the static call graph and the dynamic link data, performing link completion, link repair, and semantic optimization using a pre-trained large language model, and outputting the fused call chain include: Align the static call graph and the dynamic link data; By combining the aligned static call graph and dynamic link data, noise filtering, missing edge completion, cross-thread link recovery and semantic reduction are performed using a pre-trained large language model to obtain pre-processed link data. The preprocessed link data is subjected to consistency verification to obtain the fused call chain.
5. The call chain analysis method as described in claim 4, characterized in that, The steps of combining the aligned static call graph and dynamic link data, and performing missing edge completion, cross-thread link recovery, and semantic reduction processing through a pre-trained large language model to obtain pre-processed link data include: Based on the aligned static call graph, dynamic link data, and the class meta information, method comments, and code context of the target program, input data is formed and then input into the pre-trained large language model. The input data is filtered for noise using the pre-trained large language model to remove data from the framework layer and proxy layer methods, thus obtaining the first processed data. Using the pre-trained large language model, inference reflection, proxy, asynchronous tasks and event-driven invocation are performed based on the input data to obtain the second processed data; Using the pre-trained large language model, cross-thread link recovery is performed based on the input data to restore broken links in asynchronous and thread switching scenarios, and obtain third-processed data. Using the pre-trained large language model, the link nodes are aggregated into business methods based on the input data to obtain the fourth processing data; The first processed data, the second processed data, the third processed data, and the fourth processed data are integrated to obtain the preprocessed link data.
6. The call chain analysis method as described in claim 1, characterized in that, After the step of combining the static call graph and the dynamic link data, performing link completion, link repair, and semantic optimization processing through a pre-trained large language model, and outputting the fused call chain, the following steps are included: Based on the fused call chain, a semantic call chain diagram and a corresponding analysis report are generated.
7. A call chain analysis system, characterized in that, The call chain analysis system includes: The static analysis module is used to parse the target program and construct a static call graph using static analysis strategies. The dynamic analysis module is used to collect runtime-related data during the execution of the target program through dynamic analysis strategies and generate dynamic link data. The fusion processing module is used to combine the static call graph and the dynamic link data, and perform link completion, link repair and semantic optimization processing through a pre-trained large language model to output the fused call chain.
8. A call chain analysis device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the call chain analysis method as described in any one of claims 1 to 6.
9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the call chain analysis method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the call chain analysis method as described in any one of claims 1 to 6.