Java agent-based runtime dependency automatic acquisition method and system

Abstract

The application relates to the field of computer software engineering, and provides a Java agent-based runtime dependency automatic acquisition method and system, which comprises the following steps: non-invasively injecting an agent into a JVM through a -javaagent parameter when a Java application is started; registering a class file converter in the agent to monitor a class loading process; acquiring system running environment information; when a class loading event is monitored, identifying a class loader type, and for the three main types, respectively adopting specific modes to extract real paths of JAR files loaded; filtering and deduplicating the extracted paths; and finally integrating dependency information and system information and asynchronously outputting the same as structured data. The application solves the problems that static analysis cannot reflect runtime dependency and that existing APM tools have coarse acquisition granularity and do not support asset list generation.

Description

Technical Field

[0001] This application relates to the field of computer software engineering technology, specifically to a method and system for automatic runtime dependency collection based on Java agents. Background Technology

[0002] With the widespread adoption of microservice architecture and containerized deployment, enterprise-level Java systems typically consist of numerous services, each running on different operating systems, JVM versions, and deployment environments. To perform system governance, dependency management, vulnerability investigation, and version asset inventory, operations and development personnel need to accurately obtain runtime environment information and a list of third-party dependency JARs.

[0003] Currently, common methods for dependency collection and system information acquisition mainly include the following categories:

[0004] (1) Static dependency analysis based on build tools

[0005] During the build phase, a dependency tree is generated using Maven or Gradle plugins (such as mvn dependency:tree or gradledependencies) to analyze the project's third-party libraries.

[0006] This method can analyze dependencies at the source code level, but it has the following drawbacks:

[0007] It fails to reflect runtime dependencies loaded during actual deployment;

[0008] Unable to perceive the true internal structure of container images or Spring Boot fat jars (nested JARs);

[0009] Unable to record runtime environment (such as JDK version, operating system architecture, etc.);

[0010] The analysis results will become invalid if the JAR file is manually replaced or the classpath is modified in the runtime environment.

[0011] Therefore, static dependency analysis is only suitable for use in the build phase and cannot be used for dependency monitoring during production runtime.

[0012] (2) Runtime monitoring based on APM (Application Performance Monitoring) probe

[0013] Some existing APM products (such as SkyWalking, Pinpoint, Arthas, etc.) use Java Agent technology to monitor class loading, method calls, etc.

[0014] However, these tools are primarily designed for performance sampling, tracing, or anomaly detection, and do not focus on dependency structure or system version information.

[0015] Its main drawbacks are:

[0016] The data collection granularity is too coarse, only counting the loaded class names instead of the JAR source;

[0017] The collected data has a fixed structure and cannot be expanded into an asset list;

[0018] It cannot distinguish between different levels of ClassLoader (such as Tomcat's WebappClassLoader or Spring Boot's LaunchedURLClassLoader).

[0019] It cannot achieve YAML / JSON structured output, making it difficult to integrate with asset platforms. Summary of the Invention

[0020] To help solve the above-mentioned technical problems, this application provides a method and system for automatic runtime dependency collection based on Java agents.

[0021] Firstly, this application provides a runtime dependency automatic collection method based on Java agents, employing the following technical solution:

[0022] A runtime dependency auto-collection method based on Java proxies, comprising the following steps:

[0023] S1: During the startup phase of the target Java application, a proxy program is injected using the Java Agent mechanism, and a class loader converter is registered to intercept and monitor the class loading process in the Java Virtual Machine;

[0024] S2: Collect system information of the current operating environment;

[0025] S3: When a class loading event is detected, identify the type characteristics of the class loader instance that is performing the current loading operation, classify the class loader instance into a normal application class loader, a nested structure class loader, or a Web container class loader according to the identification result, and execute the differential dependency extraction strategy corresponding to the classification result respectively to obtain the list of resource paths loaded by the class loader.

[0026] S4: Filter the resource path list extracted in step S3, and remove preset system-level paths and paths that are not target file types;

