Code analysis method and platform based on static and dynamic analysis combination

Abstract

The invention relates to a code analysis method and platform based on combination of static analysis and dynamic analysis, and belongs to the technical field of code detection.The method comprises the steps that a trigger signal is obtained, source codes of a target project are analyzed through a preset static code analysis tool, and all methods defined in the target project are extracted; constructing a full-amount method set; collecting all executed methods in the running process of the target service by using a preset running process analysis tool when the life cycle of the target service instance in the production environment is ended and before the running process is ended, so as to form a running method set; and carrying out difference set calculation on the full-quantity method set and the running method set to obtain a non-running method set, and generating and feeding back an analysis result with the non-running method set for a manager to know. The method and the device have the effect of realizing high-precision identification of the code running state.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of code detection, in particular to a code analysis method and platform based on static and dynamic analysis combination. BACKGROUND

[0002] In the field of software engineering and code quality management, with business iteration and system evolution, the amount of application code expands rapidly, and a large amount of unused or redundant methods are often accumulated in the system. These codes not only increase the complexity of code maintenance, but also lead to problems such as prolonged compilation time, increased deployment package size, and waste of runtime metadata space. In this regard, although there are currently corresponding code analysis methods based on static and dynamic analysis combination in the industry, such as static code analysis methods based on static and dynamic analysis combination (for example, code scanning functions integrated with integrated development environments or open source tools such as SonarQube), which can parse the abstract syntax tree of source code to discover potential defects and code smells, but such methods cannot know the actual running situation in the production environment, and therefore cannot accurately determine the calling situation of any method, so there is room for improvement. SUMMARY

[0003] In order to achieve high-precision identification of code running state, the present application provides a code analysis method and platform based on static and dynamic analysis combination.

[0004] In the first aspect, the present application provides a code analysis method based on static and dynamic analysis combination, which adopts the following technical solution: A trigger signal is obtained, a preset static code analysis tool is used to parse the source code of a target project, and all methods defined in the target project are extracted to construct a full method set; A preset running process analysis tool is used to collect all methods that have been executed in the running process of the target service at the end of the life cycle of the target service instance in the production environment and before the running process is terminated, to form a running method set; The full method set and the running method set are calculated by difference set to obtain a non-running method set, and an analysis result with the non-running method set is generated and fed back for management personnel to know.

[0005] By adopting the technical scheme, firstly, the full-quantity method is acquired through static analysis, ensuring the completeness of the basic code coverage; the dynamic collection is performed at the end of the instance lifecycle, the runtime data is directly read, and the high precision of the running method information is ensured. At the same time, because the collection is performed in the empty window period when the service instance has removed the traffic and is about to be destroyed, any influence on the online business performance (such as STW) and stability (such as code invasiveness) is completely avoided. This is a fundamental breakthrough to the inherent defects of the traditional technologies such as AOP, Java Agent, SA, etc. in the background technology. Secondly, the method is no longer isolated and one-time collection, but a repeatable process combined with the lifecycle of the service instance. Finally, the analysis result with the set of non-running methods is generated and fed back, so that the management personnel can continuously and accurately master the code health status, and provide direct and reliable data support for cleaning redundant code, optimizing system architecture and reducing maintenance cost. By accurately identifying the non-running code, the management personnel can selectively remove the non-running code, thereby improving the compilation speed, reducing the deployment package size, saving the runtime metadata space, and finally optimizing the resource utilization efficiency of the entire software system.

[0006] Optionally, the generating and feeding back the analysis result with the set of non-running methods comprises: performing static analysis on each non-running method in the set of running methods to construct the calling dependency relationship between the non-running method and other methods in the full-quantity method set; assigning a risk label to each non-running method based on the calling dependency relationship, the risk label being used to represent the influence degree of deleting the corresponding non-running method on all methods in the full-quantity method set; wherein the non-running method contained in the analysis result is provided with the corresponding risk label.

[0007] By adopting the technical scheme, the potential influence of deleting the non-running method on the code library is quantified, an explicit priority and risk warning is provided for the code cleaning operation, and systematic errors caused by deleting methods with underlying dependency relationships are effectively avoided; the non-running methods are classified based on the risk level, so that the developer can preferentially process the methods without dependency or with low dependency, thereby reducing the complexity of the code library with higher efficiency and reducing the resource consumption of compilation and deployment. Data support is provided for the structured analysis and systematic optimization of the code library, which helps to continuously maintain the clarity and manageability of the code structure.

[0008] Optionally, the method further comprises: acquiring the runtime scenario features of the target service instance, the runtime scenario features being obtained by collecting the context information associated with the execution of the running process of the target service instance; The preset expected functional scenario corresponding to each non-running method in the non-running set is matched and analyzed with the runtime scenario features; If there is a target non-running method that satisfies the following conditions: the expected functional scenario of the target non-running method does not match the runtime scenario characteristics, but the target non-running method has potential value, then the target non-running method is identified as a scenario-specific method, the scenario-specific method is migrated to a preset independent code archive library for storage, and an archive method index is established for the scenario-specific method so that the corresponding scenario-specific method can be called and executed.

[0009] By adopting the above technical solutions and using correlation analysis to examine the expected functionality and actual system operation scenarios, the reasons why code was not invoked at the business logic level were revealed, overcoming the limitations of analysis that only focuses on the code level. For code with potential value but incompatible with current mainstream operating scenarios, a management strategy between direct deletion and retention in the main codebase is provided, achieving standardized archiving and traceable management of code assets. By isolating and archiving scenario-specific code, redundancy and cognitive load in the main codebase are reduced, while ensuring that relevant functions can be quickly located and restored when business scenarios change, thus improving the architecture's ability to adapt to business changes.

[0010] Optionally, the method further includes: Perform code similarity analysis on all methods in the full method set of all target projects, including the scenario-specific methods described above; Methods with code similarity higher than a preset threshold are clustered into a method cluster; Generate a baseline template method for each method family, wherein the baseline template method contains the common core logic of all methods in the method family; For each specific method in the method family, store the differences between the specific method and the baseline template method corresponding to the method family; When it is necessary to call and execute any specific method in any method family, the corresponding base template method is loaded and the corresponding differentiated modification points are applied to synthesize the complete logic of the corresponding specific method before execution.

