CN116483700A - A Method of API Misuse Detection and Correction Based on Feedback Mechanism - Google Patents

Abstract

The invention provides an API misuse detection and correction method based on a feedback mechanism, which comprises the following steps: 1) Collecting an application programming interface API correct use data set and an API misuse data set, and acquiring a source code set; 2) After the source codes of correct use and misuse of the API are obtained, the correct use mode and misuse mode of the API are mined, so that the use condition of the API is generalized; 3) Giving a code to be detected, converting the code to be detected into an API usage graph AUG to be detected, and completing detection of whether the API misuse occurs by using a graph distance algorithm; 4) After the misuse of the API is detected, a modification opinion is provided for the misuse API, so that the user can correct the API conveniently. The method utilizes two opposite data sets of an API project set and an API misuse code set to detect the API misuse of the code to be detected from two opposite aspects. The invention introduces the use of different feedback information in detail, and further improves the accuracy of API misuse detection and API misuse correction by using user interaction.

Description

A Method of API Misuse Detection and Correction Based on Feedback Mechanism

technical field

The invention belongs to the technical field of software engineering, and in particular relates to a method for detecting and correcting API misuse based on a feedback mechanism.

Background technique

In the process of modern software development, developers often rely on third-party libraries that provide reusable functions, and the third-party libraries are accessed through Application Programming Interfaces (Application Programming Interface, API). APIs provide software developers with the means to interact with software development kits, libraries, operating systems, frameworks, and cloud services. Using the API, software developers can implement specific methods by calling the corresponding API and directly complete the corresponding functions without accessing the source code or knowing the details of the internal working mechanism of the called API. Therefore, by using API, software developers can simplify their work, improve work efficiency and code quality, and rely on existing software to reduce the overhead required to reinvent existing functions, reducing the development cost of the software development process.

When software developers call the API, they need to follow the constraints and usage precautions. For example, when using the file read and write stream to read and write files, exception handling must be performed. However, due to the complexity of the use of the API itself, the use constraints are usually implicit assumptions, the API documentation information is not complete or contains ambiguity, and the update and maintenance are not timely, etc., developers face severe challenges in the process of learning to use the API, and there are often problems of API misuse in the software development process. In addition, API misuse often arises due to reasons such as software developers becoming decoupled from the inner workings of the APIs they use or the API consumers themselves being negligent.

API misuse refers to the violation of the correct use constraints of the API, such as wrong method calls, missing condition checks, missing exception handling, etc. API misuse in actual projects can lead to code defects such as functional errors, performance problems, and security vulnerabilities. And due to the uneven security awareness of many developers and the lack of high-quality API documentation, software problems caused by API misuse have existed for a long time, seriously endangering software security. Therefore, detecting whether an API is misused is an important task in software development, and ideally, the development environment should be able to provide accurate correction suggestions for the detected API misuse.

In order to reduce API misuse, many API misuse detection methods have been proposed, which can be basically divided into the following two categories:

The first type is to infer based on API documents, use natural language processing technology to analyze API documents, and use heuristic language patterns to infer specific types of API constraints, extract API usage rules and detect API misuse. For example, Ren et al. proposed a fine-grained API constraint knowledge graph to detect whether the use of API violates known usage constraints, such as call sequence, preconditions, etc., and then perform API misuse detection. This method develops an open information extraction method, crawls online API documentation to obtain API call constraints, and then converts it into a statement graph and compares it with source code to detect violations of API call constraints. Due to the limitations of API documentation, that is, in many libraries, developers are unwilling or incapable of writing high-quality documentation, so many API constraints cannot be correctly inferred from their documentation. Moreover, since the constraints extracted from API documents cannot be well combined with the actual software development process, the accuracy of API misuse detection needs to be improved.

