Java application function call data collection method, device, medium and product

Abstract

The embodiment of the application relates to the information technology field, discloses a Java application function call data collection method, equipment, medium and product based on JVM-SA technology, and the method comprises the following steps: a collection process independent of a target Java application is used to establish a debugging connection with the target Java application; based on a preset collection range, a runtime memory space of the target Java application is directly accessed through the debugging connection, full-amount function call count original data generated by the target Java application in a running cycle is extracted; according to a parsing rule corresponding to a version of the target Java application, the function call count original data is corrected to obtain real function call statistical information; the real function call statistical information is outputted, and the debugging connection is disconnected, so that completely zero-invasion "bypass" data collection is realized.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method, device, medium and product for collecting Java application function call data based on JVM-SA technology. Background Technology

[0002] With the widespread adoption of Java technology in enterprise applications, application performance management (APM) and code coverage analysis have become crucial for ensuring system stability and optimizing code quality. In these scenarios, obtaining function call data from within Java applications is fundamental for accurate performance evaluation and dead code analysis.

[0003] Existing technologies primarily collect function call data from Java applications through the following methods:

[0004] The first category is bytecode enhancement technology, which achieves data collection by modifying or instrumenting bytecode during JVM class loading. However, this approach has significant limitations: First, it is intrusive to the original business code, and modifying bytecode may introduce compatibility risks; second, the instrumentation logic will continue to execute during application runtime, generating significant CPU and memory overhead, directly impacting business performance; furthermore, for large-scale production environments, fully enabling probes is often difficult to implement due to excessive performance overhead.

[0005] The second category is data collection methods based on JMX (Java Management Extensions) interfaces or log tracking. JMX typically only exposes system-level macro-indicators such as garbage collection and heap memory usage, failing to pinpoint the granularity of specific business functions. This results in overly coarse data granularity, making it difficult to meet the needs of refined analysis. Log tracking, on the other hand, requires explicit embedding of printing logic in the business code, which not only relies on manual development costs but also cannot track methods automatically called by the JVM or dynamically generated synthesized methods, leading to incomplete data coverage.

[0006] The third category is debugging analysis based on the Java Virtual Machine Tool Interface (JVMTI) or traditional Serviceability Agent (SA) technologies. While these technologies can deeply access the internal state of the JVM, they are typically designed for offline debugging in development environments (such as jstack and jmap tools). Using these technologies directly in production environments carries extremely high risks: firstly, establishing a debugging connection usually causes the target JVM process to pause, severely hindering the normal response of online services; secondly, existing tools lack robust resource protection mechanisms, and excessive memory consumption during data collection can easily lead to target process crashes or service unavailability.

[0007] In summary, existing technologies struggle to achieve a balance between zero invasiveness, data granularity, and production environment security. Therefore, there is an urgent need for a data collection method that can securely acquire full, real function call data without modifying the target application code, in order to meet the requirements for in-depth profiling of Java applications in production environments. Summary of the Invention

[0008] One objective of this application is to provide a method, device, medium, and product for collecting Java application function call data based on JVM-SA (Java Virtual Machine Serviceability Agent) technology, at least to solve the problem that existing Java application function call collection technologies usually rely on intrusive bytecode modification, thus affecting application performance, or are unable to securely obtain full data inside the JVM in a production environment due to the lack of effective security protection mechanisms.

[0009] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0010] This application provides a method for collecting Java application function call data based on JVM-SA technology, the method comprising:

[0011] Establish a debugging connection with the target Java application using a collection process independent of the target Java application;

[0012] Based on the preset collection range, the runtime memory space of the target Java application is directly accessed through the debugging connection to extract the raw data of all function call counts generated by the target Java application during its runtime cycle;

[0013] Based on the parsing rules corresponding to the version of the target Java application, the raw function call count data is corrected to obtain the actual function call statistics.

[0014] Output the actual function call statistics and disconnect the debugging connection.

[0015] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0016] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0017] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0018] Compared with related technologies, the solution provided in this application overcomes the shortcomings of existing bytecode enhancement technologies that require modification of business code or implantation of probes by using an independent process acquisition mode based on JVM-SA technology, achieving completely non-intrusive "bypass" data acquisition. The acquisition process, as a third-party observer independent of the business process, can directly access the runtime memory space of the target application without restarting the application, ensuring the purity and performance loss of the business logic stored in the target process. Furthermore, this application breaks through the limitation of traditional JMX interfaces, which can only obtain macroscopic system indicators. By directly reading the full call count raw data maintained in the underlying JVM method object and creatively combining bitwise operation correction mechanisms (such as right shift processing) to remove internal state bits, it accurately restores the actual function call counts, including system automatic calls and dynamically generated proxy methods, significantly improving the granularity and coverage of data acquisition.

[0019] Furthermore, this application constructs a multi-layered security protection system, effectively solving the problem that traditional debugging techniques (SA / JVMTI) cause process pauses or excessive resource consumption, making them unsuitable for production environments. On one hand, this application utilizes the "traffic isolation state" of the application lifecycle (such as release intervals or the eve of decommissioning) as a collection window, using the time after business traffic is cut off to perform full data collection, completely eliminating the impact of debugging pauses (STW) on online services; on the other hand, the system has a built-in dual circuit breaker mechanism for host machine idle memory and target process heap memory, monitoring resource levels in real time throughout the entire collection process, and automatically disconnecting once limits are exceeded, fundamentally ensuring the stability of production services.