[0011] By adopting the above technical solution, and identifying and aggregating highly similar methodological logic, a "baseline template + differentiated incremental" storage model is used to replace the storage of multiple independent codebases. This fundamentally reduces code duplication and saves storage resources. Converging common logic into a unified baseline template ensures the consistency of core business logic, avoids potential inconsistencies caused by code copying and pasting, and focuses subsequent maintenance and updates on a single template, reducing the complexity and cost of long-term maintenance. It provides efficient runtime synthesis and execution capabilities for archived code assets, transforming them from static storage states into dynamic logical units that can be invoked at any time, greatly improving the convenience and efficiency of code asset reuse.

[0012] Optionally, the method further includes: For each method in the full set of methods, construct a multidimensional vector. The features contained in the multidimensional vector include at least: a call activity decay index calculated based on historical call data and a code structure importance score calculated based on call relationships. The multidimensional vector of each method is input into a preset code value prediction model, and the code value prediction model outputs the obsolescence probability of the corresponding method. The obsolescence probability is used to characterize the possibility that the corresponding method will be obsolete in the future. The probability of the method being scrapped is fed back to the management personnel so that they are aware of it.

[0013] By adopting the above technical solution, and constructing a multi-dimensional vector and utilizing a code value prediction model, the likelihood of each method being deprecated in the future is quantitatively assessed. This elevates code analysis from statistical analysis of past states to prediction of future trends, providing a data foundation for proactive code governance. By comprehensively considering the invocation activity of methods and the importance of code structure, the evaluation results no longer rely on a single dimension or human experience, but are based on multi-dimensional, quantitative data. This makes the judgment of code value more objective and accurate, reducing the risk of misjudgment. Furthermore, the provided deprecation probability provides managers with direct and clear quantitative evidence to identify low-value, high-deprecation-risk code, making the prioritization of code cleanup and resource investment more scientific and efficient.

[0014] Optionally, the method of feeding back the obsolescence probability to the manager for the manager's knowledge includes: For methods with a higher probability of being scrapped than a preset probability value, the contribution of each feature in the multidimensional vector of the corresponding method to the scrapping probability is calculated, and an explanation is generated based on the contribution. The explanation is used to characterize the reason for the high scrapping probability. Methods with a higher probability of being discarded than the preset probability value, along with their corresponding explanations, will be fed back to the management personnel for their information.

[0015] By adopting the above technical solution, and by providing explanations for methods with a high probability of obsolescence, the underlying data drivers behind the prediction results are revealed. This allows managers to understand the reasons behind the model's judgments, thereby increasing newcomers to the automated decision-making system and making the decision-making process more transparent. This solution can automatically locate and explain why a method is judged to have a high risk of obsolescence, effectively improving the depth and efficiency of code analysis. Furthermore, by providing explanations along with the high-obsolescence-probability methods, it can quickly guide managers to focus on the most critical issues and core reasons, avoiding blindly searching through massive amounts of code, thus significantly improving the efficiency of code review and decision-making.

[0016] Optionally, the method further includes: For each unrunnated method, acquire corresponding key data, including at least scenario matching results, risk tags, and abandonment probability; based on the acquired key data, and following a preset logical judgment process, generate a final strategy for the unrunnated method; wherein the analysis results include the final strategy for each unrunnated method; the final strategy includes at least: a suggestion to delete and a suggestion for manual review.

[0017] By adopting the above technical solution, this approach integrates diverse information such as scenario matching, risk tags, and obsolescence probability to automatically generate clear processing strategies (such as "recommend deletion" or "recommend manual review") for each non-running method. This frees managers from complex manual analysis and decision-making, automating the decision-making process. It enables code cleanup work to proceed systematically and according to priority, forming a closed loop from analysis to decision-making, significantly improving the collaborative efficiency and execution effectiveness of team code governance.

[0018] Secondly, this application provides a code analysis platform based on a combination of static and dynamic analysis, including, The full method collection module is used to acquire trigger signals, parse the source code of the target project using a preset static code analysis tool, and extract all methods defined in the target project to construct a full method collection. The execution method collection module is used to collect all the methods that have been executed in the execution process of the target service at the end of the life cycle of the target service instance in the production environment and before the execution process is terminated, in order to form an execution method set. The data comparison and analysis module is used to perform difference calculation between the full set of methods and the set of running methods to obtain the set of non-running methods, generate and return the analysis results containing the set of non-running methods for management personnel to know.

[0019] Thirdly, this application provides a code analysis apparatus, including a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any of the first aspects.

[0020] Fourthly, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described in any of the first aspects.

[0021] In summary, this application includes the following beneficial technical effects: In this application, firstly, full method data is obtained through static analysis, ensuring the completeness of basic code coverage. Secondly, dynamic data collection at the end of the instance's lifecycle directly reads runtime data, guaranteeing extremely high accuracy of runtime method information. Furthermore, by selecting a window of opportunity—when service instances have been de-trapped and are about to be destroyed—collection completely avoids any impact on online business performance (such as STW) and stability (such as code intrusion). Finally, the generated and fed-back analysis results enable administrators to continuously and accurately monitor code health, providing direct and reliable data support for cleaning up redundant code, optimizing system architecture, and reducing maintenance costs. By accurately identifying non-running code, administrators can selectively remove it, thereby improving compilation speed, reducing deployment package size, saving runtime metadata space, and ultimately optimizing the resource utilization efficiency of the entire software system. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart illustrating the code analysis method based on a combination of static and dynamic analysis disclosed in an embodiment of this application.

[0024] Figure 2 This is a structural block diagram of the code analysis platform based on the combination of static and dynamic analysis disclosed in the embodiments of this application.

[0025] Figure labeling: 201, Full data acquisition module; 202, Running data acquisition module; 203, Data comparison and analysis module. Detailed Implementation

[0026] The following is in conjunction with the appendix Figures 1-2 This application will be described in further detail.

[0027] This application discloses a code analysis method based on a combination of static and dynamic analysis (hereinafter referred to as the code analysis method), the execution subject of which is a code analysis platform based on a combination of static and dynamic analysis (hereinafter referred to as the code analysis platform). The following will describe the method in conjunction with the attached... Figure 1 This section details the specific steps involved in executing code analysis methods on a code analysis platform.