The other is to convert API usage instances into API call situations based on the existing API project set, and extract API call rules from it, so as to detect whether the API is misused according to the extracted rules. Sven et al. proposed MuDetect, an API misuse detection tool. The method mines API usage graphs from cross-project code instances, exploits cross-project data to improve the way API call patterns are extracted, and then uses these API call patterns to detect API misuse. Many static API misuse detectors mine usage patterns, i.e., frequently occurring equivalent APIs, and report any anomalies in these patterns as potential API misuses. These methods all conform to the assumption that any deviations related to frequent usage patterns are potential misuses, but existing detectors still suffer from a large number of false positives due to the possibility of uncommon but correct usage patterns that do not fit the mined patterns.

In terms of API misuse correction, the method of defect automatic repair is generally adopted, that is, the test suite of the program is used to create patches as the specification of its expected behavior, and the defects in the software are repaired by automatically generating patches, thereby improving the efficiency of defect repair. Zhang et al. developed Seader, an example-based detection tool that can infer vulnerability remediation patterns and apply these patterns in vulnerability detection and remediation recommendations. Seader compares code fragments, combines intra-program analysis and inter-program analysis, infers API misuse templates to search for API misuse, and provides high-precision repair suggestions. However, when repairing API misuse defects, the current automatic defect repair methods still have shortcomings such as single type of repair defects, relying on predefined repair templates, and low efficiency.

At the same time, many current API misuse detection tools can only detect API misuse, and do not provide correction suggestions or defect repair methods for it. Therefore, the current API misuse detection methods still have certain deficiencies, and new methods are urgently needed to improve the existing technologies.

Contents of the invention

The purpose of the present invention is to propose a new method for detecting API misuse based on a feedback mechanism, and at the same time provide correction suggestions for the detected API misuse. Our new approach consists of four main phases, which are data collection phase, code pattern mining phase, API misuse detection phase, and API misuse remediation phase, and the following are the main objectives of each phase:

In the data collection stage, collect a large number of high-quality API correct use projects and API misuse code sets, obtain representative and comprehensive source code collections, and ensure the richness and diversity of API types.

In the code pattern mining stage, API usage patterns are mined using API usage graphs and frequent pattern mining algorithms, and a comprehensive API positive/misuse pattern data set is obtained.

In the API misuse detection stage, the code to be detected is judged from two aspects of API positive/misuse pattern data sets, reducing the impact of any deviation related to frequent use patterns as potential misuse, further improving the accuracy of API misuse detection, and reducing the generation of false positives.

In the API misuse correction stage, correction suggestions are put forward for the detected API misuse, and the API usage pattern data set is continuously adjusted according to user feedback information, and the accuracy of API misuse detection and API correction suggestion generation is further improved by recording user interaction information.

A method for detecting and correcting API misuse based on a feedback mechanism, comprising the following steps:

1) Collect application programming interface API correct use source code set and API misuse source code set;

2) Mining the API correct use pattern and API misuse pattern from the API correct use source code set and API misuse source code set;

3) Give the code to be detected, convert the code to be detected into an API usage graph to be detected, and use the graph distance algorithm to complete the detection of API misuse;

4) After detecting the misuse of the API, propose amendments to the misuse of the API.

Preferably, the implementation process of step 1) is:

Step 1.1) Select a large real open source client code as the API to properly use the source code set;

For the correct use of the source code set of the obtained API, screen the multiple source files of the correct use of the source code set of the API according to the development language, and keep the source files ending in .java; use the Java code analysis tool JavaParser to parse the source files ending in .

Step 1.2) Obtain API misuse source code set through the crowd intelligence knowledge of the technical question-and-answer website StackOverflow;

Extract the API type from the official document, use the search engine to search from the technical question-and-answer website StackOverflow and link to the corresponding API type; at the same time, choose to search for the API type and keywords in the title or question of the post to obtain examples of API misuse.

Preferably, in step 2):

The transformation process of converting a source code set into an API usage graph is as follows: 1) represent the objects, values and texts in the API usage with data nodes; 2) represent the method calls, operators and instructions in the API usage with action nodes; 3) represent the control and data flow between entities and actions represented by nodes with edges, which are divided into eight types, including receive edges, parameter edges, definition edges, sequence edges, condition edges, throw edges, processing edges, and synchronization edges; API usage includes API correct use and API misuse;