[0020] Finally, in conjunction with a Kafka-based dual-channel transmission architecture, this application adopts an asynchronous batch mode to process high-throughput statistical data and uses an independent synchronous channel to transmit abnormal logs, effectively avoiding the blocking of the monitoring system by large-scale data transmission and ensuring the real-time performance, integrity and traceability of data collection tasks in a large-scale cluster environment. Attached Figure Description

[0021] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0022] Figure 1A flowchart illustrating a Java application function call data acquisition method based on JVM-SA technology, provided as an exemplary embodiment of this disclosure;

[0023] Figure 2 A flowchart illustrating another Java application function call data acquisition method based on JVM-SA technology, provided as an exemplary embodiment of this disclosure;

[0024] Figure 3 An exemplary structural diagram of the electronic device provided for some embodiments of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] Figure 1 A flowchart illustrating a Java application function call data acquisition method based on JVM-SA technology, provided as an exemplary embodiment of this disclosure, is included in the method:

[0027] S101. Establish a debugging connection with the target Java application using a collection process independent of the target Java application.

[0028] Specifically, step S101 (establishing a connection) is the starting point of the entire data acquisition process. The data acquisition task is executed by an acquisition process (e.g., an independent component of SA-Agent) that runs independently of the target Java application process. When the triggering conditions are met, the acquisition process first obtains the process identifier (PID) of the target Java application, loads sa-jdi.jar (a core dependency of JVM-SA), creates a HotSpotAgent instance, and establishes a connection with the target process via agent.attach(pid). This process is similar to debugger mounting, establishing a non-intrusive debugging connection from the outside to the inside of the target application. This connection allows the acquisition process to establish an interactive channel without stopping the target application (or causing only a very brief pause).

[0029] S102. Based on the preset collection range, the runtime memory space of the target Java application is directly accessed through the debugging connection to extract the raw data of the full function call count generated by the target Java application during its runtime cycle.

[0030] Specifically, step S102 (data extraction) aims to obtain core data. After establishing a debug connection, the collection process does not blindly scan all memory, but rather performs targeted searches based on a preset collection scope (such as a configured package name whitelist). The collection process traverses the loaded classes by accessing the target JVM's System Dictionary and filters out system classes, framework classes, and other dynamic proxy classes based on the whitelist. For the selected valid business classes, the collection process directly accesses the Method object structure in its runtime memory space. Since the JVM automatically maintains the call status of each method at runtime, the collection process does not need to perform any code instrumentation; it only needs to directly read the Invocation Counter field corresponding to the Method object in memory to extract the raw data of all function call counts generated by the application throughout its entire runtime cycle.

[0031] S103. Based on the parsing rules corresponding to the version of the target Java application, the original function call count data is corrected to obtain the actual function call statistics.

[0032] Specifically, step S103 (correction processing) is a crucial step in ensuring data accuracy. In the implementation mechanisms of mainstream JVMs such as HotSpot, to optimize memory layout, the function call counter does not directly store simple decimal integers. Instead, it compresses and stores the method's runtime status (e.g., whether it has been JIT compiled, whether it was called from the interpreter, etc.) and the call count in the same field. Therefore, the raw data read directly is often too large and contains impurities. In this step, the collection process performs bitwise operation correction processing on the obtained raw count value according to the parsing rules of the target JVM version. After this correction processing, the system successfully restores the true function call statistics that reflect the actual business load.

[0033] S104. Output the actual function call statistics and disconnect the debugging connection.

[0034] Specifically, finally, step S104 (output and disconnect) is executed to complete the data collection loop. The collection process encapsulates the cleaned class names, function signatures, and corrected actual call counts into structured business objects (such as StMethodPo) and serializes them into JSON format. Subsequently, this data is sent asynchronously in batches to the backend processing system through a pre-defined message queue (such as Kafka) data channel for subsequent persistent storage or cumulative analysis. After the data transmission is complete, to ensure that system resources are properly reclaimed and do not affect subsequent operations of the target application (such as destruction or restart), the collection process will actively execute a Detach operation in the finally block to disconnect the debug connection with the target Java application. This action marks the end of a single collection task, releasing not only the debug port but also releasing control over the target process.

[0035] In this embodiment, an independent process acquisition mode based on JVM-SA technology overcomes the shortcomings of existing bytecode enhancement technologies that require modification of business code or implantation of probes, achieving completely non-intrusive "bypass" data acquisition. The acquisition process, acting as a third-party observer independent of the business process, can directly access the runtime memory space of the target application without restarting the application, ensuring the purity and performance loss of the business logic stored in the target process. Furthermore, it overcomes the limitation of traditional JMX interfaces, which can only obtain macroscopic system indicators. By directly reading the full call count raw data maintained in the underlying JVM method objects and creatively combining bitwise operation correction mechanisms (such as right shift processing) to remove internal state bits, it accurately restores the actual function call counts, including system automatic calls and dynamically generated proxy methods, significantly improving the granularity and coverage of data acquisition. In addition, this embodiment constructs a multi-layered security protection system, effectively solving the problem that traditional debugging techniques (SA / JVMTI) cannot be implemented in production environments due to process pauses or excessive resource consumption.

[0036] In one embodiment, establishing a debugging connection with the target Java application using a collection process independent of the target Java application includes:

[0037] Monitor the running status of the target Java application;

[0038] In response to the detection that the target Java application is in a traffic isolation state, the collection process is triggered to establish the debugging connection with the target Java application.

