A non-fatal heap memory overflow alarm method based on delay processing thread

Abstract

The application provides a non-fatal heap memory overflow alarm method based on a delay processing thread, comprising the following steps: S1: application startup stage completes initialization of an OOM scheduling daemon thread, a bounded blocking queue, a mail client and an object storage client; S2: a global uncaught exception processor is registered, and it is judged whether an exception object is of the OutOfMemoryError type; S3: the OOM scheduling daemon thread responds and executes in delay; S4: an OOM snapshot object is generated, and hierarchical alarm is executed. The application proposes a four-stage light OOM response method of initialization->capture->delay->diagnosis and alarm, which can not only identify a non-fatal OOM scenario in which JVM can still run, but also complete heap dump file detection and alarm linkage, thereby improving the observability, stability and operation and maintenance efficiency of a Java application when OOM occurs.

Description

Technical Field

[0001] This invention relates to the fields of JVM anomaly monitoring and cloud-native observability technology, and in particular to a non-fatal heap memory overflow alarm method based on delayed processing threads. Background Technology

[0002] In Java application operations and maintenance, OutOfMemoryError (OOM) is a common and serious exception. An OOM not only means that the current request cannot be processed normally, but it can also lead to application process crashes, service unavailability, and serious economic losses and a degraded user experience. Therefore, it is necessary to quickly capture, diagnose, and alert when an OOM occurs, while preventing secondary memory crashes caused by the response operation itself. Current mainstream handling methods include: immediately terminating the process when an OOM occurs using the JVM parameter -XX:+ExitOnOutOfMemoryError, relying on the container platform to rebuild the instance; immediately sending an email or uploading a heap dump file after catching the OOM in Thread.UncaughtExceptionHandler; and only enabling -XX:+HeapDumpOnOutOfMemoryError to generate a heap dump file, relying on manual or offline scripts for subsequent processing. However, these methods cannot simultaneously identify non-fatal OOM scenarios where the JVM can still run, and also complete heap dump file detection and alert linkage. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies by proposing a non-fatal heap memory overflow alarm method based on a delayed processing thread.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: a non-fatal heap memory overflow alarm method based on a delayed processing thread, comprising the following steps: S1: During the application startup phase, the initialization of the OOM scheduling daemon thread, bounded blocking queue, email client, and object storage client is completed. S11: When a Java application starts, parse the JVM startup parameters, determine whether the heap dump function is enabled, and determine the expected heap dump file path accordingly. Includes the following sub-steps: S111: If the parameter -XX:+HeapDumpOnOutOfMemoryError is detected, then the flag heapDumpEnabled=true; otherwise, the flag heapDumpEnabled=false. S112: If the heapDumpEnabled flag is true, then further check if -XX:HeapDumpPath= exists.<base_path> parameter; If it exists, then determine<base_path> Does it end with .hprof? If so, then the heap dump file path is...<base_path> Otherwise, treat it as a directory and append / java_${pid}.hprof; If it does not exist, set the heap dump file path to ${user.dir} / java_${pid}.hprof; Where ${pid} is the current Java process ID, and ${user.dir} is the current working directory when the JVM starts; S12: Create an OOM bounded blocking queue to temporarily store the exception thread object and the exception object; Furthermore, the capacity of the OOM bounded blocking queue is 32; S13: Create an OOM scheduling daemon thread, complete initialization during application startup, and set its priority to the highest. S14: Initialize the email client and object storage client; S2: Register a global uncaught exception handler and determine if the exception object is of type OutOfMemoryError; S21: Call the Thread.setDefaultUncaughtExceptionHandler method to register a global uncaught exception handler; S22: When any thread throws an uncaught exception or error during execution and the thread is about to terminate abnormally, the JVM calls back the global uncaught exception handler, which receives the thread object that caused the exception and the exception object. S23: Determine if the exception object is of type OutOfMemoryError; If not, skip; If so, the thread object and exception object are placed in the OOM bounded blocking queue, and the process terminates immediately without performing any memory allocation or I / O operations. S3: The OOM scheduling daemon thread responds and executes with a delay; S31: The OOM scheduling daemon periodically retrieves thread objects and exception objects from the OOM bounded blocking queue; S32: Submit the retrieved thread object and exception object to a delayed task and set the delay time for the delayed task; Furthermore, the delay time is 5 seconds; S4: Generate an OOM snapshot object and execute a tiered alert; S41: Read the thread name, thread group name, and thread status and attributes of the thread object; S42: Obtain the complete execution stack of the thread object. Based on the preset project package path prefix, filter out the thread frames that match the package path from the execution stack and store them in the execution stack string array. Furthermore, the preset project package path prefix is ​​the root package path of the business project; S43: Read the exception type and error message of the exception object; S44: Obtain the complete exception stack of the exception object, and based on the preset project package path prefix, filter out the thread frames belonging to the project package from the exception stack and store them in the exception stack string array. S45: Encapsulate the above fields into an OOM snapshot object; Furthermore, the fields include at least: the thread name, thread group name, and thread state and attributes of the thread object, the complete execution stack, the execution stack string array, the exception type and error message of the exception object, the complete exception stack, and the exception stack string array; S46: Get the application name of the Java application; S47: Determine if the delayed task's heap dump file path exists and issue a tiered warning; If it exists, call the object storage client to upload the heap dump file to the cloud, obtain the download link, confirm that the heap dump file has been successfully uploaded, delete the local heap dump file, and send the OOM snapshot object, download link and application name to the operations and maintenance personnel via email client; Furthermore, the heap dump file is a binary snapshot file; If it does not exist, the OOM snapshot object, application name, and prompt message will be sent to the operations and maintenance personnel via email client; Furthermore, the prompt message indicates that the heap dump file has not been generated and / or please check if the configuration is enabled.