Modify and improve the acquired API usage graph: first, add a type attribute to each sequence edge order of the API usage graph to indicate the sequence of method calls; secondly, use fields and parameters different from local variables to represent the information in the data node; finally, find the statement that identifies the basic information of misuse from the code block that contains the constructor and field initialization, and link the found corresponding statement to the API usage graph of the method that uses the corresponding statement through the order edge order;

Step 2.1) According to the conversion process, the API correct use source code set and the API misuse source code set are respectively converted into the API correct use atlas and the API misuse atlas;

Step 2.2) Mining of the correct usage pattern of the API: use the correct usage graph of the API and the minimum threshold min_sup as the input of the frequent subgraph mining algorithm gSpan, and identify subgraphs whose frequency of occurrence is higher than the minimum threshold min_sup, that is, dig out the correct usage pattern of the API, and obtain the correct usage pattern dataset of the API;

Mining of API misuse patterns: due to the various forms of API misuse, each API misuse situation exists as an API misuse pattern alone, so the API misuse pattern is directly represented by the API misuse graph, and the API misuse pattern data set is obtained;

Step 2.3) For the correct usage pattern of the acquired API, an initial sorting is performed according to the frequent support.

Preferably, the implementation process of step 3) is:

Step 3.1) convert the code to be detected into an API usage diagram to be detected according to the conversion process;

Step 3.2) Detect whether API misuse occurs by graph distance algorithm:

For the usage graph of the API to be detected, compare the usage graph of the API to be detected with the correct API usage graph and the API misuse graph through the graph distance algorithm, and judge whether API misuse occurs in the API usage according to the relative distance between the API usage graphs:

First, dist is defined as a distance function, and the relative distance between any two API usage graphs augi and augj is expressed as dist(augi, augj) ∈ [0, 1]; where 0 means that the usages of the two API usage graphs are completely the same, and 1 means that the two usages are completely different; in addition, each API usage graph in the API correct usage source code set is denoted as augc, and each API usage graph in the API misuse source code set is denoted as augm;

For each API usage graph to be detected, the API name is used as a search keyword, and the full-text search is carried out in the API correct use source code set and the API misuse source code set, and a set of API usage graph data sets C = {augc1, augc2, ..., augcm} and a set of misused API usage graph data sets M = {augm1, augm2, ..., augmn} are obtained;

According to the graph distance algorithm, the usage graph of the API to be detected is expressed as augt. When the usage graph of the API to be detected is correct, it is expected to appear:

When the usage graph of the API to be detected is misused, it is expected to appear:

Preferably, the implementation process of step 4) is:

Step 4.1) Present the correction code suggestion:

For the detected API misuse, retrieve the API correct usage pattern data set according to the API name, and select the top 5 API misuse patterns according to the correction suggestion score. Since the API misuse pattern is directly represented by the API usage graph, the top 5 API usage graphs are obtained, and then the nodes and edges in the API usage graph are traversed to extract the order of API calls, the parameters of each API call, and the type information of the returned results, and generate API codes;

Step 4.2) The user selects and records the feedback information:

For the 5 API codes provided to the user for each API misuse pattern in step 4.1), record the feedback information during user interaction, specifically divided into the following three types:

i) If the user chooses to adopt the API code corresponding to an API misuse pattern, provide a feedback on the API correct usage pattern data set, and set a positive feedback score for the API correct usage pattern;

ii) If the user chooses to rewrite by himself, record the rewritten API code as the API correct usage pattern, convert the API correct usage pattern into an API usage map, incorporate it into the API correct usage pattern dataset and set a positive feedback score;

iii) If the user rejects all the correction code suggestions and does not rewrite them by himself, the API usage map to be tested is considered correct, the API usage map to be tested is changed from an incorrect code to a correct API code pattern, a positive feedback score is set for the API usage map to be tested, and the API usage map corresponding to the original API code is included in the correct API usage pattern dataset;