[0039] Specifically, the running status of a target Java application can be tracked in real time through a monitoring module integrated into the application deployment platform or operation and maintenance management system. When the target Java application is detected to have entered a "traffic isolation state" (this state usually occurs during application version rolling updates or offline maintenance), the load balancer has cut off all external business traffic to the application instance, but the application process has not yet been destroyed by the operating system and is still resident in memory—the monitoring module will immediately recognize this safe collection window. In response to the detection of this traffic isolation state, the startup logic will be automatically triggered (e.g., executing the pre-built sa.sh script) to start a collection process independent of the target Java application. This collection process then actively initiates an Attach request to the target process and establishes a debugging connection based on the target application's process identifier (PID) using JVM-SA technology.

[0040] This state-monitoring-based reactive triggering mechanism cleverly utilizes the "garbage time" before the application's lifecycle ends to recycle data. This ensures that the collected data covers all information from the application's entire lifecycle while completely avoiding any jitter risks that debugging operations might cause to online services.

[0041] Furthermore, in one embodiment, the response to detecting that the target Java application is in a traffic isolation state includes:

[0042] Receive trigger commands from the application publishing system;

[0043] The trigger command is issued after the application publishing system cuts off the business traffic of the target Java application and before destroying the process of the target Java application.

[0044] Specifically, this operational process typically occurs during application version iterations or canary releases. When an application is released and a decision is made to update or take a specific application instance offline, it first performs a "traffic pull" operation, instructing the load balancer to stop forwarding new business requests to that instance. At this time, although the target Java application is no longer processing external traffic, its process is not immediately terminated but enters a brief downtime or idle window. It is within this specific time window (i.e., the gap between when business traffic has been cut off and before the operating system executes the process destruction instruction) that the application release system sends an explicit trigger instruction to the host machine (e.g., automatically calling a pre-built startup script). Upon receiving this instruction, it is regarded as a definite signal that the target application is in a "traffic isolation state," and the subsequent SA connection and data collection process is initiated.

[0045] This mechanism ensures that data collection is strictly limited to the end of the application lifecycle, making full use of previously idle system time to complete the full data collection, while avoiding online business interruptions due to misjudgment of status.

[0046] Furthermore, in one embodiment, the step of establishing a debugging connection with the target Java application using a collection process independent of the target Java application in response to detecting that the target Java application is in a traffic isolation state further includes:

[0047] Call the host machine's network status query interface to obtain the transmission control protocol connection information of the business service port bound to the target Java application;

[0048] The number of connections in the established connection state of the business service port is counted; only when the number of connections is zero or only includes connections from the local loopback address is the target Java application confirmed to be in traffic isolation state, and the step of establishing the debug connection is executed;

[0049] Otherwise, refuse to establish a connection and trigger an alarm.

[0050] Specifically, before the data collection process establishes a debug connection, it first calls the host operating system's underlying network status query interface (e.g., executing the netstat command or directly reading the / proc / net / tcp file) to obtain the current Transmission Control Protocol (TCP) connection details of the business service port (e.g., port 8080) bound to the target Java application. The data collection process analyzes this connection information in real time, focusing on the number of connections in the "ESTABLISHED" state and checking the source IP addresses of these connections. It executes strict judgment logic: only when the number of active connections on the business port is zero, or when connections exist but all originate from the local loopback address (e.g., 127.0.0.1, typically used for local health checks), does it confirm at the underlying level that the target application is indeed in a secure "traffic isolation state." Only after this confirmation will the data collection process execute the subsequent JVM-SA mounting and debug connection establishment steps. Conversely, if active business connections from external IPs are still detected, it is determined that the traffic has not been completely cut off. In order to avoid interference with online business caused by forced intervention at this time, the collection process will forcibly refuse to establish a connection and immediately trigger an abnormal alarm, prompting the operation and maintenance personnel to check the load balancing or traffic scheduling configuration.

[0051] In the above embodiments, an innovative responsive data collection mechanism based on "traffic isolation status" is constructed through deep integration with application deployment platforms or operation and maintenance management systems. This mechanism precisely targets the brief idle window before the end of the application's lifecycle as the only safe opportunity for data collection. By triggering SA connections within this specific time window, it obtains "full" function call data during the application's runtime while completely avoiding the jitter risk caused to online services by JVM-SA debugging operations. This strategy enables the safe deployment of high-risk deep memory probing technology in production environments, ensuring zero interference with user experience while achieving complete data recovery.

[0052] Furthermore, to address extreme situations that may occur in the production environment, such as delays in issuing system commands or lag in the effective implementation of load balancing configurations, the system directly calls the host interface to query the TCP connection details of the business ports and executes strict "zero external connections" or "loopback connection only" judgment logic. This allows for a secondary verification of the authenticity of traffic isolation at the underlying factual level. This mechanism is equivalent to adding an objective physical defense line beyond the logical commands, effectively preventing the data collection process from mistakenly intervening in online nodes with real-time traffic due to misjudgments of the upstream system's status. This greatly enhances the robustness and fault tolerance of the automated data collection system in complex production network environments, ensuring that business data stored in memory can only be extracted under absolutely secure conditions.

[0053] In one embodiment, the step of correcting the raw function call count data according to the parsing rules corresponding to the version of the target Java application includes:

[0054] Bitwise operations are performed on the raw function call count data to remove JVM internal state bits and restore the actual function call statistics.

[0055] Specifically, the data directly extracted from the runtime memory of the target Java application is called "raw function call count data." It's important to note that in the underlying implementation of mainstream Java Virtual Machines (such as HotSpot JVM), to optimize memory access efficiency and reuse storage space, the Invocation Counter field in the Method object does not directly store a simple decimal number of calls. The JVM typically reserves several bits in the lower digits of this field to record the method's status (e.g., whether the method has been compiled by the JIT compiler, whether it is in interpreted execution mode, etc.), while storing the actual call count offset to the higher digits. Therefore, the raw value read directly is actually a mixture of the actual call count and internal status bits. If used directly without processing, it will lead to severely distorted statistical results. To address this, this embodiment sets specific parsing rules to perform bitwise operations on the extracted raw data, stripping away lower-order status interference through bit-level processing, thereby restoring the purified business data.

