Thread resource monitoring processing method and apparatus, and storage medium and electronic device

Abstract

The present application relates to the technical field of operating systems. Disclosed are a thread resource monitoring processing method and apparatus, and a storage medium and an electronic device. The method comprises: adaptively adjusting monitoring configuration parameters, so as to obtain dynamic monitoring parameters; on the basis of the dynamic monitoring parameters, analyzing intra-process thread usage information, so as to obtain an anomalous-thread analysis result; and on the basis of resource leakage information in the anomalous-thread analysis result, performing self-recovery with respect to resource leakage. The present application can improve the reliability of thread resource monitoring processing.

Description

Thread resource monitoring and processing methods, devices, storage media and electronic devices

[0001] This application claims priority to Chinese Patent Application No. 202510137535.1, filed on February 7, 2025, entitled “Thread Resource Monitoring and Processing Method, Apparatus, Storage Medium and Electronic Device”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of operating system technology, specifically to a thread resource monitoring and processing method, apparatus, storage medium, and electronic device. Background Technology

[0003] In operating systems like Android, threads are widely used to perform various tasks, including handling user interfaces, network communication, and database operations. Each thread requires a certain amount of thread resources (such as memory and processor time). However, under certain circumstances, threads may experience resource leaks due to improper resource release. These leaks can lead to performance degradation, increased response time, or even crashes in the process. Technical issues

[0004] Some thread resource monitoring and processing methods exist in related technologies, which usually monitor thread resources at the system level. However, the monitoring of thread usage is relatively coarse, and the monitoring process can easily have a negative impact on system performance. Furthermore, it cannot effectively repair thread resource leaks, resulting in weak reliability of thread resource monitoring and processing. Technical solutions

[0005] This application provides a solution that can improve the reliability of thread resource monitoring and processing.

[0006] The embodiments of this application provide the following technical solutions:

[0007] According to one embodiment of this application, a thread resource monitoring and processing method includes: acquiring monitoring configuration parameters and adaptively adjusting the monitoring configuration parameters according to the system running status to obtain dynamic monitoring parameters; performing multi-level thread usage monitoring through the embedded monitoring logic of each process unit at the system level and application level to obtain monitored in-process thread usage information; performing thread anomaly analysis processing on the in-process thread usage information according to the dynamic monitoring parameters to obtain abnormal thread analysis results; and calling a self-repair module to perform resource leak self-repair based on resource leak information in the abnormal thread analysis results.

[0008] In some embodiments of this application, after performing thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters to obtain abnormal thread analysis results, the method further includes: performing hierarchical integration and judgment on the abnormal thread information in the abnormal thread analysis results to obtain abnormal threads to be reported; reporting the thread-related data of the abnormal threads to be reported to the cloud, so that the cloud can perform resource leakage diagnosis and prediction based on the thread-related data to obtain predicted leakage information; receiving the predicted leakage information sent by the cloud, and saving the predicted leakage information to a preset leakage database.

[0009] In some embodiments of this application, the step of performing hierarchical integration and judgment on the abnormal thread information in the abnormal thread analysis results to obtain the abnormal threads to be reported includes: recording the thread information included in the abnormal thread information into corresponding local variables at different levels; comparing local variables and global variables at the same level to obtain the thread information differences between the local variables and the global variables, wherein the global variables are variables used to record the thread information of confirmed abnormal threads; and determining the thread class corresponding to the thread information differences as the abnormal threads to be reported.

[0010] In some embodiments of this application, the dynamic monitoring parameters include a thread count threshold; the abnormal thread analysis results include abnormal thread information; the step of performing thread anomaly analysis processing on the in-process thread usage information based on the dynamic monitoring parameters to obtain abnormal thread analysis results includes: obtaining the total number of threads and the threads started in a single process based on the in-process thread usage information; classifying the threads started in the single process to obtain at least one thread class; if the total number of threads is greater than the thread count threshold, determining whether the number of threads within each thread class is greater than a preset in-class threshold; and identifying the thread information of thread classes with a number of threads within the class greater than the preset in-class threshold as the abnormal thread information.

[0011] In some embodiments of this application, the abnormal thread analysis results also include resource leakage information; the method further includes: comparing the thread monitoring information of thread classes with a number of threads greater than the thread class threshold with preset thread information in a preset leakage library to obtain preset thread information that matches the thread monitoring information; and determining the preset leakage information corresponding to the preset thread information that matches the thread monitoring information as the resource leakage information.

[0012] In some embodiments of this application, the step of adaptively adjusting the monitoring configuration parameters according to the system operating status to obtain dynamic monitoring parameters includes: calculating the system load according to the system operating status; adjusting the thread count threshold in the monitoring configuration parameters according to the system load and a preset threshold adjustment coefficient to obtain an adjusted thread count threshold, wherein the dynamic monitoring parameters include the adjusted thread count threshold.

[0013] In some embodiments of this application, adjusting the thread count threshold in the monitoring configuration parameters according to the system load and a preset adjustment coefficient to obtain the adjusted thread count threshold includes: calculating the adjusted thread count threshold according to the formula Threshold_d = Threshold_0 * (1 + α * Load), where Threshold_d refers to the adjusted thread count threshold, Threshold_0 refers to the thread count threshold in the monitoring configuration parameters, Load refers to the system load, and α refers to the preset threshold adjustment coefficient.

[0014] In some embodiments of this application, the method further includes: adjusting the monitoring frequency in the monitoring configuration parameters according to the system load and a preset frequency adjustment coefficient to obtain an adjusted monitoring frequency, wherein the dynamic monitoring parameters include the adjusted monitoring frequency, so as to perform thread anomaly analysis and processing on the in-process thread usage information according to the adjusted monitoring frequency.

[0015] In some embodiments of this application, the system operating state includes CPU utilization and memory utilization; the calculation of system load based on the system operating state includes: calculating the system load according to the formula Load = w_CPU * CPU_Usage + w_Mem * Memory_Usage, where Load refers to the system load, CPU_Usage refers to the CPU utilization, w_CPU refers to the weighting coefficient of the CPU utilization, Memory_Usage refers to the memory utilization, and w_Mem refers to the weighting coefficient of the memory utilization.

[0016] According to one embodiment of this application, a thread resource monitoring and processing device includes: a parameter module, configured to: acquire monitoring configuration parameters and adaptively adjust the monitoring configuration parameters according to the system running status to obtain dynamic monitoring parameters; a monitoring module, configured to: perform multi-level thread usage monitoring through the embedded monitoring logic of each process unit at the system level and application level to obtain monitored in-process thread usage information; an analysis module, configured to: perform thread anomaly analysis processing on the in-process thread usage information according to the dynamic monitoring parameters to obtain abnormal thread analysis results; and a processing module, configured to: call a self-repair module to perform resource leak self-repair based on resource leak information in the abnormal thread analysis results.