Step 4.3) Reorder using feedback information:

After obtaining user feedback, calculate the correction suggestion score and reorder the original API correct usage pattern data set: when no user feedback is initially generated, the calculation formula of the correction suggestion score for each possible correction API usage graph is as follows:

Among them, FinalScore(i) represents the correction suggestion score of the i-th correction API usage graph, and Frequent(i) represents frequent support; u and v are weight coefficients;

After generating user feedback, the correction suggestion score for each possible correction API usage graph is calculated as follows:

Where Feedback(i) represents the corresponding feedback score, and w is the weight corresponding to the feedback score;

With the increase of user feedback information, the API usage pattern data set is continuously adjusted according to the correction suggestion score, so that the accuracy of API misuse detection is continuously improved, and the modified code template proposed for API misuse is also more accurate.

Beneficial effect:

1) In the present invention, we propose a method for API misuse detection and correction based on a feedback mechanism. This method utilizes two opposite data sets, the API item set and the API misuse code set, and performs API misuse detection on the code to be detected from two opposite aspects.

2) The present invention proposes a method of recording user interaction feedback information and using it to further adjust the data set, introduces the usage of different feedback information in detail, and uses user interaction to further improve the accuracy of API misuse detection and API misuse correction.

Description of drawings

Figure 1 is a flow chart of API misuse detection and correction based on the feedback mechanism;

Figure 2 is an example of API usage and its corresponding AUG;

Fig. 3 is a schematic flow chart of recording feedback information.

Detailed ways

Phase 1. Data Collection

Collect API correct use data sets from high-quality client projects, collect API misuse data sets from technical question-and-answer websites, obtain representative and comprehensive source code collections, and ensure the richness and diversity of API types.

Step 1.1 API client project code collection and processing

For the collection of the correct source code, select a large real open source client code project on the code hosting platform as the source code collection. Code hosting platforms can perform version management on user codes. Currently popular code hosting platforms mainly include GitHub, GitLab, BitBucket, CODING, Sourceforge, etc. In this invention, we obtain data by collecting high-quality client-side code projects on GitHub. The invention screens JAVA open source projects with more than 2000 stars on GitHub, comprehensively considers the field, project data scale, and the complexity of the API in the project to complete the project selection, and downloads and collects the project with the command line of git clone.

For the collected software projects, multiple source files in the project are screened according to the development language, that is, the source files ending in .java are kept. The Java source code is parsed by the Java code parsing tool JavaParser, the abstract syntax tree of each method body contained in the source file is obtained, the target API is extracted from it, and the usage example corresponding to the target API is extracted by using program slicing technology. Here we use the API usage examples obtained from high-quality client codes as correct usage examples for subsequent mining of correct API usage patterns.

Step 1.2 Q&A website API misuse code collection and processing

In the collection of API misuse source code, use the knowledge of the group wisdom of the technical question and answer website StackOverflow. Since StackOverflow is a popular technical question-and-answer site that attracts millions of developers, you can use the collective knowledge of developers to answer questions on this site to get examples of API misuse and some examples of fixes.

Due to the richness and diversity of API types, we choose to extract API types from official documents. Specifically, the API official documentation exists in the form of a set of HTML web pages, where each web page explains a specific API type in detail, and the web pages have a unified format style. By parsing the title of each web page, the corresponding API type is extracted. In addition, since developers tend to use API abbreviations in Q&A, API abbreviations need to be extracted from API documents to accurately match APIs in Q&As and code samples. When the same unqualified name conflicts in different packages, the fully qualified name is used to distinguish.

For the API type extracted from the API documentation, use a search engine to search from StackOverflow and link to the relevant API type. For API misuse examples, StackOverflow posts usually use keywords to describe the actual problem. Therefore, we choose to capture the corresponding examples of API misuse by searching for API types and keywords that appear in the title or question of the post. The keywords here are "misuse", "error", "exception", "fail", "issue", "flaw" and "incorrect usage".