[0056] Furthermore, in one embodiment, performing bitwise operations on the raw data of the function call count specifically includes:

[0057] A bitwise right shift operation of three bits is performed on the raw function call count data to remove the JVM internal state bits and restore the actual function call statistics.

[0058] Specifically, for the specific bitwise operation logic, this embodiment employs a specific algorithm of "right shift by three bits." This is based on the step size mechanism of the JVM's internal counter maintenance: During each function call, the JVM actually increments the counter value by 8 (i.e., binary 1000). This means that the lower 3 bits of the counter value (binary 000 to 111) are reserved for storing the aforementioned internal status bits. Therefore, after acquiring the raw data, the acquisition process performs an arithmetic right shift by three bits (>>3). Mathematically, this operation is equivalent to dividing the original value by 8 and rounding down, accurately discarding the lower 3 bits containing status information and shifting the counter value stored in the higher bits back to the least significant bit. Regardless of whether the target application runs on a 32-bit or 64-bit architecture, or whether pointer compression is enabled, this right shift correction logic ensures that the restored true function call statistics are strictly consistent with the actual number of calls that occurred internally within the JVM.

[0059] In the above embodiments, by introducing a deep parsing and correction mechanism based on bitwise operations, the "numerical distortion" problem encountered when directly reading JVM underlying memory data using SA technology is effectively overcome. Given that mainstream virtual machines such as HotSpot employ a strategy of reusing function call counts and execution status identifiers (such as JIT compilation bits) in the same counter field to optimize memory layout, the directly read raw values ​​often fail to reflect the actual business load. This embodiment creatively utilizes the JVM's internal counter step size of 8, precisely eliminating low-bit state interference through a right-shifting three-bit bitwise operation, successfully restoring the mixed underlying machine data to business statistics accurate to single digits. This processing method not only ensures that the collection accuracy is completely consistent with the actual count inside the JVM, eliminating the error of traditional sampling estimation; at the same time, this specific right-shift correction logic has extremely high environmental robustness, seamlessly adapting to various complex production environment configurations such as 32-bit and 64-bit architectures and enabling pointer compression, ensuring the standardization and reliability of data collected in heterogeneous clusters.

[0060] In one embodiment, before establishing a debugging connection with the target Java application using a collection process independent of the target Java application, a resource pre-check step is further included:

[0061] Get the current free memory capacity of the host machine running the target Java application;

[0062] Determine whether the current free memory capacity is lower than a preset safety threshold;

[0063] If the value is below the security threshold, the debugging connection will be prevented from being established.

[0064] Specifically, to ensure the stability of the production environment host machine and prevent excessive host machine load or even system-level failures caused by the resource consumption of the collection process itself, a host machine resource pre-check step is forcibly executed before officially starting SA-Agent and establishing a debugging connection with the target Java application. Specifically, after the collection process starts, it first obtains a real-time snapshot of the current host machine's memory state by executing system monitoring commands at the operating system level, and parses the total host machine memory capacity and the current free memory capacity. Then, a dynamic safety threshold is calculated based on a preset resource protection algorithm. As a preferred configuration strategy, this threshold is set to 10% of the total host machine memory capacity plus 200MB of fixed reserved space. The real-time obtained current free memory capacity is compared with this calculated safety threshold. If the current free memory capacity is determined to be lower than the safety threshold, it means that the host machine's current resource reserves are insufficient to safely support the operation of an additional debugging process. In this case, to avoid the risk of memory overflow, the circuit breaker protection mechanism will be immediately triggered, forcibly preventing the establishment of a debugging connection and directly terminating the current collection task, thereby prioritizing the availability of other critical business services running on the host machine.

[0065] In one embodiment, the step of directly accessing the runtime memory space of the target Java application through the debugging connection based on a preset collection range includes:

[0066] During the process of traversing the class loading dictionary of the target Java application, the heap memory usage of the target Java application is monitored in real time through the debug connection;

[0067] When the heap memory usage exceeds a preset circuit breaker threshold, the step of extracting the raw data of the function call count is immediately stopped and the debugging connection is disconnected.

[0068] Specifically, considering that traversing massive amounts of class objects using JVM-SA technology may incur additional resource overhead on the target process, a real-time circuit breaker mechanism is incorporated into the core data extraction stage to prevent the collection process itself from causing memory overflow or crashes in the target Java application. When the collection process accesses the target JVM's SystemDictionary via a debug connection to traverse loaded classes, it does not perform a one-time blind scan, but rather adopts a batch processing strategy (e.g., processing 100 classes per check cycle). Within each check cycle, the collection process remotely reads the target Java application's current heap memory allocation and usage details through SA interfaces (such as VM.getVM().getMemoryPoolMXBeans()). The obtained heap memory usage data is then compared in real-time with a preset circuit breaker threshold. As a typical protection strategy, this circuit breaker threshold is usually set to 90% of the target JVM's maximum heap memory capacity. Once the target Java application's heap memory usage exceeds this safety threshold, the target process is determined to be in a high-load or unstable state, and continued collection may lead to serious consequences. At this point, the data acquisition process will immediately trigger the circuit breaker logic, forcibly suspending the current class traversal and function call count extraction steps, and quickly executing the Detach operation to disconnect the debugging connection. This dynamic protection mechanism of "acquiring and monitoring simultaneously" ensures that data acquisition tasks will never come at the expense of the stability of the target application.