[0017] According to another embodiment of this application, a storage medium stores a computer program thereon, which, when executed by a device's processor, causes the device to perform the methods described in the embodiments of this application.

[0018] According to another embodiment of this application, an electronic device may include: a memory storing a computer program; and a processor reading the computer program stored in the memory to execute the methods described in the embodiments of this application.

[0019] According to another embodiment of this application, a computer program product or computer program includes computer instructions stored in a computer-readable storage medium. A processor of the device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the device to perform the methods provided in the various optional implementations described in the embodiments of this application. Beneficial effects

[0020] In this embodiment, monitoring configuration parameters are obtained and adaptively adjusted according to the system operating status to obtain dynamic monitoring parameters; multi-level thread usage monitoring is performed through the embedded monitoring logic of each process unit at the system level and application level to obtain the monitored in-process thread usage information; thread anomaly analysis is performed on the in-process thread usage information based on the dynamic monitoring parameters to obtain abnormal thread analysis results; and resource leakage information in the abnormal thread analysis results is used to call the self-repair module to perform resource leakage self-repair.

[0021] In this way, multi-level thread usage monitoring is performed through embedded monitoring logic within each process unit at the system and application levels, enabling the monitoring of fine-grained in-process thread usage information. Furthermore, thread anomaly analysis is conducted on this information based on dynamic monitoring parameters. This approach accurately obtains abnormal thread analysis results reflecting thread usage anomalies while effectively avoiding the impact of thread resource monitoring activities on operating system performance and stability. Moreover, a pre-defined self-repair module can be invoked based on resource leak information from the abnormal thread analysis results to effectively self-repair resource leaks. Ultimately, this significantly improves the overall reliability of thread resource monitoring and processing. Attached Figure Description

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

[0023] Figure 1 shows a flowchart of a thread resource monitoring processing method according to an embodiment of this application.

[0024] Figure 2 shows a flowchart of parameter adjustment according to an embodiment of this application.

[0025] Figure 3 shows a flowchart of thread exception analysis according to an embodiment of this application.

[0026] Figure 4 shows a flowchart of intelligent diagnostics according to an embodiment of this application.

[0027] Figure 5 shows a flowchart of the hierarchical integration judgment according to an embodiment of this application.

[0028] Figure 6 illustrates a thread resource monitoring and processing system architecture diagram of an embodiment of this application in a scenario.

[0029] Figure 7 shows a logic embedded flowchart according to an embodiment of this application.

[0030] Figure 8 shows a block diagram of a thread resource monitoring processing apparatus according to an embodiment of the present application.

[0031] Figure 9 shows a block diagram of an electronic device according to an embodiment of this application.

[0032] Implementation methods of this application

[0033] The present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the embodiments provided herein are merely illustrative of the present disclosure and are not intended to limit the present disclosure. Furthermore, the embodiments provided below are some embodiments for implementing the present disclosure, and not all embodiments for implementing the present disclosure. Unless otherwise specified, the technical solutions described in the embodiments of the present disclosure can be implemented in any combination.

[0034] It should be noted that, in the embodiments of this disclosure, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a method or apparatus that includes a list of elements includes not only the elements expressly described, but also other elements not expressly listed, or elements inherent to implementing the method or apparatus. Without further limitations, an element defined by the phrase "comprising a..." does not exclude the presence of other related elements (e.g., steps in the method or units in the apparatus, such as portions of circuitry, processors, programs, or software, etc.) in the method or apparatus that includes that element.

[0035] For example, the thread resource monitoring and processing method provided in this disclosure includes a series of steps, but the thread resource monitoring and processing method provided in this disclosure is not limited to the steps described. Similarly, the thread resource monitoring and processing device provided in this disclosure includes a series of units, but the device provided in this disclosure is not limited to the units explicitly described, and may also include units that need to be set up for obtaining relevant information or processing based on information.

[0036] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of this disclosure.

[0037] It is understood that in the specific implementation of this application, relevant data is involved. When the embodiments in this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0038] Figure 1 schematically illustrates a flowchart of a thread resource monitoring and processing method according to an embodiment of this application. The executing entity of this thread resource monitoring and processing method can be any device with processing capabilities, such as a television, computer, mobile phone, smartwatch, and home appliance, etc.

[0039] As shown in Figure 1, the thread resource monitoring and processing method may include steps S110 to S140.

[0040] Step S110: Obtain monitoring configuration parameters and adaptively adjust the monitoring configuration parameters according to the system operating status to obtain dynamic monitoring parameters;

[0041] Step S120: Multi-level thread usage monitoring is performed through the embedded monitoring logic of each process unit under the system level and application level to obtain the monitored in-process thread usage information.

[0042] Step S130: Perform thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters to obtain abnormal thread analysis results;

[0043] Step S140: Based on the resource leak information in the abnormal thread analysis results, call the self-repair module to perform resource leak self-repair.

[0044] Monitoring configuration parameters are used for thread resource monitoring, such as the timer period required for resource monitoring, thread count thresholds, and unit resource thresholds. System running status refers to the operating system's running status, such as CPU, memory, and thread count. Users can set monitoring configuration parameters, which can be adaptively adjusted in real time based on the system running status to obtain dynamic monitoring parameters more suitable for the system's operating conditions.

[0045] Furthermore, at the system level, each process (i.e., the system process) includes units (such as Bluetooth modules, Wi-Fi modules, and other in-process modules or components) that embed monitoring logic for monitoring thread usage. At the application level, each process (i.e., the application process) also includes units (such as application modules or components) that embed monitoring logic for monitoring thread usage.

[0046] By embedding monitoring logic within each process unit at the system and application levels, fine-grained monitoring of thread usage at the process unit level can be performed at both the system and application levels. This enables multi-level, fine-grained thread usage monitoring at both the system and application levels, obtaining in-process thread usage information for one or more monitored processes. In-process thread usage information refers to the thread usage information of the units within a process, such as the names and number of threads started by the units within the process.

[0047] Furthermore, thread anomaly analysis is performed on the in-process thread usage information based on dynamic monitoring parameters to obtain abnormal thread analysis results. On the one hand, dynamic monitoring parameters are more suitable for the system's operating state, and using dynamic monitoring parameters for processing can effectively avoid the impact of thread resource monitoring activities on the operating system's performance and stability. On the other hand, the in-process thread usage information is obtained through the embedded monitoring logic of each in-process unit at the system level and application level, which can reflect the thread usage in a fine-grained manner, thereby further ensuring the accuracy of abnormal thread analysis results.