Phase 2. Code Pattern Mining

After obtaining the code representation of the API usage mode, it is necessary to dig out the correct API usage pattern and the API misuse pattern, so as to generalize the API usage, and facilitate the subsequent API misuse detection of the code to be detected and the correction template recommendation for the misused code.

Step 2.1 Convert the code into a graph representation

To mine API usage patterns from code, it is usually necessary to convert the code into some intermediate representations to obtain better generalization capabilities. Currently, the more commonly used intermediate representations include call sequences, abstract syntax trees, and graph structures. Compared with call sequence and abstract syntax tree, graph structure is more convenient to represent the interaction between variables, and it is also more convenient for coding to use elements, structures and data dependencies. Therefore, the choice is to convert the code into an API usage graph, from which API usage patterns can be mined.

An API Usage Graph (AUG) is a directed connected graph with labeled nodes and edges that captures usage properties relevant to identifying API misuse. The specific conversion process of converting code into AUGs is as follows: 1) Represent objects, values, and text in API usage with data nodes; 2) Represent method calls, operators, and instructions in API usage with action nodes; 3) Represent the control and data flow between entities and actions represented by nodes with edges, which are divided into eight types, including receive edges, parameter edges, definition edges, sequence edges, condition edges, throw edges, processing edges, and synchronization edges. An example of API usage and its corresponding AUG is shown in Figure 2.

In order to represent API constraints in more detail, we can modify and enhance AUG to better assist API misuse detection. First, add a type attribute to each order edge to represent the sequence of method calls, that is, the order edge in AUG is expressed as the pre-order call constraint order[precede] and the follow-up call constraint order[follow] according to the call order constraints. Secondly, use fields and parameters different from local variables to represent the information in the data node, that is, in addition to using the parameter edge para to indicate that a specific variable is passed as a parameter in the method call, the parameters of the current method in the data node are also marked as param. Finally, since constructors and field initializations provide necessary information for identifying misuses, we choose to find corresponding statements from code blocks containing constructors and field initializations and link them through sequential edges into the AUG of methods that use these fields. In actual use, you can choose to use the basic AUG or the modified AUG to represent the API usage according to specific needs.

Converting the code to AUGs can facilitate the subsequent comparison of the AUGs of the code to be detected with the AUGs of the API constraints in the data set, so as to more accurately detect API misuse.

Step 2.2 Frequent Pattern Mining

In client project code, the frequency of API usage can generally represent correctness and certainty. Therefore, for the mining of API correct usage patterns, the frequent pattern mining algorithm is selected to mine frequent patterns from the AUGs converted by the project code, and the AUGs whose occurrence frequency is not less than the specified frequency threshold are considered to be API correct usage patterns.

Here, we choose to use the frequent subgraph mining algorithm gSpan for frequent pattern mining, take AUGs and the lowest threshold (min_sup) as input, and identify subgraphs with a frequency higher than min_sup as output. gSpan will map each subgraph to the minimum depth-first search (DFS) code, and enumerate the subgraphs in the order of DFS code through depth-first search. In addition, gSpan uses heuristics to prune branches during code tree traversal to facilitate subgraph mining in less time. Finally, the subgraph with a frequency higher than min_sup can be obtained, that is, the mined API usage pattern.

However, due to the various forms of API misuse, each API misuse situation can exist as an API misuse pattern alone, so the API misuse pattern is directly represented by the misuse AUG, and frequent pattern mining is not necessary.

Step 2.3 Initial Ranking of API Usage Patterns

After the API usage patterns are mined, the correct API usage patterns mined by the frequent pattern mining algorithm will be initially sorted according to their frequent support, and then the API usage patterns will be reordered according to the weight of feedback and frequent support.

Phase 3. API Misuse Detection

Given the code to be detected, by converting it into AUG to be detected, and using the graph distance algorithm, the detection of API misuse can be completed.