[0027] S5: Integrate the filtered dependency path information from S4 with the system information collected in S2, and output it as structured data.

[0028] In S1, registering a class loader converter specifically involves registering a ClassFileTransformer to intercept class loading events before a class is defined, in order to obtain and analyze the ClassLoader instance that performs the loading operation.

[0029] The differential dependency extraction strategies described in S3 include:

[0030] For ordinary application class loaders, the URLClassPath structure inside is accessed through reflection to extract the list of URLs for JAR files;

[0031] For nested class loaders, the getURLs() method is called to obtain a list of URLs for nested JARs, and the path prefixes indicating nesting are removed to obtain the actual JAR filenames.

[0032] For the Web container class loader, the getURLs() method is used to obtain a list of JAR file URLs in the WEB-INF / lib / directory.

[0033] The filtering rules described in S4 include: ignoring entries containing system keywords such as jdk, jre, agent, and tools.jar in the path, retaining only paths with the file extension .jar, and excluding paths located in the preset system library standard directory.

[0034] The output described in S5 is asynchronous, using a concurrency control mechanism, and waits for the main class loader to complete initialization before triggering the data integration and output logic.

[0035] After S3 performs dependency extraction, it also includes a data deduplication step: using a thread-safe collection to record the identifiers of the processed class loader instances, and deduplicating the extracted resource paths to ensure that each unique JAR file appears only once in the final output.

[0036] The system information collected in S2 includes at least: Java version, JVM startup parameters, operating system name, operating system architecture, operating system version, and collection timestamp.

[0037] Secondly, this application also provides a runtime dependency automatic collection system based on Java agents, which adopts the following technical solution:

[0038] A runtime dependency auto-collection system based on Java proxies, wherein the runtime dependency auto-collection method based on Java proxies as described in any of the first aspects is employed, the system comprising:

[0039] The startup and injection module is used to load the Java Agent into the Java Virtual Machine in response to a startup command that includes the -javaagent parameter;

[0040] The system information acquisition module is used to collect and encapsulate system-level operating environment information;

[0041] The class loading monitoring module is used to monitor class loading events through registered class loading converters and identify class loader types. The class loading monitoring module contains three parallel dependency extraction paths, corresponding to ordinary application class loaders, nested structure class loaders, and Web container class loaders, respectively.

[0042] The asynchronous output module is used to integrate system environment information and filtered and deduplicated dependency path information after the main class loader initialization is detected, and output the data in a structured data format.

[0043] The three dependency extraction paths are as follows:

[0044] The first path is used to extract the list of dependency URLs from a regular application class loader via reflection;

[0045] The second path is used to extract dependencies from nested structure class loaders by calling the getURLs() method and resolving the nested paths.

[0046] The third path is used for the Web container class loader to obtain dependencies under the WEB-INF / lib directory by calling the getURLs() method.

[0047] It also includes a data filtering and processing module, which is connected between the class loading monitoring module and the asynchronous output module, and is used to perform filtering and deduplication operations on the extracted resource paths.

[0048] In summary, compared with the prior art, the method of this application has the following advantages:

[0049] 1. By automatically injecting a Java Agent during the JVM startup phase, without modifying business logic, a truly "non-intrusive" data collection method is achieved, applicable to all Java applications;

[0050] 2. Automatically identifies multiple types of ClassLoader (AppClassLoader, WebappClassLoader, LaunchchedURLClassLoader), and can simultaneously support multiple runtime environments such as ordinary JAR files, Spring Boot, and Tomcat;

[0051] 3. Reflection can be used to parse the internal structure of the URLClassPath (including nested JARs), enabling complete extraction of the internal dependencies of the Spring Boot fat JAR;

[0052] 4. The path-level filtering mechanism effectively excludes system-level JARs and agent-specific JARs, improving data accuracy;

[0053] 5. Asynchronous triggering and thread safety mechanisms ensure data consistency and performance through CountDownLatch and concurrent collections;