[0048] The abnormal thread analysis results reflect information about abnormal thread usage, which may include resource leak information and / or abnormal thread information. The operating system has a pre-defined self-repair module for self-correcting thread resource leaks. Based on the resource leak information in the abnormal thread analysis results, calling the self-repair module can effectively perform resource leak self-correction (e.g., reclaiming leaked resources or migrating leaked resources to other available space), thereby effectively fixing thread resource leak problems.

[0049] In this embodiment of the application, multi-level thread usage monitoring is performed through embedded monitoring logic within each process unit at the system and application levels. This allows for the monitoring of fine-grained in-process thread usage information. Furthermore, thread anomaly analysis is performed on the in-process thread usage information based on dynamic monitoring parameters. This effectively avoids the impact of thread resource monitoring activities on operating system performance and stability, while accurately obtaining abnormal thread analysis results reflecting abnormal thread usage. Moreover, a pre-set self-repair module can be invoked based on resource leak information in the abnormal thread analysis results to effectively perform resource leak self-repair. Therefore, the overall reliability of thread resource monitoring and processing is effectively improved.

[0050] The following describes further optional embodiments of the steps performed during thread resource monitoring in the embodiment shown in Figure 1.

[0051] In one embodiment, referring to Figure 2, the step of adaptively adjusting the monitoring configuration parameters according to the system operating status to obtain dynamic monitoring parameters may include: step S210, calculating the system load according to the system operating status; step S220, adjusting the thread number threshold in the monitoring configuration parameters according to the system load and a preset threshold adjustment coefficient to obtain an adjusted thread number threshold, wherein the dynamic monitoring parameters include the adjusted thread number threshold.

[0052] The thread count threshold in the monitoring configuration parameters is a user-configured threshold used for thread anomaly analysis and handling. This adjusted threshold is determined based on system load and a preset threshold adjustment factor. This adjusted threshold is more suitable for the system's operating conditions and is used during thread anomaly analysis and handling, effectively avoiding the impact of thread resource monitoring activities on operating system performance and stability.

[0053] In one embodiment, the system operating status includes CPU utilization and memory utilization; the calculation of system load based on the system operating status may specifically include: calculating the system load according to the formula Load = w_CPU * CPU_Usage + w_Mem * Memory_Usage, where Load refers to the system load, CPU_Usage refers to the CPU utilization, w_CPU refers to the weighting coefficient of the CPU utilization, Memory_Usage refers to the memory utilization, and w_Mem refers to the weighting coefficient of the memory utilization.

[0054] The system load is calculated using the formula Load = w_CPU * CPU_Usage + w_Mem * Memory_Usage. This system load is used to adjust the thread count threshold in the monitoring configuration parameters. When the adjusted thread count threshold is obtained, the thread count threshold can be flexibly and reliably adjusted to better suit the state of the central processing unit (CPU) and memory during system operation, thereby effectively avoiding the impact of thread resource monitoring activities on the operating system performance and stability.

[0055] The weighting coefficients for CPU utilization (w_CPU) and memory utilization (w_Mem) can be set according to actual conditions, and must satisfy w_CPU + w_Mem = 1. In some examples, since CPU load has a greater impact on thread resources than memory load, w_CPU can be greater than w_Mem.

[0056] Optionally, in some other embodiments, the system operating status includes CPU utilization and memory utilization; the calculation of system load based on the system operating status may include: System load = predetermined total system load - unused system resources.

[0057] In one embodiment, adjusting the thread count threshold in the monitoring configuration parameters according to the system load and a preset adjustment coefficient to obtain the adjusted thread count threshold may specifically include: calculating the adjusted thread count threshold according to the formula Threshold_d = Threshold_0 * (1 + α * Load), where Threshold_d refers to the adjusted thread count threshold, Threshold_0 refers to the thread count threshold in the monitoring configuration parameters, Load refers to the system load, and α refers to the preset threshold adjustment coefficient.

[0058] The adjusted thread count threshold Threshold_d is calculated using the formula Threshold_d = Threshold_0 * (1 + α * Load). This effectively adjusts the thread count threshold in the monitoring configuration parameters based on system load and preset adjustment coefficients. The adjusted thread count threshold Threshold_d is used in thread anomaly analysis and processing, which can effectively avoid the impact of thread resource monitoring and processing activities on operating system performance and stability.

[0059] The preset threshold adjustment coefficient α can be set according to the actual situation. The range of α can be 0 < α ≤ 1. For example, if the actual online project of the system has good performance and large running memory, the α can be increased, and vice versa.

[0060] Furthermore, in one embodiment, the step of adaptively adjusting the monitoring configuration parameters according to the system operating status to obtain dynamic monitoring parameters may further include:

[0061] The monitoring frequency in the monitoring configuration parameters is adjusted according to the system load and the preset frequency adjustment coefficient to obtain the adjusted monitoring frequency. The dynamic monitoring parameters include the adjusted monitoring frequency, so as to perform thread anomaly analysis and processing on the thread usage information in the process according to the adjusted monitoring frequency.

[0062] The monitoring frequency in the monitoring configuration parameters is adjusted based on system load and a preset frequency adjustment factor to obtain the adjusted monitoring frequency. Thread anomaly analysis and processing of in-process thread usage information is then performed based on this adjusted monitoring frequency, which can further effectively avoid the impact of thread resource monitoring activities on operating system performance and stability. Specifically, thread anomaly analysis and processing of in-process thread usage information is performed based on this adjusted monitoring frequency. For example, if the adjusted monitoring frequency is once every S hours, then thread anomaly analysis and processing of in-process thread usage information can be performed once every S hours.

[0063] Furthermore, the monitoring frequency in the monitoring configuration parameters is adjusted according to the system load and the preset frequency adjustment coefficient to obtain the adjusted monitoring frequency. This can be achieved by calculating the adjusted thread count threshold according to the formula P_d = P_0 * (1 + β * Load), where P_d refers to the adjusted monitoring frequency, P_0 refers to the monitoring frequency in the monitoring configuration parameters, Load refers to the system load, and β refers to the preset frequency adjustment coefficient.

[0064] In one embodiment, referring to Figure 3, the dynamic monitoring parameters include a thread count threshold; the abnormal thread analysis result includes abnormal thread information; the step of performing thread anomaly analysis processing on the in-process thread usage information based on the dynamic monitoring parameters to obtain the abnormal thread analysis result may include:

[0065] Step S310: Obtain the total number of threads and the threads started in a single process based on the in-process thread usage information; Step S320: Classify the threads started in the single process to obtain at least one thread class; Step S330: If the total number of threads is greater than the thread count threshold, determine whether the number of threads within each thread class is greater than a preset in-class threshold; Step S340: Identify the thread information of thread classes with a number of threads within the class greater than the preset in-class threshold as abnormal thread information.

[0066] The in-process thread usage information for each process can include the total number of threads started within a single process and the names of the started threads. The threads started within a single process are classified into at least one thread class. For example, the 200 threads started in process 1 can be divided into a first thread class and a second thread class. The first thread class can include 50 threads, and the second thread class can include 150 threads.

[0067] If the total number of threads exceeds a thread count threshold, it indicates that the threads within that single process are suspected of being abnormal. Further, it checks whether the number of threads within each thread class exceeds a preset threshold. If the number of threads within a thread class exceeds the preset threshold, it indicates that that thread class is abnormal. For example, if the first thread class has 50 threads, and the preset threshold is 32, then the first thread class is abnormal.

[0068] This method can accurately identify abnormal thread classes (i.e., thread classes with more than a preset threshold number of threads, which are highly likely to have thread resource leaks). The thread information of these thread classes with more than the preset threshold is then identified as abnormal thread information, allowing for further accurate resource leak analysis. The thread information for each thread class can include at least the thread identifiers, such as the names of the threads within the class.

[0069] In one implementation, the threads started within the single process are classified to obtain at least one thread class. Specifically, threads started within the single process that have the same thread name body are grouped into one class to obtain at least one thread class. For example, threads with the thread name Thread-1 and threads with the thread name Thread-ABC that have the same thread name body Thread can be classified into a thread class (Thread class), and the number of threads in this Thread class is 2.

[0070] Furthermore, the abnormal thread analysis results also include resource leakage information; the method further includes: comparing the thread monitoring information of thread classes with a number of threads greater than the thread class threshold with preset thread information in a preset leakage library to obtain preset thread information that matches the thread monitoring information; and determining the preset leakage information corresponding to the preset thread information that matches the thread monitoring information as the resource leakage information.

[0071] The preset leak database stores preset leak information and corresponding preset thread information. Preset leak information can be resource leak points, and preset thread information can be preset tracking data or preset log-related data of the thread that caused the resource leak point. By comparing the thread monitoring information (currently monitored tracking data or log-related data) of thread classes with a determined number of threads greater than the thread class threshold with the preset thread information in the preset leak database, the preset thread information matching the thread monitoring information can be obtained (that is, the resource leak scenario corresponding to the thread monitoring information is the same as the resource leak scenario corresponding to the preset thread information). Therefore, the preset leak information corresponding to the preset thread information matching the thread monitoring information can be determined as resource leak information. Based on this resource leak information, the self-repair module can be invoked to perform resource leak self-repair at the resource leak point indicated by the resource leak information.

[0072] Furthermore, in one embodiment, referring to Figure 4, after performing thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters to obtain the abnormal thread analysis result, the method may further include: step S410, performing hierarchical integration and judgment on the abnormal thread information in the abnormal thread analysis result to obtain the abnormal thread to be reported; step S420, reporting the thread-related data of the abnormal thread to be reported to the cloud, so that the cloud can perform resource leakage diagnosis and prediction based on the thread-related data to obtain predicted leakage information; step S430, receiving the predicted leakage information sent by the cloud and saving the predicted leakage information to a preset leakage database.

[0073] The abnormal thread information in the abnormal thread analysis results may include thread information of thread classes within processes at the system level (i.e., system processes) and thread information of thread classes within processes at the application level (i.e., application processes).

[0074] The abnormal thread information in the abnormal thread analysis results is integrated and judged hierarchically. That is, the thread information of the system process is integrated and judged according to the integration and judgment method corresponding to the system level, and / or the thread information of the application process is integrated and judged according to the integration and judgment method corresponding to the application level. By integrating and judging hierarchically, the abnormal thread information at the system level and the application level can be judged separately, which effectively ensures the accuracy of the judgment. Thus, the abnormal threads to be reported to the cloud for further intelligent diagnosis can be accurately identified through hierarchical integration and judgment. The abnormal threads to be reported can be thread classes enabled by units within the system process and / or thread classes enabled by units within the application process.

[0075] The thread-related data (such as data points or log data) of the abnormal thread to be reported is reported to the cloud. The cloud can use an AI diagnostic prediction model to perform resource leakage diagnosis and prediction based on the thread-related data to obtain predicted leakage information. The predicted leakage information can include the predicted resource leakage points and corresponding remediation suggestions. The cloud then sends the predicted leakage information obtained from the diagnosis and prediction to the device.

[0076] The device receives predicted leakage information from the cloud and saves the predicted leakage information as preset leakage information in the preset leakage database. In the future, if a thread class with more than the number of threads in the class is found to be an abnormal thread to be reported, the device can match the preset leakage information of the abnormal thread to be reported from the preset leakage database and call the self-repair module to perform efficient and accurate self-repair of the predicted resource leakage point based on the preset leakage information.

[0077] Furthermore, in one embodiment, referring to Figure 5, the hierarchical integration and judgment of the abnormal thread information in the abnormal thread analysis results to obtain the abnormal threads to be reported may specifically include: step S510, recording the thread information included in the abnormal thread information into corresponding local variables at different levels; step S520, comparing local variables and global variables at the same level to obtain the thread information differences between the local variables and the global variables, wherein the global variables are variables used to record the thread information of confirmed abnormal threads; step S530, determining the thread class corresponding to the thread information differences as the abnormal threads to be reported.

[0078] The thread information included in the abnormal thread information is recorded in the corresponding local variables at different levels. For example, the thread information of the thread class used by the in-process unit under the system level is recorded in the local variable mapA, and the thread information of the thread class used by the in-process unit under the application level is recorded in the local variable mapB.

[0079] At the system level, a corresponding global variable `mContrastSystemMap` is set. This global variable `mContrastSystemMap` records thread information for confirmed abnormal threads at the system level (i.e., thread classes whose corresponding preset leak information can be matched from the preset leak database). At the application level, a corresponding global variable `mContrastApplicationMap` is set. This global variable `mContrastApplicationMap` records thread information for confirmed abnormal threads at the application level (i.e., thread classes whose corresponding preset leak information can be matched from the preset leak database).