[0069] In one embodiment, the preset acquisition range includes:

[0070] Using a whitelist mechanism, data is extracted only from classes whose package names match a preset prefix;

[0071] By using a blacklist mechanism, dynamically generated classes containing preset proxy identifiers are excluded from the classes that match the whitelist;

[0072] The function signature filtering mechanism is used to exclude constructors, class initialization functions, and compiler-generated synthesized functions.

[0073] Specifically, to ensure that the collected data accurately focuses on the business logic that users care about and effectively reduces the consumption of transmission bandwidth and backend storage by invalid data, a sophisticated three-layer filtering funnel mechanism was designed. The first layer is a whitelist mechanism, which allows users to preset the prefix of the business package names they are interested in (e.g., com.example.qa). When the collection process traverses the JVM's system dictionary, it will obtain the fully qualified name of the current class in real time. Only when the class name starts with the preset whitelist prefix will it be included in the scope of collection, thereby automatically eliminating a large number of JDK system libraries (such as java.*) and irrelevant third-party dependency libraries at the source.

[0074] After initial screening using the whitelist, a second-layer blacklist mechanism is activated for further cleaning. Given that modern Java frameworks (such as Spring or Hibernate) often use bytecode technology to dynamically generate helper classes, these classes, although potentially located within business packages, do not carry core business logic. Therefore, the collection process checks whether the class name contains preset proxy identifiers (typical keywords include `$auxiliary$` for helper classes or `CGLIB` for CGLIB dynamic proxies). Once these blacklist features are matched, even if the class meets the whitelist rules, it will be immediately excluded, thus preventing the collection of meaningless framework-generated code.

[0075] Finally, for the identified target business class, the third-level function signature filtering mechanism is implemented. While traversing the method list of this class, the name and signature of each function are parsed, automatically identifying and eliminating non-business logic functions. Specific filtering objects include: Java language-level constructors (methods named...). <init>) and class initialization function (method name) <clinit>This includes compiler-generated lambda expression synthesis functions (usually prefixed with lambda$); and bridge functions (usually prefixed with access$) for inner classes to access private members of outer classes. This filtering ensures that the final output statistics purely reflect the execution of the core business code written by the developers.

[0076] In one embodiment, outputting the actual function call statistics includes:

[0077] The actual function call statistics are encapsulated into a structured object containing the class name, function signature, and number of calls;

[0078] The serialized structured objects are sent to the backend processing system asynchronously in batches via the data channel of the message queue.

[0079] Furthermore, the data acquisition process logs and exception information are sent synchronously through the message queue's log channel; the data channel and the log channel are isolated from each other.

[0080] Specifically, to efficiently process the massive amounts of collected business data and ensure the observability of system operation, a strategy of structured encapsulation and dual-channel isolated transmission was adopted in the data output stage. First, the collection process standardizes and models the corrected real function call statistics, encapsulating them into structured objects (e.g., POJO objects) containing class names, function signatures (precisely describing parameter and return value types), and the actual number of calls. Subsequently, this object is serialized into a lightweight JSON string for network transmission and backend parsing. In terms of transmission architecture, physically isolated "data channels" and "log channels" are built based on message queues (such as Kafka). The encapsulated function call statistics are transmitted through a dedicated data channel. Considering the large volume and high concurrency of this type of data, an asynchronous batch sending mode is adopted for the data channel to maximize network throughput. The data acquisition process temporarily stores the serialized data in a local buffer. A network transmission operation is only triggered when the accumulated data count reaches a preset threshold (e.g., 100 records) or the waiting time exceeds a preset window (e.g., 500ms), significantly reducing the performance overhead of frequent I / O. Simultaneously, to ensure monitoring and troubleshooting capabilities for the acquisition task, a separate log channel is configured to transmit operational logs (e.g., acquisition start / end events) and exception information (e.g., connection timeouts or permission denials) during the acquisition process. Unlike the data channel, the log channel uses a synchronous transmission mode to ensure that every critical diagnostic message is delivered to the backend immediately and reliably, preventing log loss due to buffer overflows or process crashes. This data and log separation design ensures that even under high-load data surge scenarios, critical monitoring alarms can still be reported smoothly and in real-time.

[0081] Furthermore, in one embodiment, the step of directly accessing the runtime memory space of the target Java application through the debugging connection based on a preset collection range, and extracting the raw data of all function call counts generated by the target Java application during its runtime cycle, further includes:

[0082] Access the method metadata area of ​​the target Java application and extract the bytecode instruction length of each target method;

[0083] The output of the actual function call statistics further includes:

[0084] Based on the product of the real function call statistics and the bytecode instruction length, a hotspot density index representing the execution load weight of the method is calculated, and the hotspot density index is associated with the real function call statistics and output.