[0054] 6. Unified structured output (JSON / YAML), supporting seamless integration with version asset management and monitoring platforms;

[0055] 7. It has strong extensibility and can be extended to other class loader types or output methods through configuration or SPI. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating a runtime dependency auto-collection method based on Java agents according to this application. Detailed Implementation

[0057] The present application will be further described below with reference to the accompanying drawings. The structure and principle of the present application are very clear to those skilled in the art. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

[0058] This application provides a non-intrusive runtime dependency collection scheme based on Java agents. By adding the `-javaagent` parameter to the application startup command, a customized Agent is injected into the target JVM. This Agent starts during the premain phase, automatically collecting system environment information and registering a class loading listener. During application runtime, the listener identifies and adapts to different types of class loaders, using targeted techniques to extract the actual JAR dependency paths loaded. The extracted dependency information, after filtering and deduplication, is asynchronously output as structured data along with system information after application startup, and can be directly used for operational scenarios such as asset inventory and vulnerability investigation.

[0059] Figure 1 This is a flowchart illustrating a runtime dependency auto-collection method based on Java proxies, as described in this application. Figure 1 The runtime dependency auto-collection method based on Java proxy in this application includes the following steps:

[0060] S1: When the Java application starts, the Java Agent is injected into the JVM via the -javaagent parameter. In the premain method of the Agent, a class loading converter is registered through the java.lang.instrument.Instrumentation interface to intercept and monitor the class loading process in the JVM.

[0061] Registering the class loader converter specifically involves registering a ClassFileTransformer, which is used to intercept class loading events before a class is defined in order to obtain and analyze the ClassLoader instance that performs the loading operation.

[0062] Specifically, the code implementing the logic of this application is packaged into a separate JAR file, such as system-agent-1.0.jar, and the Premain-Class attribute is correctly configured in its META-INF / MANIFEST.MF file, pointing to the class containing the premain method. When the user starts the Java application, the parameter -javaagent:path / to / system-agent-1.0.jar is added to the startup command. The JVM will load and initialize this Agent before loading the main class. In the Agent's premain method, a custom ClassFileTransformer is registered by calling the addTransformer method using the passed Instrumentation instance. Although the primary goal of this transformer is not to modify bytecode, its transform method is called every time a class is loaded, thus providing an entry point for capturing class loading events and enabling monitoring of the class loading process.

[0063] S2: Collect system information of the current operating environment.

[0064] The system information includes at least: Java version, JVM startup parameters, operating system name, operating system architecture, operating system version, and data collection timestamp. Specifically, this information can be obtained through ManagementFactory and System.getProperty and encapsulated into a SystemInfo object.

[0065] S3: When a class loading event is detected, identify the type characteristics of the class loader instance that is performing the current loading operation, classify the class loader instance into a normal application class loader, a nested structure class loader, or a Web container class loader according to the identification result, and execute the differential dependency extraction strategy corresponding to the classification result to obtain the list of resource paths loaded by the class loader.

[0066] Specifically, in the `transform` method of the registered `ClassFileTransformer`, the `ClassLoader` instance of the currently executing class loader is obtained through parameters or `Thread.currentThread().getContextClassLoader()`. By analyzing the class name or structural characteristics of this instance, it is categorized as follows:

[0067] Ordinary application class loader: usually refers to sun.misc.Launcher$AppClassLoader, used for standard executable JAR applications.

[0068] Nested class loader: usually refers to org.springframework.boot.loader.LaunchedURLClassLoader, used in Spring Boot's executable JAR (containing nested dependencies).

[0069] Web container class loader: usually refers to org.apache.catalina.loader.WebappClassLoader or its subclasses, used for WAR applications deployed by Servlet containers such as Tomcat.

[0070] For each type of loader, execute a differentiated dependency extraction strategy:

[0071] 1. For ordinary application class loaders: access the sun.misc.URLClassPath instance inside it through reflection, and then call its getURLs() method or access its internal collection to obtain a URL[] array, where each URL corresponds to a JAR file or directory.