[0028] S101: Obtain the trigger signal, use the preset static code analysis tool to parse the source code of the target project, extract all methods defined in the target project, and construct a full set of methods.

[0029] S102, using a preset runtime analysis tool, at the end of the lifecycle of the target service instance in the production environment and before the runtime process is terminated, collect all methods that have been executed in the runtime process of the target service to form a runtime method set.

[0030] S103 calculates the difference between the full set of methods and the set of methods in operation to obtain the set of methods not in operation, generates and feeds back the analysis results with the set of methods not in operation, so that managers can know them.

[0031] In implementation, when a developer's code is merged into the master branch, or when a trigger signal is generated at specified intervals (e.g., weekly), the code analysis platform initiates and executes the full method collection process (as described in S101) upon receiving the trigger signal. The full method collection process specifically includes the following steps: The code analysis platform calls the Spoon library to read the source code directory of the target software project (here, "project" refers to an independently compileable and deployable software unit containing the complete source code files, configuration files, and directory structure to be analyzed, such as the root directory of a Maven project or a Git repository). Spoon then parses the source code into an AST (Abstract Syntax Tree). The platform traverses the AST, identifies all method nodes, and extracts the unique target of each method (typically including: package name, class name, method name, and parameter types). For example: The `com.example.service.UserService.getUserById(Long)` method is used. Finally, the collection of all extracted methods (i.e., the full method collection) is stored in the `scanner_method_all` table in the database. This completes the full method collection process.

[0032] In addition, the code analysis platform is also used to trigger and execute the runtime method collection process (i.e., the content described in S102) whenever any service (hereinafter referred to as the target service) is taken offline or updated by the preset deployment management system (i.e., the old version is replaced by the new version). The runtime method collection process is carried out by the code analysis platform and the preset deployment management system working together, and specifically includes the following steps: The pre-defined deployment management system first removes the target service instance from the load balancer (such as a gateway) to ensure no new user requests arrive. Then, before terminating the JVM process of the target service instance, the system automatically executes a pre-defined data collection script (such as command_sa.sh). This script starts the Serviceability Agent (SA) tool, attaching it to the target service's JVM process and reading the method call count information recorded in the JVM memory. The code analysis platform filters out methods with a call count greater than 0, extracts their unique coordinates (including package name, class name, method name, and parameter types), and stores them in the scanner_method_run table in the database. This table records the set of methods that were called at least once during the current service run (hereinafter referred to as the running method set). After the SA tool disconnects from the JVM, the running method collection process ends. The deployment management system then continues with the subsequent standard service update process (e.g., terminating the old instance, starting the new instance, and reconnecting the new instance to the load balancer). It should be noted here that the default deployment management system refers to any system used to manage application deployment, release, scaling, etc., such as Kubernetes-based container orchestration systems, traditional Ansible / Jenkins deployment chains, cloud service provider deployment services, etc.

[0033] Once both the full set of methods and the set of executed methods have been stored in the corresponding database, a data comparison and analysis process (i.e., the content described in S103) will be executed. The data comparison and analysis process specifically includes the following steps: The database reads the full set of methods (Set A) from the `scanner_method_all` table and the set of executed methods (Set B) from the `scanner_method_run` table. Using set operations, the set of unexecuted methods is calculated: Unexecuted method set = Set A - Set B. This set of unexecuted methods is then stored in a pre-defined difference table (e.g., the `scanner_method_diff` table). It's important to note that to ensure accuracy, the code analysis platform executes the running method collection process multiple times (i.e., once every time a service is deployed offline). The union of the multiple collected running method sets is then taken. This ensures that any method executed in any running method collection process is retained. This solves the problem of missing subsequently executed methods during a single data run, significantly reducing the risk of accidental code deletion. Finally, the code analysis platform calculates analytical metrics based on the aforementioned data, such as method utilization (method utilization = number of methods running in the method set / number of methods in the full method set), and generates visual reports with these analytical metrics. It can also automatically filter all methods in the full method set based on preset deletion safety rules to exclude methods that, although not running during the monitoring period, are critical to the system. These rules include, but are not limited to: Retain program entry point methods (such as the main method); retain lifecycle callback methods marked with framework-specific annotations (such as @PostConstruct); retain contract methods defined in interfaces; retain abstract methods and overridden methods annotated with @Override; retain methods in the test code directory; retain methods discovered through static analysis that are referenced by reflection or JNI.

[0034] After filtering according to the above rules, a candidate list of methods to be deleted is obtained. The visualization report and the candidate list of methods to be deleted are then fed back to the administrators (such as developers) for their information.

[0035] Optionally, generating and feeding back the analysis results with the set of unrunn methods in S103 specifically includes the following steps: S1031, Perform static analysis on each non-running method in the set of running methods to construct the call dependencies between the non-running methods and other methods in the full set of methods; S1032, based on the call dependency relationship, assign a risk label to each non-running method. The risk label is used to characterize the degree of impact of deleting the corresponding non-running method on all methods in the full method set; wherein, the non-running methods included in the analysis results have corresponding risk labels.

[0036] In implementation, the code analysis platform also performs the following operations during the full method collection process: For each method body, by traversing its AST, it identifies other methods called within that method body (including method calls within the same class, method calls from other classes, etc.). These call relationships (e.g., method A → call → method B) are persistently stored in a graph database, or simply in a relation table. Ultimately, a global method call chain graph is formed, with all methods as nodes and call relationships as directed edges; this global method call chain graph is used to represent the call dependencies between all methods in the entire method set.

[0037] Furthermore, before outputting the aforementioned set of non-running methods, this application will traverse each non-running method in the set and query the adjacent nodes and connectivity of the non-running method in the global method call chain graph to determine whether the following situations occur. If they do, the corresponding risk label will be assigned (risk labels include low-risk, medium-risk, and high-risk labels): Scenario 1: If a non-running method is found, and it has neither incoming edges (not called by any method) nor outgoing edges (not calling any other methods) in the corresponding global method call chain graph, then this non-running method is an isolated node in the global method call chain graph, and is assigned a low-risk label.