[0085] Specifically, to more comprehensively evaluate the actual runtime load of the target function and effectively distinguish between "high-frequency lightweight functions" (such as simple property accessors) and "high-frequency heavyweight functions" (the real performance bottlenecks), function metadata is further collected in addition to extracting the call count. The collection process utilizes the deep probing capabilities provided by JVM-SA. When accessing the runtime memory of the target Java application, it not only reads the counter field in the Method object but also further accesses the underlying method metadata area of ​​the object through pointer association (in the HotSpot virtual machine's underlying implementation, this typically corresponds to the ConstMethod structure). In the metadata area, the system directly extracts the "bytecode instruction length" (CodeSize) field, which records the logical complexity of the function body. Based on this metadata dimension, the calculation logic of the "hotspot density index" is introduced in the data processing and output stages. The actual function call statistics (i.e., the actual number of calls) obtained through bitwise operations are multiplied by the bytecode instruction length of the function. The resulting product directly quantifies the "execution load weight" of the function during its runtime. Ultimately, this hotspot density metric is encapsulated and output as a key derived performance parameter, along with the class name, function signature, and basic call count. This mechanism allows backend analytics systems to quickly identify "heavy-load" functions that are frequently called and contain a large amount of computational logic, thus providing more targeted data guidance for code optimization.

[0086] Optionally, the calculation and characterization method performs a hotspot density index for load weights, specifically:

[0087] The hotspot density index is calculated using the following formula: Real function call statistics × Bytecode instruction length × Weight factor; wherein the weight factor is determined based on at least one of the following: the package name of the target method, annotation information, or inheritance relationship.

[0088] Specifically, when the acquisition process uses JVM-SA technology to access the metadata area of ​​the target class, it not only extracts the number of function calls and bytecode length, but also deeply analyzes the context features of the target method. The method pre-configures a weighting strategy, which dynamically determines the weight factor of the method based on at least one of the following: the package name to which the target method belongs (e.g., the core business package com.core.trade is assigned a higher weight of 1.5, while the general utility package com.common.util is assigned a lower weight of 0.8), annotation information (e.g., whether the constant pool contains key business annotations such as @Transactional and @RiskControl; if so, it is assigned a high weight of 2.0), and inheritance relationship (e.g., whether a specific core interface is implemented).

[0089] Based on this, the final weighted calculation logic is executed. The calculation formula is set as: Hotspot density index = Actual function call statistics × Bytecode instruction length × Weighting factor. Through this formula, the data collection process can organically integrate the simple physical execution frequency with the complexity and importance of business logic. For example, for a payment settlement method with moderate call frequency but complex logic and core business annotations, after weighting, its hotspot density index may exceed that of a log printing method with extremely high call frequency but simple logic. Finally, this weighted index is encapsulated and output, allowing subsequent performance analysis to directly focus on those "critical hotspots" that consume resources and have high business value.

[0090] The technical solution provided in this embodiment achieves a leap from the "physical load dimension" to the "business semantic dimension" in code hotspot evaluation by introducing multi-dimensional weighting factors including package name, annotations, and inheritance relationships. Existing technologies typically only mechanically sort hotspots based on call count or execution time, often resulting in a large number of low-level utility classes with no business significance (such as string processing or log concatenation) occupying the top of the alert list, masking the real business bottlenecks. This application, through the aforementioned weighting formula, can intelligently increase the weight of core business logic in performance evaluation based on the package path or metadata markers (such as core transaction annotations), while suppressing interference from non-critical auxiliary code. This mechanism ensures that the output hotspot density index not only reflects the degree of system resource consumption but also the importance of the function in the business chain, thereby helping developers and operations personnel quickly locate the key code segments that truly affect the stability and throughput of core business processes from massive amounts of data, greatly improving the targeting and efficiency of performance optimization.

[0091] Optionally, the method further includes:

[0092] Based on the ratio of the hotspot density index to the actual function call statistics, the average single execution complexity of the method is calculated; the average single execution complexity is correlated with the hotspot density index and output to distinguish between high-frequency lightweight methods and low-frequency heavyweight methods.

[0093] Specifically, the data collection process or backend processing performs a division operation to calculate the ratio between the aforementioned "hotspot density metric" and the "actual function call statistics" (i.e., the number of calls). This ratio is defined as the method's "average execution complexity per run." From a mathematical perspective, this metric effectively eliminates the interference of external business traffic (i.e., call frequency) on hotspot judgment, restoring the inherent logical cost of the method in a single run (primarily determined by bytecode length and business weight). Subsequently, the calculated "average execution complexity per run" and the "hotspot density metric" are correlated, encapsulated, and output.

[0094] In the above embodiments, the joint output of multi-dimensional data provides great convenience for subsequent performance profiling. Through the comparison of these two metrics, the analysis platform can construct an intuitive "frequency-complexity" four-quadrant analysis model: on the one hand, it can quickly filter out those "high-frequency lightweight methods" that although occupy the top of the hot list but have extremely low single-time complexity (such as simple Getter / Setter or status check functions in high-concurrency scenarios), and such methods usually do not require code-level refactoring; on the other hand, it can accurately lock in those "low-frequency heavyweight methods" that although have a small total number of calls but have extremely high single-time execution costs (such as complex report generation or large-volume data settlement logic). This discrimination mechanism helps the architect quickly determine whether the system bottleneck is due to "excessive traffic" or "poor code", so as to formulate differentiated optimization strategies.

[0095] Figure 2 The flowchart of another Java application function call data collection method based on the JVM-SA technology provided by an exemplary embodiment of the present disclosure. Among them, the target Java process: runs the Java business application to be monitored, and the JVM internally natively maintains a function call counter (records the call times of each method) without the need to implant any additional logic. The SA-Agent collector: runs as an independent process (non-invasive to the target process), deeply accesses the internal state of the JVM of the target process based on the JVM-SA technology, completes memory detection, whitelist filtering, call data extraction, and transmits data through Kafka. The back-end processing system: receives the data transmitted by Kafka, completes storage, analysis and visualization, and supports generating function call volume reminders, useless function analysis reports, etc.

[0096] Among them, the SA process manager is the core scheduling module of the collector, responsible for initializing resources, establishing an SA connection, coordinating the collection steps, and ensuring the security of the collection process. The core logic is as follows:

[0097] Parameter verification: Verify the input parameters (such as the target process PID, whitelist package name, Kafka address) at startup. If a parameter is missing or the format is incorrect (such as the PID is not a number), directly terminate the collection and report the log.

[0098] Memory pre-detection: Execute the system command `free |awk ' / ^Mem: / {print $2, $4}'` to obtain the total memory (total) and free memory (free) of the host, and calculate the minimum allowable memory threshold threshold = total * 0.1 + 200 * 1024 * 1024 (unit: byte). If free < threshold, automatically interrupt the collection to avoid occupying the memory resources of the target process.

[0099] SA connection establishment: Load sa-jdi.jar (JVM-SA core dependency), create a HotSpotAgent instance, and establish a non-intrusive connection with the target process through agent.attach(pid) (without affecting the normal operation of the target process).

[0100] Data Acquisition Process Coordination: The `VM.getVM().getSystemDictionary().allClassesDo()` function is called to iterate through all classes loaded in the target process. Class and method data are processed using `SaClassVisitor`, while the acquisition progress is monitored. If processing a single class takes more than 10 seconds, it is marked as an exception and skipped to avoid blocking the overall process. Specifically, the class accessor (`SaClassVisitor`) is used for class traversal and function call data extraction.

[0101] The class accessor implements the JVMSystemDictionary.ClassVisitor interface and is responsible for traversing classes, filtering target methods, and extracting call counts. Its core logic is as follows:

[0102] Class-level filtering (based on a whitelist): Get the class name (klass.getName().asString()), keep only classes under the whitelist package name (such as com.example.qa), filter system classes (such as those starting with java.lang.) and proxy classes (containing the keywords $auxiliary$ and CGLIB), and reduce invalid data collection.

[0103] Method-level filtering: Iterate through all methods of a class (((InstanceKlass)klass).getMethods()), and filter for specific methods:

[0104] Constructor methods and class initialization methods (with <init> 、 <clinit>beginning);

[0105] Composition methods generated by olambda expressions (starting with lambda$);

[0106] Bridge methods (starting with access$) for inner classes to access outer classes.

[0107] Call count extraction: The function call counter value is obtained through the JVM-SA native interface method.getInvocationCount(). Since this value is stored in units of 8 (underlying optimization), it needs to be right-shifted by 3 bits (>>3) to obtain the actual call count, ensuring that the data is completely consistent with the internal state of the JVM.

[0108] Data modeling: Encapsulating the extracted class and method data into structured objects:

[0109] StClassPo (class-level data): includes version number (ver), site identifier (site), class name (klassName), and method list (List). <stmethodpo>);