[0005] Compared with existing technologies, the beneficial effects of this invention are as follows: This invention proposes a four-stage lightweight OOM response method: initialization → capture → delay → diagnosis and alarm. This method can identify non-fatal OOM scenarios where the JVM can still run, and can also perform heap dump file detection and alarm linkage, improving the observability, stability, and operational efficiency of Java applications when OOM occurs. During the OOM capture stage, only exception type judgment and enqueueing operations are performed, without any memory allocation or I / O operations, effectively preventing resource exhaustion caused by diagnostic actions in critical memory states, thereby avoiding application avalanche or process exit. During the delayed task execution stage, key snapshots such as thread name, thread group, thread state, complete execution stack, and exception stack are automatically extracted. It intelligently filters irrelevant stack frames based on preset project package path prefixes, ensuring that alarm content focuses on business code and improving root cause location efficiency; by setting a fixed delay time, it allows the JVM sufficient time for GC reclamation and heap dump file writing; combined with a successful upload confirmation mechanism, it ensures that alarm actions are only executed after resources are stable, significantly reducing the alarm failure rate caused by resource contention; the OOM scheduling daemon thread, email client, and object storage client are all initialized during the application startup phase, avoiding the creation of threads or connections after OOM and causing uncontrollable behavior, ensuring a highly reliable response process; it designs structured snapshot objects with controllable memory usage and no original references, fundamentally avoiding the risk of GC pressure or memory leaks caused by snapshots holding large object references. Attached Figure Description

[0006] Figure 1 This is a flowchart of the non-fatal heap memory overflow alarm method based on delayed processing threads according to the present invention. Detailed Implementation