[0038] Scenario 2: The query reveals that a non-running method has an incoming edge (called by other non-running methods), but no outgoing edges. If this exists, the non-running method is a leaf node in the global method call chain graph, and is therefore assigned a medium-risk label because it is the end point of a call chain.

[0039] Scenario 3: A query reveals that a non-running method has no incoming edges but outgoing edges (it calls other methods). If this exists, the non-running method is the root node in the global method call chain graph. Therefore, this non-running method is labeled as high-risk because deleting it would cause all methods it calls to become new non-running methods, potentially creating a chain reaction.

[0040] Add the risk labels corresponding to the non-running methods with risk labels to the non-running method set, and you can add a brief description, such as "This method is an isolated method and can be safely deleted" or "This method is the starting point of the call. Before deleting it, please confirm that its downstream functions X, Y, and Z are all deprecated". This will allow managers to use the risk labels as a reference to determine whether the corresponding non-running methods need to be deleted when they receive the analysis results.

[0041] Optionally, the code analysis method may also include the following steps: The runtime scenario characteristics of the target service instance are obtained by collecting the context information associated with the running process of the target service instance during execution. Match and analyze the preset expected functional scenarios and runtime scenario characteristics corresponding to each non-running method in the non-running set; If there is a target non-running method that satisfies the following conditions: the expected functional scenario of the target non-running method does not match the runtime scenario characteristics, but the target non-running method has potential value, then the target non-running method is identified as a scenario-specific method, the scenario-specific method is migrated to a pre-defined independent code archive for storage, and an archive method index is created for the scenario-specific method so that the corresponding scenario-specific method can be called and executed.

[0042] In implementation, this application further analyzes why unexecuted methods are not called, and performs intelligent archiving management of methods with potential value but mismatched scenarios. The specific implementation principles and steps are as follows: First, during the method collection process, while the SA tool collects the running methods, the code analysis platform simultaneously samples a portion of the request context information in a lightweight and non-intrusive manner. This can be achieved by integrating a lightweight APM Agent or utilizing the JVM's built-in MXBean. For the sampled requests, the platform captures their entry API path, key fields in the HTTP header (such as User-Agent identifying the client type and Referer identifying the source), and the currently logged-in user's role information. Ultimately, this yields a runtime scenario feature associated with the set of running methods (specifically manifested as one or more discrete, predefined scenario tags), such as: Traffic sources: "Mobile", "PC", "WeChat Mini Program", "API Gateway"; User types: "Internal Employees", "Regular Users", "VIP Users"; Business types: "Back-end management", "Front-end online store", "Data dashboard"; Triggering modes: "User request", "Scheduled task".

[0043] The code analysis platform also analyzes each non-running method to determine its expected functional scenario. Specifically, it analyzes the method name, class name, and package path of the non-running method, using pre-defined regular expressions or keyword matching to infer its expected functional scenario. For example, the `generateMonthlyReport` method located in the `com.x.service.report` package can be inferred to have the expected scenario of generating monthly reports. Furthermore, the expected scenarios for each method can be manually pre-annotated and stored. For instance, developers can define the expected functional scenario of a method in the code using specific, non-functional annotations (such as `@BusinessScenario("marketing campaign")`). In this case, the expected functional scenario of the non-running method can be determined by searching. Ultimately, each method is inferred to have one or more discrete, predefined scenario tags (i.e., the expected functional scenario includes one or more scenario tags), such as: {"report", "monthly"}.

[0044] The code analysis platform is used to match the expected functional scenarios of each non-running method with the runtime scenario characteristics corresponding to the target service instance. The specific matching rules are as follows: Based on a scenario relevance matrix pre-maintained by the code analysis platform (for example, it is defined that "marketing activities" are strongly correlated with "front-end e-commerce"; "marketing activities" are weakly correlated with "back-end management"; "marketing activities" are not correlated with "data maintenance"; and "reports" are strongly correlated with "data dashboards"), it iterates through each scenario tag contained in the expected functional scenario of each non-running method, and checks whether the runtime scenario features contain tags with strong correlation to the threshold. If they exist, the non-running method is considered to be a scenario match (i.e., a successful match), otherwise it is considered not to match (this indicates that the runtime environment of the service is not the design target of the method at all, and its non-running is logical).

[0045] For non-running methods deemed mismatched, the code analysis platform needs to further determine their potential value to avoid mistakenly deleting features that might be needed in the future. The criteria for determining potential value can be any of the following: 1. Calculate the cyclomatic complexity, lines of code, and similarity to other methods in the remaining codebase for the unrunned methods deemed mismatched. If the cyclomatic complexity is high (e.g., greater than 10) or the number of lines of code is large (e.g., greater than 50), and the similarity to other methods in the full method set is low (e.g., below a preset similarity threshold), then it is considered to implement non-trivial and unique business logic, possessing high potential value. Reimplementing it after deletion is costly.

[0046] 2. Static analysis determines whether the non-running methods that are deemed mismatched call external services, database-specific tables, message queues, etc. If a method contains any external dependencies, it is considered to have potential value because this means that it is not a purely computational function, but interacts with external systems and may need to be enabled in a specific workflow in the future.

[0047] 3. Check whether the non-running method that is judged to be mismatched has a calling dependency relationship with other methods in the archived library. If so, it is considered to have high potential value.

[0048] The code analysis platform defines non-running methods deemed mismatched but with high potential value as scenario-specific methods. For scenario-specific methods, the platform initiates an archiving process (i.e., migrating the source code of the scenario-specific method to an independent archiveGit repository and creating an archive method index in the metadata database, recording its unique identifier, path, functional scenario, and calling interface for future retrieval and execution). Specifically, by pre-integrating with version control systems such as Git, the entire class or file of the scenario-specific method is moved to an independent Git repository named archive (i.e., the code archive repository). A new record is added to the pre-maintained metadata database (such as a MySQL table) as the archive method index. The archive method index records the scenario-specific method's: unique identifier, original project path, path in the new archive repository, expected functional scenario description, and a standard calling interface specification (e.g., a RESTful API endpoint or a list of required parameters). This allows administrators or the code analysis platform to obtain the calling method by querying the corresponding archived method index when a scenario-specific method that has been included in the code archive needs to be called (for example, when a marketing campaign page needs to be temporarily generated). The method can then be deployed or loaded from the archive for execution.