[0072] 2. For nested class loaders: Cast the class loader to java.net.URLClassLoader and directly call its public method getURLs(). The obtained URL format is usually jar:file: / xxx.jar! / BOOT-INF / lib / yyy.jar! / . Through string processing, locate and remove the BOOT-INF / lib / prefix and nested identifiers to extract the internal JAR file name.

[0073] 3. For the Web container class loader: Similarly, cast it to java.net.URLClassLoader and call the getURLs() method. The obtained URL directly points to the specific JAR file in the WEB-INF / lib / directory, for example, file: / usr / local / tomcat / webapps / app / WEB-INF / lib / spring-webmvc-5.3.9.jar. The JAR filename can be directly parsed from the URL path.

[0074] S4: Filter the resource path list extracted in step S3, and remove preset system-level paths and paths that are not target file types.

[0075] Specific filtering rules include: ignoring entries containing system keywords such as jdk, jre, agent, and tools.jar in the path string; retaining only paths with the .jar file extension; and excluding paths located in the preset system library standard directory. This mechanism effectively excludes JAR files from the Java runtime environment, system libraries, and the Agent itself, ensuring that the final dependency list contains only business-related third-party JAR packages.

[0076] S5: Integrate the filtered dependency path information from S4 with the system information collected in S2, and output it as structured data.

[0077] In this embodiment, the output is asynchronous. The output thread reads a SystemInfo object and a filtered, deduplicated set of JAR filenames from the shared data area. This data is serialized into a structured string using a JSON or YAML library. The formatted string can be output to standard output, written to a specified local file, or reported to a remote asset management system via an HTTP client.

[0078] Furthermore, during or after the dependency extraction operation performed by S3, a data deduplication step can be included: using a thread-safe collection to record the unique identifiers of the processed class loader instances, avoiding duplicate extraction of the same loader. Simultaneously, another thread-safe Set... <string>Store the extracted and filtered unique JAR identifiers to ensure that each unique JAR file is recorded only once in the final output.

[0079] It should be noted that the numbers "S1" to "S5" in this application are only used to refer to steps and should not be construed as a strict restriction on the order of steps. For example, step S2, system information collection, and step S3, class loading monitoring and dependency extraction, can logically be started and executed in parallel. Those skilled in the art can adjust the execution timing or parallel relationship of some steps according to actual needs.

[0080] This application also provides a runtime dependency automatic collection system based on Java agents, which employs the collection method described in any of the above-described method embodiments. The system includes:

[0081] Startup and Injection Module: Used to load the JavaAgent into the Java Virtual Machine in response to Java application startup commands that include the -javaagent parameter.

[0082] System information collection module: used to collect and encapsulate system-level runtime environment information (JDK version, OS information, etc. in this embodiment) after the Agent starts.

[0083] The class loading monitoring module works in parallel with the system information acquisition module. It monitors class loading events and identifies class loader types through registered class loader converters. This module contains three parallel dependency extraction paths, one for general application class loaders, one for nested class loaders, and one for web container class loaders. Each path executes a differentiated extraction strategy tailored to the internal structure of the corresponding class loader.

[0084] Data filtering and processing module: Connected between the class loading monitoring module and the asynchronous output module, it is used to perform the aforementioned filtering and deduplication operations on the extracted resource path list.

[0085] Asynchronous output module: After detecting that the main class loaders have been initialized, it receives system environment information from the system information collection module and dependency path information from the class loading monitoring module, or after being processed by the data filtering and processing module, and integrates the two into a structured data format such as JSON or YAML for output.

[0086] The specific implementation of the three dependency extraction paths corresponds to the description of step S3 in the aforementioned method embodiment:

[0087] The first path, for ordinary application class loaders, extracts dependencies by accessing their internal URLClassPath object through reflection.

[0088] The second path, targeting nested class loaders, extracts dependencies by calling getURLs() and resolving nested paths.