Step 3.1 Convert the code to be detected into a graph representation

When testing the code to be tested, it is first necessary to convert the code to be tested into test AUGs according to the method of converting the code into a graph structure as shown in step 2.1.

Step 3.2 Detect whether it is misused by the graph distance algorithm

Based on the large-scale API correct usage pattern and API misuse pattern data sets, for the test AUG, the test AUG is compared with the positive/misuse pattern data set through the graph distance algorithm, and whether the API usage is misused is judged according to the relative distance between the AUGs. The specific implementation process is as follows:

First, dist is defined as a distance function, and the relative distance between any two AUGs (augi and augj) is denoted as dist(augi, augj) ∈ [0, 1]. Where 0 means that the usages of the two AUGs are exactly the same, and 1 means that the usages of the two AUGs are completely different. Furthermore, denote each AUG in the API correct usage patterns dataset as augc and each AUG in the API misuse dataset as augm.

For each API usage to be detected, the API name is used as the search keyword, and the full-text search is carried out in the API positive/misuse pattern data set, and a set of AUGs data sets C={augc1,augc2,...,augcm} and a set of misuse data sets M={augm1,augm2,...,augmn} that describe the correct usage can be obtained.

According to the general idea of the graph distance algorithm, the AUG to be detected is expressed as augt. When the AUG to be detected is used correctly, it is expected to appear:

When the AUG to be detected is misused, it is expected to appear:

Therefore, the graph distance algorithm can be used to calculate the relative distance from the usage to be judged to the correct usage and misuse, so as to judge whether API misuse occurs. If the minimum value of the distance between the AUG to be judged and any correct usage in C is smaller than the minimum value of the distance to any misused usage in M, the AUG to be detected is considered to be a correct usage, otherwise it is API misuse.

Phase 4. API Misuse Fixes

After the misuse of the API is detected, suggestions for modification of the misused API are proposed, so that it is convenient for users to make corrections. And record the feedback information of user corrections to further enhance the accuracy of API misuse and API corrections. The specific flowchart of recording feedback information is shown in FIG. 3 .

Step 4.1 Presenting correction code suggestions

For the detected API misuse, retrieve the API correct usage data set according to the API name, and select the top 5 API usage patterns according to the correction suggestion score. The calculation of the revised proposal score is explained in detail in step 4.3.

After obtaining the top 5 correction AUGs with the highest final correction suggestion scores, traverse the nodes and edges in the AUG, extract the order of API calls, the parameters of each API call, and the type of returned results, and generate corresponding API codes based on these information for users to refer to when correcting misused APIs.

Step 4.2 The user selects and records the feedback information

For the 5 correct code templates provided to users for each misused API in step 4.1, record the feedback information during user interaction, which can be divided into the following three types:

i) If the user chooses to adopt the API correction suggestion corresponding to a certain mode, provide a feedback to the API correct usage mode data set, and set a positive feedback score for the correct API usage mode.

ii) If the user chooses to rewrite by himself, record the rewritten API code as the correct code mode, convert it into AUG, include it in the correct usage mode data set, and set the positive feedback score.

iii) If the user rejects all the amendments and does not rewrite them by himself, the original AUG to be tested is considered correct, and it is marked as a correct API code mode from an error code change, a positive feedback score is set for it, and the AUG corresponding to the original API code is included in the correct API usage mode data set.

Step 4.3 Reordering using feedback information

After getting user feedback, it is necessary to calculate the correction suggestion score and reorder the original API correct usage pattern dataset.

The correction suggestion score is the basis for sorting the corresponding correct patterns of the detected API misuse. Since the feedback mechanism is introduced here, the correction suggestion score is determined by the graph distance and frequent support at the beginning. After the feedback mechanism starts to operate, the correction suggestion score is determined by the graph distance, frequent support and feedback score. Here, the graph distance refers to the distance between the misused AUG calculated by the graph distance algorithm and the corresponding correct AUGs in the API correct usage data set. According to the definition in step 3.2, the misused AUG is expressed as augt, and each corresponding correct AUG is expressed as augci. The graph distance can be expressed as dist(augt, augci). Since the correlation between dist(augt, augci) and two AUGs shows a negative correlation, it is necessary to take the inverse of dist in the final calculation.