[0049] Optionally, the code analysis method may also include the following steps: Perform code similarity analysis on all methods in the full method set of all target projects, including scenario-specific methods; Methods with code similarity higher than a preset threshold are clustered into a method cluster; Generate a baseline template method for each method family. The baseline template method contains the common core logic of all methods in the method family. For each specific method in a method family, store the differences between the specific method and the base template method corresponding to the method family; When it is necessary to call and execute any specific method in any method family, the corresponding base template method is loaded and the corresponding differentiated modification points are applied to synthesize the complete logic of the corresponding specific method before execution.

[0050] In implementation, this application also proposes to identify and reuse similar code across the entire set of methods for all target projects, including the scenario-specific methods, to improve code reusability. The specific implementation steps are as follows: The code analysis platform normalizes the code of all methods in the target project, including methods specific to the described scenario, by ignoring variable names, standardizing code format, folding spaces, and adding comments. Then, it calculates the hash value (e.g., SimHash) of the normalized code string or parses it into an Abstract Syntax Tree (AST). A feature vector reflecting the syntactic structure is generated by traversing the AST node sequence. Specifically, this feature vector is generated by performing a depth-first traversal of the AST, recording all visited node types to form a node type sequence. For example, for the code `if(a>b) { return a;}`, its AST node type sequence might be: `[IfStmt, BinaryExpr, Variable, Variable, Block, ReturnStmt, Variable]`. A predefined vocabulary containing all possible AST node types is used. For each method's node type sequence, the frequency of each node type is counted. Based on the order of the vocabulary, the frequency values ​​are arranged into a fixed-length numerical vector, which is the structural feature vector.

[0051] Next, method clusters can be generated by grouping based on hash values ​​(e.g., for methods based on SimHash hash values, methods with the same hash value are grouped into the same method cluster), or clustering algorithms (e.g., Jaccard similarity-based clustering) can be used to calculate the similarity between different vectors based on AST feature vectors (e.g., Jaccard similarity or cosine similarity), and methods with similarity higher than a preset threshold are grouped into the same method cluster. This generates one or more method clusters, and each method cluster contains a group of methods with highly similar implementation logic.

[0052] Next, for each method family, the code analysis platform identifies the identical parts in the AST of all methods, extracts these common logics, and solidifies them into a baseline template method. The variable parts in this baseline template method are replaced with placeholders or parameters. Then, for each specific method within the method family, the code analysis platform records the differences (i.e., the points of difference) between the AST of that specific method and the AST of the baseline template method. For example, the differences might be a different database table name, a different API URL, or a different conditional branch. These differences are serialized and stored in a configuration file (such as a JSON or XML file). Finally, each method family will have a baseline template method and the corresponding points of difference for each specific method (represented in the specific configuration file).

[0053] When an application needs to call a method belonging to any method family (indicating that the method has been templated), the call request will be captured by the corresponding pre-defined interceptor of the code analysis platform. The interceptor first loads the bytecode of the corresponding base template, then finds the corresponding differentiation configuration file based on the method's identifier (by default, each specific method has an identifier to distinguish it from other methods), and finally merges the bytecode with the configuration file of the differentiation modification points in memory (that is, using the differentiation modification points to replace the placeholders or parameters of the variable parts in the base template method, and by default, when the differentiation modification points are determined, the code analysis platform records the one-to-one correspondence between each differentiation modification point and the variable parts in the base template method so that different differentiation modification points can find the corresponding replacement positions), generating a complete, executable method logic (i.e., a complete specific method), and delivers it to the JVM for execution.

[0054] Optionally, the code analysis method may also include the following steps: For each method in the full set of methods, construct a multidimensional vector. The features contained in the multidimensional vector include at least: a call activity decay index calculated based on historical call data and a code structure importance score calculated based on call relationships.

[0055] The multidimensional vector of each method is input into a preset code value prediction model, which outputs the obsolescence probability of the corresponding method. The obsolescence probability is used to characterize the possibility that the corresponding method will be obsolete in the future.

[0056] For methods with a higher probability of being scrapped than a preset probability value, the contribution of each feature in the multidimensional vector of the corresponding method to the scrapping probability is calculated, and an explanation is generated based on the contribution. The explanation is used to characterize the reasons for the high scrapping probability.

[0057] Methods with a higher probability of being discarded than the preset probability value, along with their corresponding explanations, will be fed back to the management personnel for their information.

[0058] For each non-run method, acquire the corresponding key data, which includes at least the scenario matching result, risk label, and abandonment probability. Based on the acquired key data, and following the preset logical judgment process, generate the final strategy for the non-run method. The analysis results include the final strategy for each non-run method. The final strategy includes at least: a suggestion to delete and a suggestion for manual review.

[0059] In practice, the code analysis platform is also used to construct a multidimensional vector containing the following four core features for each method in the full method set: Feature 1: Call Activity Decay Index. The specific calculation method is as follows: Based on historical data obtained from long-term, multiple-run method acquisition processes, the number of calls to each method in the full method set is calculated in the most recent N consecutive acquisition cycles (e.g., 4 cycles) (i.e., the execution period of the method acquisition process). Specifically, for methods determined not to be run in the latest acquisition cycle, the code analysis platform first locates the last acquisition cycle in historical data where this method was acquired with a number of calls (call count > 0) (referred to as T_last), and then extracts historical data from T_last backwards for M acquisition cycles (e.g., 12 acquisition cycles) as the analysis window. For methods in the latest acquisition cycle with a call count > 0, historical data from N acquisition cycles backwards is extracted as its corresponding analysis window. This facilitates obtaining the call count of each method in the full method set (i.e., the call count within the analysis window).

[0060] Next, for each method, within a defined analysis window (e.g., 12 periods backward from the last run, T_last), a chronological sequence of call counts is obtained: C = [c_1, c_2, c_3, ..., c_M]; where c_1 is the call count of the earliest period in the analysis window, and c_M is the call count of the latest period (T_last). M is the size of the analysis window (e.g., 12). The following calculation steps are performed using the Exponentially Weighted Moving Average (EWMA) algorithm (the core idea of ​​EWMA is to assign higher weights to recent data points, making them have a greater impact on the average and thus better reflect recent trends): Initialize a smoothing factor α (0 < α < 1), for example, α = 0.5. The larger the value of α, the higher the sensitivity to recent changes.