[0089] The third path, for the Web container class loader, retrieves the dependencies under the WEB-INF / lib directory by calling getURLs().

[0090] Specifically, it can be divided into the following main modules:

[0091] 1. Agent Startup Registration Module

[0092] When the application starts, the Agent provided in this application is dynamically injected into the JVM by adding `-javaagent:system-agent-1.0-SNAPSHOT.jar` to the startup command. The Agent's `premain` method executes before the main class is loaded, registering a class loader converter (ClassFileTransformer) through the Instrumentation interface so that monitoring logic is automatically executed during the initialization of various class loaders.

[0093] 2. System Information Acquisition Module

[0094] After the Agent starts, it first collects and encapsulates system-level runtime environment information, generating a SystemInfo object with fields including:

[0095] getTime: Data collection time;

[0096] jdkVersion: Java version;

[0097] jvmArguments: JVM startup parameters;

[0098] osName: Operating system name;

[0099] osArch: CPU architecture;

[0100] osVersion: System version.

[0101] This module uses ManagementFactory and system properties (System.getProperty) to obtain information and records timestamps using Date.

[0102] 3. Class Loading Monitoring Module

[0103] When classes are loaded during application runtime, this application utilizes the transformer callback mechanism provided by Instrumentation to judge and analyze each newly appearing ClassLoader instance.

[0104] The system can automatically identify three typical class loader types:

[0105] AppClassLoader is suitable for regular executable JARs;

[0106] LaunchedURLClassLoader — suitable for Spring Boot packaging;

[0107] WebappClassLoader – Suitable for Tomcat or containerized deployments.

[0108] (1) Dependency extraction:

[0109] Whenever a new class loader instance is detected, the system automatically invokes the corresponding dependency extraction logic. This application employs a differentiated extraction method for different types of ClassLoaders:

[0110] Normal AppClassLoader:

[0111] By accessing its private field ucp (of type sun.misc.URLClassPath) through reflection, its path or lmap field can be parsed to extract the list of URLs actually loaded.

[0112] Spring Boot LaunchedURLClassLoader:

[0113] Because its internal JARs are nested (e.g., jar:file: / app.jar! / BOOT-INF / lib / *.jar! / ), LaunchedURLClassLoader inherits from URLClassLoader, calls getURLs() to obtain the URLs that the JARs depend on, and uses a string truncation function to remove the "BOOT-INF / lib / " prefix, keeping only the filename part. See the following code for details:

[0114] app.jar

[0115] ├── BOOT-INF /

[0116] │ ├── classes / # Business class

[0117] │ └── lib / # All third-party dependency JARs

[0118] ├── META-INF /

[0119] │ └── MANIFEST.MF

[0120] └── org / springframework / boot / loader / (Spring Boot starter classes)

[0121] Tomcat WebappClassLoader:

[0122] The `getURLs()` method is called to directly retrieve the dependent JAR files in the `WEB-INF / lib / ` directory. During the extraction process, the system uses a `ConcurrentHashMap` to record the processed `ClassLoader` instances and utilizes a `Set`... <string>Deduplication is performed to ensure that each JAR file is recorded only once. See the following code for details:

[0123] app.war

[0124] ├── WEB-INF /

[0125] │ ├── classes / # Business class

[0126] │ └── lib / # All third-party dependency JARs

[0127] ├── META-INF /

[0128] └── MANIFEST.MF

[0129] (2) Data filtering and noise removal:

[0130] To ensure that the output only includes business-related dependencies, this application performs path filtering during the extraction phase:

[0131] Ignore paths containing keywords such as jdk, jre, agent, tools.jar;

[0132] Ignore files that do not end with .jar;

[0133] Exclude system library directories (such as / usr / lib / jvm / , C: / Program Files / Java / ).

[0134] This mechanism effectively eliminates redundant JAR information from both the system level and the agent itself.

[0135] 4. Asynchronous output module