[0080] By comparing local and global variables at the same level, we can obtain the thread information that differs between the local and global variables. For example, by comparing the local variable mapA and the global variable mContrastSystemMap, we can determine the thread information 1 that differs from the global variable mContrastSystemMap. The thread information 1 differs from the global variable mContrastSystemMap and is the thread information that exists in the local variable mapA but does not exist in the global variable mContrastSystemMap.

[0081] The thread class corresponding to the discrepancy in thread information is a newly emerging problematic thread class that cannot be matched with the corresponding preset leak information in the preset leak database. By identifying the thread class corresponding to the discrepancy in thread information as the abnormal thread to be reported, an AI diagnostic prediction model can be used in the cloud to perform resource leak diagnosis and prediction based on its thread-related data to obtain predicted leak information. Based on this predicted leak information, the self-repair module can be invoked to self-repair the predicted resource leak point in the predicted leak information.

[0082] To facilitate better implementation of the thread resource monitoring and processing method provided in the embodiments of this application, the following describes the process and system architecture of thread resource monitoring and processing using the aforementioned embodiments of this application in a specific scenario. The meanings of the terms used are the same as in the thread resource monitoring and processing method described above, and specific implementation details can be found in the descriptions within the method embodiments. Figure 6 shows the system architecture diagram of the thread resource monitoring and processing system using the embodiments of this application in this scenario.

[0083] Referring to Figure 6, the thread resource monitoring and processing system may include a device 610 and a cloud 620. The device 610 may include a framework layer 611 and a native layer 612. The framework layer may include embedded monitoring logic 6111 and communication services 6112 within each process unit. The native layer 621 may include a client (HeClient) 6121, a server (HeServer) 6122, and a self-healing module 62123 of the system-wide anomaly monitoring and processing toolkit (which may be represented as HERA SDK). The client 6121 and server 6122 can communicate via sockets, as can the server 6122 and the self-healing module 6123. The server 6122 may include a daemon process, a multi-level alarm mechanism, main processing function modules, adaptive monitoring strategies, and a database. The cloud 620 may include a dynamic configuration service, a data receiving module, a model training module, and an intelligent diagnostic engine.

[0084] The process of monitoring and processing thread resources based on this thread resource monitoring and processing system may specifically include steps (1) to (5).

[0085] (1) The device determines whether the dynamic configuration service in the cloud is enabled through the communication service 6112. If enabled, the device obtains the monitoring configuration parameters configured by the user from the dynamic configuration service in the cloud through the communication service 6112, and transmits the monitoring configuration parameters to the daemon process in the server 6212 via the client 6211 through the communication service 6112. Among them, the device can obtain the monitoring configuration parameters configured by the user from the dynamic configuration service through the communication service 6112 according to the time interval corresponding to the timer.

[0086] (2) Start the adaptive monitoring strategy in server 6212. The adaptive monitoring strategy periodically adjusts the monitoring configuration parameters according to the system running status to obtain dynamic monitoring parameters, and can synchronize the dynamic monitoring parameters to the database.

[0087] The process of adaptively adjusting monitoring configuration parameters based on system operating status to obtain dynamic monitoring parameters may include: calculating system load based on system operating status; adjusting the thread count threshold in the monitoring configuration parameters based on system load and a preset threshold adjustment coefficient to obtain the adjusted thread count threshold, and the dynamic monitoring parameters include the adjusted thread count threshold.

[0088] The system operating status includes CPU utilization and memory utilization. The system load is calculated based on the system operating status, specifically by using the formula Load = w_CPU * CPU_Usage + w_Mem * Memory_Usage, where Load refers to the system load, CPU_Usage refers to the CPU utilization, w_CPU refers to the weighting coefficient of the CPU utilization, Memory_Usage refers to the memory utilization, and w_Mem refers to the weighting coefficient of the memory utilization.

[0089] The thread count threshold in the monitoring configuration parameters is adjusted based on the system load and a preset adjustment coefficient to obtain the adjusted thread count threshold. Specifically, the adjusted thread count threshold can be calculated using the formula Threshold_d = Threshold_0 * (1 + α * Load), where Threshold_d refers to the adjusted thread count threshold, Threshold_0 refers to the thread count threshold in the monitoring configuration parameters, Load refers to the system load, and α refers to the preset threshold adjustment coefficient.

[0090] The monitoring configuration parameters are adaptively adjusted according to the system operating status to obtain dynamic monitoring parameters. It may also include: adjusting the monitoring frequency in the monitoring configuration parameters according to the system load and a preset frequency adjustment coefficient to obtain an adjusted monitoring frequency. The dynamic monitoring parameters include the adjusted monitoring frequency, so as to perform thread anomaly analysis and processing on the thread usage information in the process according to the adjusted monitoring frequency.

[0091] (3) Multi-level thread usage monitoring is performed through the embedded monitoring logic 6111 of each process unit in the system layer and application layer in the framework layer to obtain the monitored thread usage information in the process; the embedded monitoring logic transmits the monitored thread usage information in the process to the daemon process in the server 6212 through the communication service 6112 via the client 6211.

[0092] At the system level, each process (i.e., the system process) contains embedded monitoring logic within its units (such as Bluetooth modules, Wi-Fi modules, and other in-process modules or components) for monitoring thread usage. Similarly, at the application level, each process (i.e., the application process) contains embedded monitoring logic within its units (such as application modules or components) for monitoring thread usage.

[0093] Referring to Figure 7, the specific method for implementing the embedded monitoring logic in each unit may include: step S710, defining the thread monitoring interface corresponding to each unit; step S720, implementing the embedded monitoring logic corresponding to each unit; and step S730, connecting the corresponding embedded monitoring logic to each unit (module or component). Specifically, in step S710, interfaces for recording thread startup (onThreadStart(String moduleName, String threadName)), recording thread shutdown (onThreadFinish(String moduleName, String threadName)), and printing thread usage (i.e., thread usage log) can be defined, where moduleName is the name of the unit and threadName is the name of the thread. In step S720, the embedded monitoring logic for recording thread startup (onThreadStart method), recording thread shutdown (onThreadFinish method), and printing thread usage (logThreadUsage method) is implemented; in step S730, the above embedded monitoring logic is connected to the unit.

[0094] When the monitoring logic embedded in each unit detects that the number of threads used in its unit exceeds the reporting threshold, it can transmit the monitored thread usage information within the process to the daemon process in the server 6212 via the communication service 6112 and the client 6211.