[0061] Starting from the first data point in sequence C, the EWMA value e_t at each time point is recursively calculated: e_t = α * c_t + (1-α) * e_{t-1} (for t from 2 to M). Where e_1 = c_1 (the first EWMA value equals the first actual value); e_2 = α * c_2 + (1-α) * e_1; e_3 = α * c_3 + (1-α) * e_2… Finally, a smoothed EWMA sequence E = [e_1, e_2, …, e_M] corresponding to the original call sequence C is obtained. This sequence filters out some random fluctuations and better reflects the inherent trend of the call volume.

[0062] Then, the code analysis platform quantifies the decay degree by analyzing the trend of the EWMA sequence E. Specifically, it uses time t (1, 2, ..., M) as the independent variable and the EWMA value e_t as the dependent variable, performing a univariate linear regression to fit a trend line. The slope β of this line directly represents the average rate of change of call activity. To eliminate the influence of differences in call magnitude between different methods, the slope β is divided by the initial value e_1 of the EWMA sequence to obtain a relative decay rate. The relative decay rate is negative and mapped to a positive exponent, with the corresponding calculation formula: Call Activity Decay Index = max(0, -β / e_1). If the trend is downward (β is negative), -β / e_1 will be positive, and the faster the decline, the larger the value. If the trend is stable or upward (β is zero or positive), the decay index will be 0 or a very small value. Finally, a non-negative call activity decay index is obtained. The higher the value of the call activity decay index, the more obvious the call activity decay trend of the method within the analysis window, indicating that it is being abandoned.

[0063] Feature 2: Code Structure Importance Score. Specifically, it's calculated by assigning a PageRank value to each method in the global method call chain graph, and using this value as the code structure importance score. The PageRank algorithm naturally identifies methods that occupy a central, pivotal position in the entire call network. A higher code structure importance score indicates that the method is more important in its code structure and is depended upon by many other methods.

[0064] Feature 3: External Dependency Identifier. The specific calculation method is as follows: check if the method body contains code that calls external services, databases, or message queues. If so, the external dependency identifier is 1; otherwise, it is 0. This is a Boolean feature, and methods with external dependencies are usually strongly related to business logic and therefore more valuable.

[0065] Feature 4: Modification History Activity. The specific calculation method is as follows: query the version control system (such as Git) and calculate the number of times the method has been modified in the past year; this is used as the modification history activity. Frequent modifications usually indicate that the method is in a high-activity zone or has design flaws, but it also proves its current importance.

[0066] Then, using the version control system's tags, each officially released version (e.g., V1.0, V1.1, V2.0) is treated as a key time node, such as V2.0, V2.1, V2.2, V3.0. The Nth version release date before the latest release (e.g., V2.0 release date) is taken as a historical time point, and a time window is determined: [V2.0 release date, V3.0 release date), which is used as the specified time period. For each method in the version corresponding to the historical time point (i.e., V2.0 in the previous example), its call activity decay index within the historical window [V1.0 release date, V2.0 release date], its code structure importance score and external dependency identifier in version V2.0, and its modification history activity before the historical time point are calculated to form a multi-dimensional vector; finally, the set of multi-dimensional vectors of all methods at the historical time point is obtained.