[0136] Once it is detected that all major ClassLoaders have been initialized (i.e., the application has finished starting), this application asynchronously triggers output logic via CountDownLatch to uniformly print or write JSON / YAML format data, which can be directly reported to the visual asset management platform. See the following code for details:

[0137] jdkVersion: 1.8.0_242

[0138] osName: Linux

[0139] osArch: aarch64

[0140] osVersion: 4.19.36

[0141] jars:

[0142] - sentinel-core-1.8.5.jar

[0143] - spring-boot-2.4.5.jar

[0144] - jackson-core-2.11.4.jar

[0145] To verify the adaptability and effectiveness of this application for different types of Java applications, the following examples are provided:

[0146] Case 1: Dependency Collection During Runtime of a Typical Java Application

[0147] The user specifies in the startup command:

[0148] java -javaagent:system-agent-1.0.jar -jar app.jar

[0149] During the JVM startup process:

[0150] 1. The SystemAgent.premain() method is executed;

[0151] 2. The system information acquisition module obtains JDK, operating system, and startup parameters;

[0152] 3. The class loading monitoring module detected sun.misc.Launcher$AppClassLoader;

[0153] 4. Extract all URLs by accessing the ucp.path field using reflection;

[0154] 5. Filter out non-.jar and system path files to obtain the business dependency list;

[0155] 6. Output to a YAML file or print to the console.

[0156] The output is as follows:

[0157] jdkVersion: 1.8.0_242

[0158] osName: Linux

[0159] osArch: aarch64

[0160] osVersion: 4.19.36

[0161] jars:

[0162] - hutool-all-5.8.20.jar

[0163] - fastjson-1.2.83.jar

[0164] - mysql-connector-java-8.0.28.jar

[0165] Case Study 2: Spring Boot Executable JAR Data Collection

[0166] Executing the command:

[0167] java -javaagent:system-agent.jar -jar spring-app.jar

[0168] When the Agent detects org.springframework.boot.loader.LaunchedURLClassLoader, it accesses its ucp.loaders collection via reflection and extracts the internal URL from each loader.

[0169] The URL format is as follows:

[0170] jar:file: / spring-app.jar! / BOOT-INF / lib / spring-core-5.3.9.jar! /

[0171] The system resolves the path and removes the prefix "BOOT-INF / lib / " to obtain the actual dependency filenames, as shown in the following output:

[0172] jars:

[0173] - spring-core-5.3.9.jar

[0174] - spring-context-5.3.9.jar

[0175] - jackson-core-2.12.5.jar

[0176] Meanwhile, the system information acquisition module records JDK and system information and generates a complete dependency snapshot.

[0177] Case Study 3: Tomcat Container WAR Application Data Collection

[0178] In a Tomcat deployment scenario, adding `-javaagent:system-agent.jar` to the Catalina startup script will cause the Agent to detect the `org.apache.catalina.loader.WebappClassLoaderBase` class loader.

[0179] The system directly calls the getURLs() method to retrieve the list of JAR files under WEB-INF / lib / , for example:

[0180] file: / usr / local / tomcat / webapps / app / WEB-INF / lib / spring-webmvc-5.3.9.jar

[0181] file: / usr / local / tomcat / webapps / app / WEB-INF / lib / servlet-api-4.0.1.jar

[0182] Filtered output:

[0183] jars:

[0184] - spring-webmvc-5.3.9.jar

[0185] - servlet-api-4.0.1.jar

[0186] The technical scope of this application is not limited to the contents of the above specification. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this application, and all such modifications and variations should fall within the scope of this application.< / string> < / string>

Claims