[0095] (4) Through a multi-level alarm mechanism: perform thread anomaly analysis on the thread usage information in the process based on dynamic monitoring parameters, obtain the abnormal thread analysis results, and pass the abnormal thread analysis results to the main processing function module.

[0096] The abnormal thread analysis results include abnormal thread information; based on the dynamic monitoring parameters, the thread usage information within the process is analyzed to obtain abnormal thread analysis results, which may include: obtaining the total number of threads and the threads started in a single process based on the thread usage information within the process; classifying the threads started in a single process to obtain at least one thread class; if the total number of threads is greater than the thread count threshold, determining whether the number of threads within each thread class is greater than a preset class threshold; and identifying the thread information of thread classes with a number of threads within the class greater than the preset class threshold as abnormal thread information.

[0097] To classify threads started within a single process, at least one thread class can be obtained. Specifically, threads with the same thread name body can be grouped together to obtain at least one thread class. For example, threads named Thread-1 and Thread-ABC with the same thread name body Thread can be classified into a thread class (Thread class), and the number of threads in this Thread class will be 2.

[0098] The abnormal thread analysis results also include resource leak information; based on the dynamic monitoring parameters, the thread usage information within the process is analyzed for abnormal thread behavior to obtain abnormal thread analysis results, which may further include: comparing the thread monitoring information of thread classes with a number of threads greater than the thread class threshold with preset thread information in a preset leak library to obtain preset thread information that matches the thread monitoring information; and determining the preset leak information corresponding to the preset leak information that matches the thread monitoring information as resource leak information.

[0099] (5) Main processing function module: Based on the resource leakage information in the abnormal thread analysis results, call the self-repair module to perform resource leakage self-repair; perform hierarchical integration and judgment on the abnormal thread information in the abnormal thread analysis results to obtain the abnormal threads to be reported; report the thread-related data of the abnormal threads to be reported to the cloud so that the cloud can perform resource leakage diagnosis and prediction based on the thread-related data to obtain predicted leakage information; receive the predicted leakage information sent by the cloud and save the predicted leakage information to the preset leakage database.

[0100] The abnormal thread information in the abnormal thread analysis results is integrated and judged hierarchically to obtain the abnormal threads to be reported. Specifically, this may include: recording the thread information included in the abnormal thread information into the corresponding local variables at different levels; comparing the local variables and global variables at the same level to obtain the thread information that differs between the local variables and global variables, where the global variables are used to record the thread information of confirmed abnormal threads; and determining the thread class corresponding to the thread information that differs as the abnormal thread to be reported.

[0101] For example, thread information of thread classes used by in-process units at the system level is recorded in local variable `mapA`, and thread information of thread classes used by in-process units at the application level is recorded in local variable `mapB`. A corresponding global variable `mContrastSystemMap` is set at the system level, recording thread information of confirmed abnormal threads at the system level (i.e., thread classes whose corresponding preset leak information can be matched from the preset leak database). A corresponding global variable `mContrastApplicationMap` is set at the application level, recording thread information of confirmed abnormal threads at the application level (i.e., thread classes whose corresponding preset leak information can be matched from the preset leak database). By comparing local and global variables at the same level, the thread information differences between the local and global variables are obtained. For example, comparing local variable `mapA` and global variable `mContrastSystemMap` identifies thread information difference 1, which is thread information that exists in local variable `mapA` but not in global variable `mContrastSystemMap`.

[0102] The cloud-based intelligent diagnostic engine employs an AI diagnostic prediction model to diagnose and predict resource leaks based on thread-related data, obtaining predicted leak information. This predicted leak information may include predicted resource leak points and corresponding remediation suggestions. The cloud then distributes the predicted leak information to the devices. The cloud receives thread-related data through a data receiving module.

[0103] In this scenario, applying the embodiments of this application for thread resource monitoring has at least the following beneficial effects: Multi-level thread usage monitoring is performed through embedded monitoring logic within each process unit at the system and application levels, enabling the monitoring of fine-grained in-process thread usage information; furthermore, thread anomaly analysis is performed on the in-process thread usage information based on dynamic monitoring parameters, accurately obtaining abnormal thread analysis results reflecting abnormal thread usage while effectively avoiding the impact of thread resource monitoring activities on operating system performance and stability; furthermore, through a preset self-repair module, resource leak self-repair can be effectively performed by calling the self-repair module based on resource leak information in the abnormal thread analysis results. Therefore, the overall reliability of thread resource monitoring is effectively improved.

[0104] To facilitate better implementation of the thread resource monitoring and processing method provided in the embodiments of this application, this application also provides a thread resource monitoring and processing device based on the above-described thread resource monitoring and processing method. The meanings of the terms used are the same as in the above-described thread resource monitoring and processing method, and specific implementation details can be found in the descriptions in the method embodiments. Figure 8 shows a block diagram of a thread resource monitoring and processing device according to an embodiment of this application.

[0105] As shown in Figure 8, the thread resource monitoring and processing device 800 may include: a parameter module 810 for acquiring monitoring configuration parameters and adaptively adjusting the monitoring configuration parameters according to the system running status to obtain dynamic monitoring parameters; a monitoring module 820 for performing multi-level thread usage monitoring through the embedded monitoring logic of each process unit at the system level and application level to obtain monitored in-process thread usage information; an analysis module 830 for performing thread anomaly analysis processing on the in-process thread usage information based on the dynamic monitoring parameters to obtain abnormal thread analysis results; and a processing module 840 for calling the self-repair module to perform resource leak self-repair based on the resource leak information in the abnormal thread analysis results.

[0106] In some embodiments of this application, after performing thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters to obtain abnormal thread analysis results, the device further includes a prediction module, configured to: perform hierarchical integration and judgment on the abnormal thread information in the abnormal thread analysis results to obtain abnormal threads to be reported; report the thread-related data of the abnormal threads to be reported to the cloud, so that the cloud can perform resource leakage diagnosis and prediction based on the thread-related data to obtain predicted leakage information; receive the predicted leakage information sent by the cloud, and save the predicted leakage information to a preset leakage database.

[0107] In some embodiments of this application, the prediction module is configured to: record the thread information included in the abnormal thread information into corresponding local variables at different levels; compare the local variables and global variables at the same level to obtain the thread information difference between the local variables and the global variables, wherein the global variables are variables used to record the thread information of confirmed abnormal threads; and determine the thread class corresponding to the thread information difference as the abnormal thread to be reported.