[0110] StMethodPo (method-level data): includes method name (methodName), method signature (signatureStr, such as (Ljava / lang / String;)V), and invocation count (invocationCount).

[0111] The SA process manager performs memory pre-detection during the initialization phase, and the core mechanism is as follows:

[0112] Target process memory protection: Obtain the target process's memory usage through the JVM-SA interface VM.getVM().getMemoryPoolMXBeans(). If the target process's heap memory usage exceeds 10% + 200M of the system's maximum memory, data sampling will be terminated.

[0113] Furthermore, the data transmission architecture adopts a Kafka dual-channel design.

[0114] Kafka is used to separate the transmission of collected data and log information, avoiding mutual interference and ensuring transmission efficiency in high-concurrency scenarios. The architecture is as follows:

[0115] Data Channel: The topic name format is sa-method-data-{siteName}, used to transmit JSON data serialized by StClassPo. It adopts an asynchronous sending mode and supports batch sending (batch size 100 records, timeout 500ms) to improve transmission efficiency.

[0116] Log channel: The topic name format is sa-system-log-{siteName}, which is used to transmit system logs (such as collection start / end, low memory warning, exception information). The log data is encapsulated as SaLogDto objects (including log level, message content, timestamp). Synchronous sending mode is used to ensure that the logs are not lost.

[0117] Reliability assurance: Kafka producers are configured with acks=1 (at least one partition replica acknowledges receipt), retries=3 (retry 3 times if sending fails), and retry.backoff.ms=1000 (retry interval of 1 second). At the same time, producer pooling management (SaKafkaProducerManager, SaDitingKafkaProducerManager) is implemented to avoid resource leaks caused by frequent connection creation.

[0118] Scope of exception capture: Covers the entire process of parameter validation, SA connection establishment, class traversal, method data extraction, and Kafka sending. All exceptions (including Throwable) are captured uniformly to prevent the collection process from crashing.

[0119] Anomaly reporting and logging: Captured anomalies are reported through the log channel, and simultaneously logged locally in the collection process (path / var / log / sa-agent / , log rolling strategy: split by day, retained for 7 days); if Kafka data channel transmission fails, the data is temporarily stored in a local temporary file ( / tmp / sa-data / ), and retried after Kafka recovers; regardless of whether the collection is successful or failed, resources are released in the finally block: disconnect the SA agent connection (agent.detach()), close the Kafka producer (SaKafkaProducerManager.release()), and delete the temporary file; after a collection failure, collection can be retried via the command-line parameter --retry without reconfiguring parameters.

[0120] A typical deployment configuration example is as follows:

[0121] Environment requirements: JDK 8+, Linux host

[0122] Required dependency: sa-jdi.jar

[0123] Startup command:

[0124] sudo java -cp $JAVA_HOME / lib / sa-jdi.jar:sa-agent.jarcom.example.qa.sa.SAProcess siteName 15201 com.example.qa log_kafka sa_kafka