[0007] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0008] Please refer to the reference. Figure 1 This invention provides a non-fatal heap memory overflow alarm method based on a delayed processing thread, comprising the following steps: S1: During the application startup phase, the initialization of the OOM scheduling daemon thread, bounded blocking queue, email client, and object storage client is completed. S11: When a Java application starts, parse the JVM startup parameters, determine whether the heap dump function is enabled, and determine the expected heap dump file path accordingly. Includes the following sub-steps: S111: If the parameter -XX:+HeapDumpOnOutOfMemoryError is detected, then the flag heapDumpEnabled=true; otherwise, the flag heapDumpEnabled=false. S112: If the heapDumpEnabled flag is true, then further check if -XX:HeapDumpPath= exists.<base_path> parameter; If it exists, then determine<base_path> Does it end with .hprof? If so, then the heap dump file path is...<base_path> Otherwise, treat it as a directory and append / java_${pid}.hprof; If it does not exist, set the heap dump file path to ${user.dir} / java_${pid}.hprof; Where ${pid} is the current Java process ID, and ${user.dir} is the current working directory when the JVM starts; S12: Create an OOM bounded blocking queue to temporarily store the exception thread object and the exception object; Furthermore, the capacity of the OOM bounded blocking queue is 32; A bounded blocking queue with a capacity of 32 is used to temporarily store abnormal threads and abnormal objects, which are then consumed asynchronously by a daemon thread, achieving complete decoupling between exception capture and diagnosis. The queue naturally blocks when full, preventing event loss and avoiding prolonged occupation of the producer thread. S13: Create an OOM scheduling daemon thread, complete initialization during application startup, and set its priority to the highest. The OOM scheduling daemon thread is initialized and set to the highest priority during the application startup phase, ensuring that it can respond to OOM events in a timely manner even when the system load is extremely high, thus improving the timeliness of emergency handling. S14: Initialize the email client and object storage client; The OOM scheduling daemon thread, email client, and object storage client are all initialized during the application startup phase to avoid creating threads or connections after an OOM and causing uncontrollable behavior, thus ensuring a highly reliable response process. S2: Register a global uncaught exception handler and determine if the exception object is of type OutOfMemoryError; S21: Call the Thread.setDefaultUncaughtExceptionHandler method to register a global uncaught exception handler; S22: When any thread throws an uncaught exception or error during execution and the thread is about to terminate abnormally, the JVM calls back the global uncaught exception handler, which receives the thread object that caused the exception and the exception object. S23: Determine if the exception object is of type OutOfMemoryError; If not, skip; If so, the thread object and exception object are placed in the OOM bounded blocking queue, and the process terminates immediately without performing any memory allocation or I / O operations. During the OOM capture phase, only exception type judgment and enqueue operation are performed, without any memory allocation or I / O operation. This effectively prevents resource exhaustion caused by diagnostic behavior in critical memory states, thereby avoiding application avalanche or process exit. S3: The OOM scheduling daemon thread responds and executes with a delay; S31: The OOM scheduling daemon periodically retrieves thread objects and exception objects from the OOM bounded blocking queue; S32: Submit the retrieved thread object and exception object to a delayed task and set the delay time for the delayed task; Furthermore, the delay time is 5 seconds; Set a fixed delay time to allow the JVM sufficient time for GC reclamation and heap dump file writing; S4: Generate an OOM snapshot object and execute a tiered alert; S41: Read the thread name, thread group name, and thread status and attributes of the thread object; S42: Obtain the complete execution stack of the thread object. Based on the preset project package path prefix, filter out the thread frames that match the package path from the execution stack and store them in the execution stack string array. Furthermore, the preset project package path prefix is ​​the root package path of the business project; S43: Read the exception type and error message of the exception object; S44: Obtain the complete exception stack of the exception object, and based on the preset project package path prefix, filter out the thread frames belonging to the project package from the exception stack and store them in the exception stack string array. During the delayed task execution phase, key snapshots such as thread name, thread group, thread state, complete execution stack, and exception stack are automatically extracted, and irrelevant stack frames are intelligently filtered based on the preset project package path prefix to ensure that the alarm content focuses on the business code and improve the efficiency of root cause location. S45: Encapsulate the above fields into an OOM snapshot object; Furthermore, the fields include at least: the thread name, thread group name, and thread state and attributes of the thread object, the complete execution stack, the execution stack string array, the exception type and error message of the exception object, the complete exception stack, and the exception stack string array; Design structured snapshot objects with controllable memory usage and no original references to fundamentally avoid GC pressure or memory leak risks caused by snapshots holding large object references; S46: Get the application name of the Java application; S47: Determine if the delayed task's heap dump file path exists and issue a tiered warning; If it exists, call the object storage client to upload the heap dump file to the cloud, obtain the download link, confirm that the heap dump file has been successfully uploaded, delete the local heap dump file, and send the OOM snapshot object, download link and application name to the operations and maintenance personnel via email client; Furthermore, the heap dump file is a binary snapshot file; With the successful upload confirmation mechanism, alarm actions are ensured to be executed only after resources have stabilized, significantly reducing the alarm failure rate caused by resource contention; If it does not exist, the OOM snapshot object, application name, and prompt message will be sent to the operations and maintenance personnel via email client; Furthermore, the prompt message indicates that the heap dump file has not been generated and / or please check if the configuration is enabled.

[0009] This invention proposes a four-stage lightweight OOM response method: initialization → capture → delay → diagnosis and alerting. During application startup, pre-initialization of the daemon thread, bounded blocking queue, email client, and object storage client is completed, ensuring that subsequent response processes do not require runtime creation of large objects, which exacerbates OOM. After the global exception handler captures the OOM, only exception type judgment and enqueueing operations are performed; no diagnosis, I / O, or memory allocation operations are performed, and the process immediately returns, completely offloading the response pressure to the asynchronous thread. After the daemon thread retrieves the exception context from the blocking queue, it submits a delayed execution task, reserving sufficient time for JVM GC reclamation and heap dump file generation. After the delayed task starts, lightweight diagnosis and tiered alerting are uniformly executed, achieving atomic processing of diagnosis and alerting. Zero memory allocation is ensured throughout the exception capture stage. All dependent resources are pre-initialized during startup to avoid secondary crashes caused by dynamic resource creation after an OOM. Snapshot objects do not contain any original Thread or Throwable references, eliminating GC pressure and memory leak risks.