[0108] In some embodiments of this application, the dynamic monitoring parameters include a thread count threshold; the abnormal thread analysis results include abnormal thread information; the analysis module can be used to: obtain the total number of threads and the threads started in a single process based on the thread usage information within the process; classify the threads started in the single process to obtain at least one thread class; if the total number of threads is greater than the thread count threshold, determine whether the number of threads within each thread class is greater than a preset intra-class threshold; and identify the thread information of thread classes whose intra-class thread count is greater than the preset intra-class threshold as the abnormal thread information.

[0109] In some embodiments of this application, the abnormal thread analysis results also include resource leakage information; the analysis module can be used to: compare the thread monitoring information of thread classes with a number of threads greater than the thread class threshold with preset thread information in a preset leakage library to obtain preset thread information that matches the thread monitoring information; and determine the preset leakage information corresponding to the preset thread information that matches the thread monitoring information as the resource leakage information.

[0110] In some embodiments of this application, the parameter module can be used to: calculate the system load based on the system operating status; adjust the thread count threshold in the monitoring configuration parameters based on the system load and a preset threshold adjustment coefficient to obtain an adjusted thread count threshold, wherein the dynamic monitoring parameters include the adjusted thread count threshold.

[0111] In some embodiments of this application, the parameter module can be used to: calculate the adjusted thread count threshold according to the formula Threshold_d=Threshold_0*(1+α*Load), where Threshold_d refers to the adjusted thread count threshold, Threshold_0 refers to the thread count threshold in the monitoring configuration parameters, Load refers to the system load, and α refers to the preset threshold adjustment coefficient.

[0112] In some embodiments of this application, the parameter module can be used to: adjust the monitoring frequency in the monitoring configuration parameters according to the system load and a preset frequency adjustment coefficient to obtain an adjusted monitoring frequency, wherein the dynamic monitoring parameters include the adjusted monitoring frequency, so as to perform thread anomaly analysis and processing on the in-process thread usage information according to the adjusted monitoring frequency.

[0113] In some embodiments of this application, the system operating status includes CPU utilization and memory utilization; the parameter module can be used to calculate the system load according to the formula Load = w_CPU * CPU_Usage + w_Mem * Memory_Usage, where Load refers to the system load, CPU_Usage refers to the CPU utilization, w_CPU refers to the weighting coefficient of the CPU utilization, Memory_Usage refers to the memory utilization, and w_Mem refers to the weighting coefficient of the memory utilization.

[0114] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0115] Furthermore, this application also provides an electronic device, as shown in FIG9, which is a block diagram of an electronic device according to an embodiment of this application. Specifically:

[0116] The electronic device may include components such as a processor 901 with one or more processing cores, a memory 902 with one or more computer-readable storage media, a power supply 903, and an input unit 904. Those skilled in the art will understand that the electronic device structure shown in FIG9 does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0117] The processor 901 is the control center of the electronic device. It connects to various parts of the computer device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 902, and by calling data stored in the memory 902, it performs various functions of the computer device and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 901 may include one or more processing cores; preferably, the processor 901 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user page, and application programs, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 901.

[0118] The memory 902 can be used to store software programs and modules. The processor 901 executes various functional applications and data processing by running the software programs and modules stored in the memory 902. The memory 902 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 902 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 902 may also include a memory controller to provide the processor 901 with access to the memory 902.

[0119] The electronic device also includes a power supply 903 that supplies power to various components. Preferably, the power supply 903 can be logically connected to the processor 901 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 903 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0120] The electronic device may also include an input unit 904, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0121] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 901 in the electronic device loads the executable files corresponding to the processes of one or more computer programs into the memory 902 according to the following instructions, and the processor 901 runs the computer programs stored in the memory 902, thereby realizing the various functions in the foregoing embodiments of this application. For example, the processor 901 can perform the following steps:

[0122] The system acquires monitoring configuration parameters and adaptively adjusts these parameters based on the system's operating status to obtain dynamic monitoring parameters. It then performs multi-level thread usage monitoring through embedded monitoring logic within each process unit at the system and application levels to obtain monitored in-process thread usage information. Based on the dynamic monitoring parameters, it performs thread anomaly analysis on the in-process thread usage information to obtain abnormal thread analysis results. Finally, based on resource leak information in the abnormal thread analysis results, it calls a self-repair module to perform resource leak self-repair.

[0123] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by a computer program, or by a computer program controlling related hardware. The computer program can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0124] Therefore, embodiments of this application also provide a storage medium storing a computer program that can be loaded by a processor to execute the steps in any of the methods provided in embodiments of this application.

[0125] The storage medium can be a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0126] Since the computer program stored in the storage medium can execute the steps of any of the methods provided in the embodiments of this application, the beneficial effects that the methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0127] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0128] It should be understood that this application is not limited to the embodiments described above and shown in the accompanying drawings, but various modifications and changes can be made without departing from its scope.

Claims

1. A method for monitoring and processing thread resources, wherein, include: The monitoring configuration parameters are obtained, and the monitoring configuration parameters are adaptively adjusted according to the system operating status to obtain dynamic monitoring parameters; Multi-level thread usage monitoring is performed by embedding monitoring logic within each process unit at the system and application levels to obtain the monitored in-process thread usage information. Based on the dynamic monitoring parameters, perform thread anomaly analysis on the in-process thread usage information to obtain abnormal thread analysis results; Based on the resource leak information in the abnormal thread analysis results, the self-repair module is invoked to perform resource leak self-repair.

2. The method according to claim 1, wherein, After performing thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters to obtain the abnormal thread analysis results, the method further includes: The abnormal thread information in the abnormal thread analysis results is integrated and judged hierarchically to obtain the abnormal threads to be reported. The thread-related data of the abnormal thread to be reported is reported to the cloud so that the cloud can perform resource leakage diagnosis and prediction based on the thread-related data to obtain predicted leakage information. Receive the predicted leakage information sent from the cloud and save the predicted leakage information to a preset leakage database.

3. The method according to claim 2, wherein, The abnormal thread information in the abnormal thread analysis results is integrated and judged hierarchically to obtain the abnormal threads to be reported, including: The thread information included in the abnormal thread information is recorded hierarchically to the corresponding local variables; Compare local variables and global variables at the same level to obtain the thread information differences between the local variables and the global variables, where the global variables are used to record thread information of confirmed abnormal threads; The thread class corresponding to the difference in thread information is determined as the abnormal thread to be reported.

4. The method according to claim 1, wherein, The dynamic monitoring parameters include a thread count threshold; the abnormal thread analysis results include abnormal thread information; the abnormal thread analysis process, which involves performing thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters to obtain abnormal thread analysis results, includes: Based on the in-process thread usage information, the total number of threads and the number of threads started in a single process are obtained; The threads started within the single process are classified to obtain at least one thread class; If the total number of threads is greater than the thread count threshold, then determine whether the number of threads within each thread class is greater than a preset intra-class threshold; The thread information of a class whose number of threads exceeds the preset class threshold is identified as abnormal thread information.