[0125] Main parameter descriptions:

[0126] siteName: Current sampling application

[0127] 15201: Collect the PID of the target process

[0128] com.example.qa: Whitelist of sampling class packages

[0129] log_kafka and sa_kafka: Kafka logs and function call data; Kafka server addresses.

[0130] Whitelist and filtering rules:

[0131] Only user-defined classes within the whitelisted package are collected, filtering out system classes and proxy classes (such as those containing $auxiliary$, CGLIB, etc.).

[0132] Filtering special / synthetic methods (such as) <init>(prefixes such as lambda$ and access$)

[0133] It supports multi-level filtering configurations to adapt to different business scenarios.

[0134] Memory detection implementation:

[0135] System command: `free |awk ' / ^Mem: / {print $2, $4}'` retrieves the total memory and free memory.

[0136] Memory threshold: Data collection can only proceed when `min(free) ≥ total*10%+200MB`.

[0137] Automatic interruption mechanism: Automatically stop data collection when memory is insufficient to protect the stability of the target application.

[0138] In the above embodiments, the independent process acquisition mode based on JVM-SA technology overcomes the shortcomings of existing bytecode enhancement technologies that require modification of business code or implantation of probes, achieving completely non-intrusive "bypass" data acquisition. The acquisition process, acting as a third-party observer independent of the business process, can directly access the runtime memory space of the target application without restarting the application, ensuring the purity and performance loss of the business logic stored in the target process. Furthermore, this embodiment breaks through the limitation of traditional JMX interfaces, which can only obtain macroscopic system indicators. By directly reading the full call count raw data maintained in the underlying JVM method objects and creatively combining bitwise operation correction mechanisms (such as right shift processing) to remove internal state bits, it accurately restores the actual function call counts, including system automatic calls and dynamically generated proxy methods, significantly improving the granularity and coverage of data acquisition.

[0139] Furthermore, this embodiment constructs a multi-layered security protection system, effectively solving the problem that traditional debugging techniques (SA / JVMTI) cannot be implemented in production environments due to process pauses or excessive resource consumption. On the one hand, this application utilizes the "traffic isolation state" of the application lifecycle (such as release intervals or the eve of shutdown) as a collection window, and uses the time after business traffic is cut off to collect all data, completely eliminating the impact of debugging pauses (STW) on online services; on the other hand, the system has a built-in dual circuit breaker mechanism for host machine idle memory and target process heap memory, which monitors resource levels in real time throughout the entire collection process, and automatically disconnects the connection once the limit is exceeded, fundamentally ensuring the stability of production services.

[0140] Finally, in conjunction with a Kafka-based dual-channel transmission architecture, this embodiment uses an asynchronous batch mode to process high-throughput statistical data and utilizes an independent synchronous channel to transmit exception logs, effectively avoiding the blocking of the monitoring system by large-scale data transmission and ensuring the real-time performance, integrity, and traceability of data collection tasks in a large-scale cluster environment.

[0141] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0142] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 3 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0143] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected by a bus or other means, as shown in the figure, which is connected by a bus.

[0144] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0145] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0146] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0147] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0148] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0149] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0150] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0151] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet through an Internet service provider).

[0152] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0153] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0154] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0155] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first" and "second" are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0156] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.< / init> < / stmethodpo> < / clinit> < / init> < / clinit> < / init>

Claims

1. A method for collecting Java application function call data based on JVM-SA technology, characterized in that, The method includes: Establish a debugging connection with the target Java application using a collection process independent of the target Java application; Based on a preset collection range, the runtime memory space of the target Java application is directly accessed through the debugging connection, including: During the process of traversing the class loading dictionary of the target Java application, the heap memory usage of the target Java application is monitored in real time through the debug connection; When the heap memory usage exceeds the preset circuit breaker threshold, the step of extracting the original function call count data is immediately stopped and the debugging connection is disconnected. Extract the raw function call count data generated by the target Java application during its runtime cycle; according to the parsing rules corresponding to the version of the target Java application, correct the raw function call count data, including: performing bitwise operations on the raw function call count data to remove JVM internal state bits and restore the true function call statistics; obtain the true function call statistics. Access the method metadata area of ​​the target Java application and extract the bytecode instruction length of each target method; Based on the real function call statistics, the bytecode instruction length, and the weight factor, a hotspot density index is calculated. The hotspot density index is equal to the product of the real function call statistics, the bytecode instruction length, and the weight factor. The weight factor is determined based on at least one of the following: the package name of the target method, annotation information, or inheritance relationship. The real function call statistics are output, and the debugging connection is disconnected.

2. The method according to claim 1, characterized in that, The step of establishing a debugging connection with the target Java application using a collection process independent of the target Java application includes: Monitor the running status of the target Java application; In response to the detection that the target Java application is in a traffic isolation state, the collection process is triggered to establish the debugging connection with the target Java application.

3. The method according to claim 1, characterized in that, The preset acquisition range includes: Using a whitelist mechanism, data is extracted only from classes whose package names match a preset prefix; By using a blacklist mechanism, dynamically generated classes containing preset proxy identifiers are excluded from the classes that match the whitelist; The function signature filtering mechanism is used to exclude constructors, class initialization functions, and compiler-generated synthesized functions.

4. The method according to claim 1, characterized in that, The output of the actual function call statistics includes: The actual function call statistics are encapsulated into a structured object containing the class name, function signature, and number of calls; The serialized structured objects are sent to the backend processing system asynchronously in batches via the data channel of the message queue.

5. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 4.

6. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 4.

7. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 4.

Images