[0067] Then, query the historical data of all running method collection processes within the aforementioned defined time period (i.e., [V2.0 release date, V3.0 release date)). For a method that existed in version V2.0, if it was never called in any running method collection process within the specified time period ([V2.0 release date, V3.0 release date) - i.e., it does not exist in the union of all running method sets), then assign it a status label 0 (deprecated). If it was called at least once within the specified time period ([V2.0 release date, V3.0 release date) - i.e., assign it a status label 1 (active). This yields a set of training samples (multidimensional vectors, status labels) to be labeled. For example: ( [0.85, 0.1, 1, 2], 0 ) represents a method with features [0.85, 0.1, 1, 2] in V2.0, which was deprecated within the specified time period ([V2.0 release date, V3.0 release date)).

[0068] The aforementioned training samples are used to train a pre-defined lightweight logistic regression model. The multi-dimensional vectors from the training samples are taken as input. Internally, the logistic regression model learns a weight coefficient w_i for each feature x_i, and has a bias term b. The learning objective is to minimize the difference between the model's predictions and the true state labels. For a feature vector X = [x_1, x_2, x_3, x_4] of a training sample, the logistic regression model first calculates a weighted sum to obtain the linear combination value z: z = b + (w_1 * x_1) + (w_2 * x_2) + (w_3 * x_3) + (w_4 * x_4); where w_1, w_2, w_3, and w_4 are the pre-defined weights for features one, two, three, and four, respectively. The z value is then input into the Sigmoid function σ(z) = 1 / (1 + e^{-z}), which maps a real number z to the interval (0, 1). As z approaches positive infinity, the probability approaches 1; as z approaches negative infinity, the probability approaches 0; and when z = 0, the probability is 0.5. The output value of the Sigmoid function is the output of the logistic regression model, hereinafter referred to as the obsolescence probability (i.e., a probability value between 0 and 1. For example, a model output of 0.92 indicates that the model predicts that the method has a 92% probability of being obsolete). The trained logistic regression model is referred to as the code value prediction model. After training, each learned weight coefficient w_i represents the direction and strength of its corresponding feature x_i's contribution to the obsolescence probability. The sign of the weight (positive / negative) indicates whether the feature and the obsolescence probability are positive or negative. For example, if the value of w_1 (corresponding to the call activity decay index) is negative, it means that the larger the feature value (x_1), the smaller the calculated z value, and the higher the obsolescence probability obtained after mapping through the Sigmoid function. This conforms to the business logic that the higher the decay index, the more likely the code is to be obsolete. If w_2 (corresponding to the code structure importance score) is positive, it means that the larger the feature value (x_2), the larger the calculated z value, and the lower the final probability of obsolescence. This aligns with the business logic that higher importance makes obsolescence less likely. The absolute value of the weight represents the relative importance of the feature's influence; the larger the absolute value, the greater the influence.

[0069] Furthermore, for a method whose obsolescence probability is higher than a preset probability value, the code analysis platform will traverse the method's multidimensional vector and calculate the contribution score _i = w_i * x_i, where 1 ≤ i ≤ 4. When i = 1, contribution score _1 represents the contribution of the call activity decay index to the obsolescence probability. Similarly, contribution score _2 represents the contribution of the code structure importance score to the obsolescence probability, contribution score _3 represents the contribution of the external dependency identifier to the obsolescence probability, and contribution score _4 represents the contribution of the modification history activity to the obsolescence probability. Since w_i can be positive or negative, the value and sign of contribution score _i directly reflect whether the feature increases or decreases the obsolescence probability.

[0070] The code analysis platform ultimately obtains a contribution list, for example: [(Call activity decay index, -1.2), (Code structure importance, +0.3), ...]. Here, -1.2 indicates that the call activity decay index contributes -1.2 to the z-value. Since the smaller the z-value, the higher the probability, this feature significantly increases the probability of obsolescence.

[0071] Furthermore, the code analysis platform has a pre-defined feature-description mapping table. This table is used to sort the contribution list from largest to smallest absolute value and select the Top-K (e.g., the top two) features with the largest contributions. Based on the feature names and the sign of their contribution, corresponding descriptive fragments are obtained from the mapping table. Example of a feature-description mapping table: Feature: Call activity decay index, negative contribution → Descriptive fragment: "The number of calls shows a rapid downward trend." Feature: Code structure importance, positive contribution → Descriptive fragment: "However, its importance in the code structure is relatively low." Finally, all the descriptive fragments are assembled to obtain a complete, data-driven explanation. For example: "This method has a high probability of being obsolete, mainly because: the number of calls shows a rapid downward trend, and it has low importance in the code structure." Finally, the code analysis platform outputs the obsolescence probability of methods with an obsolescence probability higher than the preset probability value, along with corresponding explanations, for administrators to see, so that they can make adaptive adjustments to the code accordingly.

[0072] For each non-running method, the code analysis platform combines the aforementioned scheme to obtain the following key data corresponding to the non-running method: the probability of the non-running method being abandoned, the risk label of the non-running method (low risk / medium risk / high risk), the external dependency identifier of the non-running method (0 or 1), and the scenario matching result (match or non-match).

[0073] Then, combining the key data mentioned above, the following logical judgment process is executed to output the final strategy: First, determine if the scene matching result is a match. If yes, output the final strategy: "It is recommended to pay close attention (reason: possible missed sampling, needs to be verified)". If no (i.e., the scene matching result is a mismatch), further determine the probability of abandonment as follows: Scenario 1: If the probability of being discarded is greater than the first threshold (e.g., 0.7) and the risk label is low risk, then the final output strategy is: "Recommend deletion (reason: low value and small impact)". Scenario 2: If the probability of being scrapped is less than the second threshold (e.g., 0.5) and there is an external dependency, the final output strategy is: "Generate archive instruction (reason: there may be potential value)"; wherein, the generated archive instruction includes automatically creating an archive task to be executed for the non-running method that meets Scenario 2. After the archive task is approved by the management personnel, the code analysis platform will automatically start the archive process to execute the archive process for the non-running method. Scenario 3: If the risk label is high risk, the final strategy output will be: "It is recommended to pay close attention (reason: the impact is large and caution is required)". If it does not fall under any of the above situations (i.e., situation one, situation two, or situation three), the final output strategy is: "Manual review is recommended (reason: manual intervention is required)".

[0074] Finally, the final strategy corresponding to each unrunned method is added to the analysis results and output together, so that managers can know the corresponding final strategy.

[0075] This application also discloses a code analysis platform based on a combination of static and dynamic analysis. (See also...) Figure 2 ,include: The full method collection module 201 is used to acquire trigger signals, use preset static code analysis tools to parse the source code of the target project, extract all methods defined in the target project, and construct a full method collection. The execution method collection module 202 is used to collect all the methods that have been executed in the execution process of the target service at the end of the life cycle of the target service instance in the production environment and before the execution process is terminated, in order to form a set of execution methods. The data comparison and analysis module 203 is used to perform difference calculation between the full set of methods and the set of running methods to obtain the set of non-running methods, generate and return the analysis results with the set of non-running methods for management personnel to know.

[0076] Optionally, the data comparison and analysis module 203 is also used to perform static analysis on each non-running method in the set of running methods to construct the call dependency relationship between the non-running method and other methods in the full set of methods; based on the call dependency relationship, a risk label is assigned to each non-running method, and the risk label is used to characterize the degree of impact of deleting the corresponding non-running method on all methods in the full set of methods; wherein, the non-running methods included in the analysis results have corresponding risk labels.

[0077] Optionally, it also includes a scenario feature analysis and matching module, used to obtain the runtime scenario features of the target service instance. The runtime scenario features are obtained by collecting the context information associated with the running process of the target service instance during execution. The module matches and analyzes the preset expected functional scenario corresponding to each non-running method in the non-running set with the runtime scenario features. If there is a target non-running method that satisfies the condition that the expected functional scenario of the target non-running method does not match the runtime scenario features, but the target non-running method has potential value, then the target non-running method is identified as a scenario-specific method. The scenario-specific method is migrated to a preset independent code archive library for storage, and an archive method index is established for the scenario-specific method so that the corresponding scenario-specific method can be called and executed.

[0078] Optionally, it also includes a method clustering analysis module, used to perform code similarity analysis on methods in the full method set of all target projects, including scenario-specific methods; cluster methods with code similarity higher than a preset threshold into a method cluster; generate a baseline template method for each method cluster, the baseline template method containing the common core logic of all methods in the method cluster; for each specific method in the method cluster, store the differences between the specific method and the baseline template method corresponding to the method cluster; when it is necessary to call and execute any specific method in any method cluster, load the corresponding baseline template method and apply the corresponding differences to synthesize the complete logic of the corresponding specific method before execution.

[0079] Optionally, it also includes a deprecation probability analysis module, used to construct a multi-dimensional vector for each method in the full method set. The features contained in the multi-dimensional vector include at least: a call activity decay index calculated based on historical call data and a code structure importance score calculated based on call relationships. The multi-dimensional vector of each method is input into a preset code value prediction model, which outputs the deprecation probability of the corresponding method. The deprecation probability is used to characterize the possibility that the corresponding method will be deprecated in the future. The deprecation probability of the method is fed back to the management personnel for their information.

[0080] Optionally, the obsolescence probability analysis module is also used to calculate the contribution of each feature in the multidimensional vector of the corresponding method to the obsolescence probability for methods whose obsolescence probability is higher than the preset probability value, generate an explanation based on the contribution, and use the explanation to characterize the reason for the high obsolescence probability; and feed back the methods whose obsolescence probability is higher than the preset probability value and their corresponding explanations to the management personnel for their information.

[0081] Optionally, a final strategy generation module is also included, which is used to obtain corresponding key data for each non-running method. The key data includes at least scenario matching results, risk tags, and abandonment probability. Based on the obtained key data, a final strategy for the non-running method is generated according to a preset logical judgment process. The analysis results include the final strategy for each non-running method. The final strategy includes at least: a suggestion to delete and a suggestion for manual review.

[0082] This application also discloses a code analysis device based on a combination of static and dynamic analysis. The code analysis device based on a combination of static and dynamic analysis includes a memory and a processor. The memory stores a computer program that can be loaded and executed by the processor, as described above, based on a code analysis method based on a combination of static and dynamic analysis.

[0083] This application also discloses a computer-readable storage medium that stores a computer program that can be loaded and executed by a processor using the code analysis method based on the combination of static and dynamic analysis described above. The computer-readable storage medium includes, for example, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0084] It should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0085] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit the scope of protection of the application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on these embodiments, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