5. The method according to claim 4, wherein, The abnormal thread analysis results also include resource leak information; the method further includes: The thread monitoring information of thread classes with a number of threads greater than the thread class threshold is compared with the preset thread information in the preset leak library to obtain the preset thread information that matches the thread monitoring information. The preset leakage information corresponding to the preset thread information matched by the thread monitoring information is determined as the resource leakage information.

6. The method according to claim 1, wherein, The step of adaptively adjusting the monitoring configuration parameters according to the system operating status to obtain dynamic monitoring parameters includes: Calculate the system load based on the system operating status; The number of threads in the monitoring configuration parameters is adjusted according to the system load and the preset threshold adjustment coefficient to obtain the adjusted number of threads threshold. The dynamic monitoring parameters include the adjusted number of threads threshold.

7. The method according to claim 6, wherein, The step of adjusting the thread count threshold in the monitoring configuration parameters according to the system load and a preset adjustment coefficient to obtain the adjusted thread count threshold includes: The adjusted thread count threshold is calculated using the formula Threshold_d = Threshold_0 * (1 + α * Load), where Threshold_d refers to the adjusted thread count threshold, Threshold_0 refers to the thread count threshold in the monitoring configuration parameters, Load refers to the system load, and α refers to the preset threshold adjustment coefficient.

8. The method according to claim 6, wherein, The method further includes: The monitoring frequency in the monitoring configuration parameters is adjusted according to the system load and the preset frequency adjustment coefficient to obtain the adjusted monitoring frequency. The dynamic monitoring parameters include the adjusted monitoring frequency, so as to perform thread anomaly analysis and processing on the thread usage information in the process according to the adjusted monitoring frequency.

9. The method according to claim 6, wherein, The system operating status includes CPU utilization and memory utilization; calculating the system load based on the system operating status includes: The system load is calculated using the formula Load = w_CPU * CPU_Usage + w_Mem * Memory_Usage, where Load refers to the system load, CPU_Usage refers to the CPU utilization rate, w_CPU refers to the weighting coefficient of the CPU utilization rate, Memory_Usage refers to the memory utilization rate, and w_Mem refers to the weighting coefficient of the memory utilization rate.

10. The method according to claim 8, wherein, The step of adjusting the monitoring frequency in the monitoring configuration parameters according to the system load and a preset frequency adjustment coefficient to obtain the adjusted monitoring frequency includes: The adjusted monitoring frequency is calculated according to the formula Pd=P0*(1+β*Load), where Pd refers to the adjusted monitoring frequency, P0 refers to the monitoring frequency in the monitoring configuration parameters, Load refers to the system load, and β refers to the preset frequency adjustment coefficient.

11. The method according to claim 4, wherein, The step of classifying the threads started within the single process to obtain at least one thread class includes: grouping threads with the same thread name body within the single process into one category to obtain at least one thread class.

12. The method according to claim 2, wherein, After saving the predicted leakage information to a preset leakage database, the method further includes: If a thread class with more than one thread in the class is found to be the abnormal thread to be reported, the preset leakage information matching the abnormal thread to be reported is matched from the preset leakage database, and the self-repair module is called to repair the predicted resource leakage point according to the preset leakage information.

13. A thread resource monitoring and processing device, wherein, include: The parameter module is used to: obtain monitoring configuration parameters and adaptively adjust the monitoring configuration parameters according to the system operating status to obtain dynamic monitoring parameters; The monitoring module is used to: perform multi-level thread usage monitoring through the embedded monitoring logic of each process unit at the system level and application level, and obtain the monitored thread usage information within the process. The analysis module is used to: perform thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters, and obtain abnormal thread analysis results; The processing module is used to: call the self-repair module to perform resource leak self-repair based on the resource leak information in the abnormal thread analysis results.

14. The apparatus according to claim 13, wherein, After performing thread anomaly analysis on the in-process thread usage information based on the dynamic monitoring parameters to obtain the abnormal thread analysis results, the device further includes a prediction module, used for: performing hierarchical integration and judgment on the abnormal thread information in the abnormal thread analysis results to obtain abnormal threads to be reported; reporting the thread-related data of the abnormal threads to be reported to the cloud, so that the cloud can perform resource leakage diagnosis and prediction based on the thread-related data to obtain predicted leakage information; receiving the predicted leakage information sent by the cloud, and saving the predicted leakage information to a preset leakage database.

15. The apparatus according to claim 14, wherein, The prediction module is used to: record the thread information included in the abnormal thread information into corresponding local variables at different levels; compare the local variables and global variables at the same level to obtain the thread information that differs between the local variables and the global variables, wherein the global variables are variables used to record the thread information of confirmed abnormal threads; and determine the thread class corresponding to the thread information that differs as the abnormal thread to be reported.

16. The apparatus according to claim 13, wherein, The dynamic monitoring parameters include a thread count threshold; the abnormal thread analysis results include abnormal thread information; the analysis module is used to: obtain the total number of threads and the number of threads started in a single process based on the in-process thread usage information; The threads started within the single process are classified to obtain at least one thread class; if the total number of threads is greater than the thread count threshold, it is determined whether the number of threads within each thread class is greater than a preset intra-class threshold; the thread information of the thread class with the number of threads within the class greater than the preset intra-class threshold is identified as the abnormal thread information.

17. The apparatus according to claim 16, wherein, The abnormal thread analysis results also include resource leakage information; the analysis module is used to: compare the thread monitoring information of thread classes with a number of threads greater than the thread class threshold with preset thread information in a preset leakage library to obtain preset thread information that matches the thread monitoring information; and determine the preset leakage information corresponding to the preset thread information that matches the thread monitoring information as the resource leakage information.

18. The apparatus according to claim 13, wherein, The parameter module can be used to: calculate the system load based on the system operating status; adjust the thread count threshold in the monitoring configuration parameters based on the system load and a preset threshold adjustment coefficient to obtain the adjusted thread count threshold, and the dynamic monitoring parameters include the adjusted thread count threshold.

19. A storage medium, wherein, It stores a computer program that, when executed by the device's processor, causes the device to perform the method described in any one of claims 1 to 12.

20. An electronic device, wherein, include: Memory, which stores computer programs; A processor reads a computer program stored in memory to execute the method according to any one of claims 1 to 12.

Images