[0010] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A non-fatal heap memory overflow alarm method based on a delayed processing thread, characterized in that: Includes the following steps: S1: During the application startup phase, the initialization of the OOM scheduling daemon thread, bounded blocking queue, email client, and object storage client is completed. S11: When a Java application starts, parse the JVM startup parameters, determine whether the heap dump function is enabled, and determine the expected heap dump file path accordingly. S12: Create an OOM bounded blocking queue to temporarily store the exception thread object and the exception object; S13: Create an OOM scheduling daemon thread, complete initialization during application startup, and set its priority to the highest. S14: Initialize the email client and object storage client; S2: Register a global uncaught exception handler and determine if the exception object is of type OutOfMemoryError; S21: Call the Thread.setDefaultUncaughtExceptionHandler method to register a global uncaught exception handler; S22: When any thread throws an uncaught exception or error during execution and the thread is about to terminate abnormally, the JVM calls back the global uncaught exception handler, which receives the thread object that caused the exception and the exception object. S23: Determine if the exception object is of type OutOfMemoryError; If not, skip; If so, the thread object and exception object are placed in the OOM bounded blocking queue, and the process terminates immediately without performing any memory allocation or I / O operations. S3: The OOM scheduling daemon thread responds and executes with a delay; S31: The OOM scheduling daemon periodically retrieves thread objects and exception objects from the OOM bounded blocking queue; S32: Submit the retrieved thread object and exception object to a delayed task and set the delay time for the delayed task; S4: Generate an OOM snapshot object and issue tiered alerts; S41: Read the thread name, thread group name, and thread status and attributes of the thread object; S42: Obtain the complete execution stack of the thread object. Based on the preset project package path prefix, filter out the thread frames that match the package path from the execution stack and store them in the execution stack string array. The default project package path prefix is ​​the root package path of the business project; S43: Read the exception type and error message of the exception object; S44: Obtain the complete exception stack of the exception object, and based on the preset project package path prefix, filter out the thread frames belonging to the project package from the exception stack and store them in the exception stack string array. S45: Encapsulate the above fields into an OOM snapshot object; S46: Get the application name of the Java application; S47: Determine if the delayed task's heap dump file path exists and issue a tiered warning; If it exists, call the object storage client to upload the heap dump file to the cloud, obtain the OOM scheduling daemon thread download link, confirm that the heap dump file has been successfully uploaded, delete the local heap dump file, and send the OOM snapshot object, the OOM scheduling daemon thread download link and the application name to the operations and maintenance personnel via email client; If it does not exist, the OOM snapshot object, application name, and prompt message will be sent to the operations and maintenance personnel via email client.

2. The non-fatal heap memory overflow alarm method based on delayed processing threads as described in claim 1, characterized in that: Step S11 includes the following sub-steps: S111: If the parameter -XX:+HeapDumpOnOutOfMemoryError is detected, then the flag heapDumpEnabled=true; otherwise, the flag heapDumpEnabled=false. S112: If the heapDumpEnabled flag is true, then further check if -XX:HeapDumpPath= exists.<base_path> parameter; If it exists, then determine<base_path> Does it end with .hprof? If so, then the heap dump file path is...<base_path> Otherwise, treat it as a directory and append / java_${pid}.hprof; If it does not exist, set the heap dump file path to ${user.dir} / java_${pid}.hprof; Where ${pid} is the current Java process ID, and ${user.dir} is the current working directory when the JVM starts.

3. The non-fatal heap memory overflow alarm method based on delayed processing threads as described in claim 1, characterized in that: In step S12, the capacity of the OOM bounded blocking queue is 32.

4. The non-fatal heap memory overflow alarm method based on delayed processing threads as described in claim 1, characterized in that: In step S45, the fields include at least: the thread name, thread group name, thread state and attributes of the thread object, the complete execution stack, the execution stack string array, the exception type and error message of the exception object, the complete exception stack, and the exception stack string array.

5. The non-fatal heap memory overflow alarm method based on delayed processing threads as described in claim 1, characterized in that: In step S47, the heap dump file is a binary snapshot file; the prompt message is that the heap dump file has not been generated and / or please check whether the configuration is enabled.

Images