Claims

1. A code analysis method based on a combination of static and dynamic analysis, characterized in that, include: Once a trigger signal is obtained, the source code of the target project is parsed using a preset static code analysis tool to extract all methods defined in the target project in order to construct a complete set of methods. Using a pre-defined runtime analysis tool, at the end of the lifecycle of the target service instance in the production environment and before the runtime process is terminated, all methods that have been executed in the runtime process of the target service are collected to form a runtime method set. The set of non-run methods is obtained by performing a difference calculation between the full set of methods and the set of run methods. An analysis result containing the set of non-run methods is generated and fed back to the management personnel.

2. The code analysis method based on the combination of static and dynamic analysis according to claim 1, characterized in that, The generation and feedback of analysis results with the set of unrunned methods includes: Static analysis is performed on each non-running method in the set of running methods to construct the call dependencies between the non-running methods and other methods in the full set of methods; Based on the aforementioned call dependencies, each non-running method is assigned a risk label, which characterizes the impact of deleting the corresponding non-running method on all methods in the full method set; wherein, the non-running methods included in the analysis results have corresponding risk labels.

3. The code analysis method based on the combination of static and dynamic analysis according to claim 2, characterized in that, The method further includes: The runtime scenario characteristics of the target service instance are obtained by collecting the context information associated with the running process of the target service instance during execution. The preset expected functional scenario corresponding to each non-running method in the non-running set is matched and analyzed with the runtime scenario features; If there is a target non-running method that satisfies the following conditions: the expected functional scenario of the target non-running method does not match the runtime scenario characteristics, but the target non-running method has potential value, then the target non-running method is identified as a scenario-specific method, the scenario-specific method is migrated to a preset independent code archive library for storage, and an archive method index is established for the scenario-specific method so that the corresponding scenario-specific method can be called and executed.

4. The code analysis method based on the combination of static and dynamic analysis according to claim 3, characterized in that, The method further includes: Perform code similarity analysis on all methods in the full method set of all target projects, including the scenario-specific methods described above; Methods with code similarity higher than a preset threshold are clustered into a method cluster; Generate a baseline template method for each method family, wherein the baseline template method contains the common core logic of all methods in the method family; For each specific method in the method family, store the differences between the specific method and the baseline template method corresponding to the method family; When it is necessary to call and execute any specific method in any method family, the corresponding base template method is loaded and the corresponding differentiated modification points are applied to synthesize the complete logic of the corresponding specific method before execution.

5. The code analysis method based on the combination of static and dynamic analysis according to claim 3, characterized in that, The method further includes: For each method in the full set of methods, construct a multidimensional vector. The features contained in the multidimensional vector include at least: a call activity decay index calculated based on historical call data and a code structure importance score calculated based on call relationships. The multidimensional vector of each method is input into a preset code value prediction model, and the code value prediction model outputs the obsolescence probability of the corresponding method. The obsolescence probability is used to characterize the possibility that the corresponding method will be obsolete in the future. The probability of the method being scrapped is fed back to the management personnel so that they are aware of it.

6. The code analysis method based on the combination of static and dynamic analysis according to claim 5, characterized in that, The method of feeding back the obsolescence probability to the management personnel for their information includes: For methods with a higher probability of being scrapped than a preset probability value, the contribution of each feature in the multidimensional vector of the corresponding method to the scrapping probability is calculated, and an explanation is generated based on the contribution. The explanation is used to characterize the reason for the high scrapping probability. Methods with a higher probability of being discarded than the preset probability value, along with their corresponding explanations, will be fed back to the management personnel for their information.

7. The code analysis method based on the combination of static and dynamic analysis according to claim 6, characterized in that, The method further includes: For each unrunnated method, acquire corresponding key data, including at least scenario matching results, risk tags, and abandonment probability; based on the acquired key data, and following a preset logical judgment process, generate a final strategy for the unrunnated method; wherein the analysis results include the final strategy for each unrunnated method; the final strategy includes at least: a suggestion to delete and a suggestion for manual review.

8. A code analysis platform based on a combination of static and dynamic analysis, characterized in that, include, The full method collection module (201) is used to acquire trigger signals, use preset static code analysis tools to parse the source code of the target project, extract all methods defined in the target project, and construct a full method collection. The running method collection module (202) is used to collect all the methods that have been executed in the running process of the target service at the end of the life cycle of the target service instance in the production environment and before the running process is terminated, so as to form a running method set; The data comparison and analysis module (203) is used to perform difference calculation between the full set of methods and the set of running methods to obtain the set of non-running methods, generate and return the analysis results with the set of non-running methods, so that the managers can know them.

9. A code analysis device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 7.

Images