When no user feedback is initially generated, the correction suggestion score calculation formula for each possible correction AUG is as follows:

Among them, FinalScore(i) represents the correction suggestion score of the i-th correction AUG, and Frequent(i) represents its frequent support. u and v are the different weights corresponding to each item.

After user feedback is generated, the correction suggestion score for each possible correction AUG is calculated as follows:

Where Feedback(i) represents the corresponding feedback score, and w is the weight corresponding to the feedback score.

With the increase of user feedback information, the API usage pattern data set is continuously adjusted according to the correction suggestion score, so that the accuracy of API misuse detection is continuously improved, and the modified code template proposed for API misuse is also more accurate.

Each embodiment in this specification is described in a progressive manner, the same and similar parts of each embodiment can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant parts, please refer to part of the description of the method embodiment. The above is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention shall be covered within the scope of protection of the present invention. Therefore, the protection scope of the present invention should be determined by the protection scope of the claims.

Claims (5)

1. A method for detecting and correcting API misuse based on a feedback mechanism, comprising the following steps: 1) Collect application programming interface API correct use source code set and API misuse source code set; 2) Mining the API correct use pattern and API misuse pattern from the API correct use source code set and API misuse source code set; 3) Give the code to be detected, convert the code to be detected into an API usage graph to be detected, and use the graph distance algorithm to complete the detection of API misuse; 4) After detecting the misuse of the API, propose amendments to the misuse of the API. 2. A kind of API misuse detection and correction method based on feedback mechanism as claimed in claim 1, it is characterized in that, The implementation process of step 1) is: Step 1.1) Select a large real open source client code as the API to properly use the source code set; For the correct use of the source code set of the obtained API, screen the multiple source files of the correct use of the source code set of the API according to the development language, and keep the source files ending in .java; use the Java code analysis tool JavaParser to parse the source files ending in . Step 1.2) Obtain API misuse source code set through the crowd intelligence knowledge of the technical question-and-answer website StackOverflow; Extract the API type from the official document, use the search engine to search from the technical question-and-answer website StackOverflow and link to the corresponding API type; at the same time, choose to search for the API type and keywords in the title or question of the post to obtain examples of API misuse. 3. A kind of API misuse detection and correction method based on feedback mechanism as claimed in claim 2, it is characterized in that, In step 2): The transformation process of converting a source code set into an API usage graph is as follows: 1) represent the objects, values and texts in the API usage with data nodes; 2) represent the method calls, operators and instructions in the API usage with action nodes; 3) represent the control and data flow between entities and actions represented by nodes with edges, which are divided into eight types, including receive edges, parameter edges, definition edges, sequence edges, condition edges, throw edges, processing edges, and synchronization edges; API usage includes API correct use and API misuse; Modify and improve the acquired API usage graph: first, add a type attribute to each sequence edge order of the API usage graph to indicate the sequence of method calls; secondly, use fields and parameters different from local variables to represent the information in the data node; finally, find the statement that identifies the basic information of misuse from the code block that contains the constructor and field initialization, and link the found corresponding statement to the API usage graph of the method that uses the corresponding statement through the order edge order; Step 2.1) According to the conversion process, the API correct use source code set and the API misuse source code set are respectively converted into the API correct use atlas and the API misuse atlas; Step 2.2) Mining of the correct usage pattern of the API: use the correct usage graph of the API and the minimum threshold min_sup as the input of the frequent subgraph mining algorithm gSpan, and identify subgraphs whose frequency of occurrence is higher than the minimum threshold min_sup, that is, dig out the correct usage pattern of the API, and obtain the correct usage pattern dataset of the API; Mining of API misuse patterns: due to the various forms of API misuse, each API misuse situation exists as an API misuse pattern alone, so the API misuse pattern is directly represented by the API misuse graph, and the API misuse pattern data set is obtained; Step 2.3) For the correct usage pattern of the acquired API, an initial sorting is performed according to the frequent support. 4. A kind of API misuse detection and correction method based on feedback mechanism as claimed in claim 3, it is characterized in that, the realization process of step 3) is: Step 3.1) convert the code to be detected into an API usage diagram to be detected according to the conversion process; Step 3.2) Detect whether API misuse occurs by graph distance algorithm: For the usage graph of the API to be detected, compare the usage graph of the API to be detected with the correct API usage graph and the API misuse graph through the graph distance algorithm, and judge whether API misuse occurs in the API usage according to the relative distance between the API usage graphs: First, dist is defined as a distance function, and the relative distance between any two API usage graphs augi and augj is expressed as dist(augi, augj) ∈ [0, 1]; where 0 means that the usages of the two API usage graphs are completely the same, and 1 means that the two usages are completely different; in addition, each API usage graph in the API correct usage source code set is denoted as augc, and each API usage graph in the API misuse source code set is denoted as augm; For each API usage graph to be detected, the API name is used as the search keyword, and the full-text search is performed in the API correct use source code set and the API misuse source code set, and a set of API usage graph data sets C = {augc1, augc2, ..., augcm} describing correct usage and a set of misused API usage graph data sets M = {augm1, augm2, ..., augmn} are obtained; According to the graph distance algorithm, the usage graph of the API to be detected is expressed as augt. When the usage graph of the API to be detected is correct, it is expected to appear: When the usage graph of the API to be detected is misused, it is expected to appear: 5. A kind of API misuse detection and correction method based on feedback mechanism as claimed in claim 4, it is characterized in that, the realization process of step 4) is: Step 4.1) Present the correction code suggestion: For the detected API misuse, retrieve the API correct usage pattern data set according to the API name, and select the top 5 API misuse patterns according to the correction suggestion score. Since the API misuse pattern is directly represented by the API usage graph, the top 5 API usage graphs are obtained, and then the nodes and edges in the API usage graph are traversed to extract the order of API calls, the parameters of each API call, and the type information of the returned results, and generate API codes; Step 4.2) The user selects and records the feedback information: For the 5 API codes provided to the user for each API misuse pattern in step 4.1), record the feedback information during user interaction, specifically divided into the following three types: i) If the user chooses to adopt the API code corresponding to an API misuse pattern, provide a feedback on the API correct usage pattern data set, and set a positive feedback score for the API correct usage pattern; ii) If the user chooses to rewrite by himself, record the rewritten API code as the API correct usage pattern, convert the API correct usage pattern into an API usage map, incorporate it into the API correct usage pattern dataset and set a positive feedback score; iii) If the user rejects all the correction code suggestions and does not rewrite them by himself, the API usage map to be tested is considered correct, the API usage map to be tested is changed from an incorrect code to a correct API code pattern, a positive feedback score is set for the API usage map to be tested, and the API usage map corresponding to the original API code is included in the correct API usage pattern dataset; Step 4.3) Reorder using feedback information: After obtaining user feedback, calculate the correction suggestion score and reorder the original API correct usage pattern data set: when no user feedback is initially generated, the calculation formula of the correction suggestion score for each possible correction API usage graph is as follows: Among them, FinalScore(i) represents the correction suggestion score of the i-th correction API usage graph, and Frequent(i) represents frequent support; u and v are weight coefficients; After generating user feedback, the correction suggestion score for each possible correction API usage graph is calculated as follows: Where Feedback(i) represents the corresponding feedback score, and w is the weight corresponding to the feedback score; With the increase of user feedback information, the API usage pattern data set is continuously adjusted according to the correction suggestion score, so that the accuracy of API misuse detection is continuously improved, and the modified code template proposed for API misuse is also more accurate.