1. A Java agent-based runtime dependency auto-collection method, characterized in that, Includes the following steps: S1: During the startup phase of the target Java application, a proxy program is injected using the Java Agent mechanism, and a class loader converter is registered to intercept and monitor the class loading process in the Java Virtual Machine; S2: Collect system information of the current operating environment; S3: When a class loading event is detected, identify the type characteristics of the class loader instance that is performing the current loading operation. Based on the identification results, class loader instances are classified as ordinary application class loaders, nested structure class loaders, or Web container class loaders. Differentiated dependency extraction strategies corresponding to the classification results are executed respectively to obtain the list of resource paths loaded by the class loader. S4: Filter the resource path list extracted in step S3, and remove preset system-level paths and paths that are not target file types; S5: Integrate the filtered dependency path information from S4 with the system information collected in S2, and output it as structured data.

2. The Java proxy based runtime dependency auto-collection method of claim 1, wherein, In S1, registering a class loader converter specifically involves registering a ClassFileTransformer to intercept class loading events before a class is defined, in order to obtain and analyze the ClassLoader instance that performs the loading operation.

3. The Java proxy based runtime dependency auto-collection method of claim 1, wherein, The differential dependency extraction strategies in S3 include: If the class loader instance is classified as a normal application class loader, then the sun.misc.URLClassPath object maintained internally by the loader is accessed via reflection to extract the list of JAR file URLs managed by it. If the class loader instance is classified as a nested structure class loader, then after casting the loader to the java.net.URLClassLoader type, its getURLs() method is called to obtain a list of URLs, and the obtained URL strings are parsed to remove the path prefixes representing nested JAR structures in order to obtain the actual JAR file names; If the class loader instance is classified as a Web container class loader, then after casting the loader to the java.net.URLClassLoader type, its getURLs() method is called to obtain a list of JAR file URLs under the WEB-INF / lib / directory.

4. The Java proxy based runtime dependency auto-collection method of claim 1, wherein, The filtering rules in S4 include: ignoring entries containing the system keywords jdk, jre, agent, and tools.jar in the path, keeping only paths with the file extension .jar, and excluding paths located in the default system library standard directory.

5. The Java proxy based runtime dependency auto-collection method of claim 1, wherein, In S5, output is asynchronous and uses a concurrency control mechanism, waiting for the main class loader to complete initialization before triggering the data integration and output logic.

6. The Java proxy based runtime dependency auto-collection method of claim 1, wherein, After S3 performs dependency extraction, it also includes a data deduplication step: using a thread-safe collection to record the identifiers of the processed class loader instances, and deduplicating the extracted resource paths to ensure that each unique JAR file appears only once in the final output.

7. The runtime dependency automatic collection method based on Java proxy according to claim 1, characterized in that, The system information collected in S2 includes at least: Java version, JVM startup parameters, operating system name, operating system architecture, operating system version, and collection timestamp.

8. A runtime dependency automatic collection system based on Java agents, characterized in that, The system employs the runtime dependency auto-collection method based on Java agents as described in any one of claims 1 to 7, and includes: The startup and injection module is used to load the Java Agent into the Java Virtual Machine in response to a startup command that includes the -javaagent parameter; The system information acquisition module is used to collect and encapsulate system-level operating environment information; The class loading monitoring module is used to monitor class loading events through registered class loading converters and identify class loader types. The class loading monitoring module contains three parallel dependency extraction paths, corresponding to ordinary application class loaders, nested structure class loaders, and Web container class loaders, respectively. The asynchronous output module is used to integrate system environment information and filtered and deduplicated dependency path information after the main class loader initialization is detected, and output the data in a structured data format.

9. The runtime dependency automatic collection system based on Java proxy according to claim 8, characterized in that, The three dependency extraction paths are as follows: The first path is used to extract the list of dependency URLs from a regular application class loader via reflection; The second path is used to extract dependencies from nested structure class loaders by calling the getURLs() method and resolving the nested paths. The third path is used for the Web container class loader to obtain dependencies under the WEB-INF / lib directory by calling the getURLs() method.

10. The runtime dependency automatic collection system based on Java agents according to claim 8, characterized in that, It also includes a data filtering and processing module, which is connected between the class loading monitoring module and the asynchronous output module, and is used to perform filtering and deduplication operations on the extracted resource paths.

Images