A method, device and computer readable storage medium for identifying a heavy thread

Abstract

This invention discloses a method, device, and computer-readable storage medium for identifying heavy threads. The method includes: attaching two pointers to each current thread, wherein a first pointer points to the first thread that last woke up the current thread, and a second pointer points to the second thread that woke up the first thread; monitoring the wake-up status of each process using a preset circular linked list and filling in multiple sets of elements according to the wake-up status, wherein each set of elements stores three values, which respectively represent the second thread, the first thread, and the current thread; obtaining the call relationships of each thread in the circular linked list for a preset sampling period; and determining the heavy thread among the threads associated with the thread of the previous frame based on the call relationships. This invention achieves an efficient and accurate heavy thread identification scheme, making resource scheduling more timely and effective, and improving the operating efficiency of large applications.

Description

Technical Field

[0001] This invention relates to the field of mobile communications, and more particularly to a method, device, and computer-readable storage medium for identifying heavy threads. Background Technology

[0002] In existing technologies, the Android operating system's kernel native scheduler uses a scheduling strategy called the CFS (Competitive Freedom of the Scheduler) algorithm. This algorithm ensures that threads using this scheduling method receive relatively equal runtime. Many foreground applications and system services in the Android operating system employ this scheduling strategy.

[0003] However, with the development of mobile platform processors and the increasing complexity of mobile platform games, some threads responsible for important screen calculations in large applications such as games require more centralized resource allocation, and the above-mentioned algorithms are no longer particularly suitable for such application scenarios.

[0004] Therefore, the need to prioritize CPU resource allocation for critical threads in large applications such as games, and how to effectively identify the heavy-duty threads in such applications, has become an urgent technical problem to be solved. Summary of the Invention

[0005] To address the aforementioned technical deficiencies in the prior art, this invention proposes a method for identifying overloaded threads, the method comprising:

[0006] Each current thread is accompanied by two pointers: the first pointer points to the first thread that last woke up the current thread, and the second pointer points to the second thread that woke up the first thread.

[0007] The wake-up status of each process is monitored by a preset circular linked list, and multiple sets of elements are filled in according to the wake-up status. Each set of elements stores three values, which are used to represent the second thread, the first thread, and the current thread, respectively.

[0008] Obtain the call relationship of each thread in the circular linked list for the preset sampling period;

[0009] Based on the calling relationship, determine the heavyweight thread associated with the thread of the previous frame among the various threads.

[0010] Optionally, the method further includes:

[0011] Get the current application running status and system running status;

[0012] The current statistical period is set according to the application running status and the system running status, and the length of the circular linked list is determined according to the statistical period.

[0013] Optionally, the method further includes:

[0014] Obtain the status values ​​of the application's running status and / or the system's running status;

[0015] The sampling interval for each group of elements is set according to the state value, and the values ​​stored in each group of elements are obtained according to the sampling interval.

[0016] Optionally, the method further includes:

[0017] The thread wake-up frequency corresponding to each element is determined based on the calling relationship;

[0018] Obtain the target element whose thread wake-up frequency meets the preset frequency condition.

[0019] Optionally, the method further includes:

[0020] The target thread associated with the thread of the previous frame in each of the threads;

[0021] When the target element is the target thread, the target thread is designated as the load thread to be controlled.

[0022] The present invention also proposes a heavy thread identification device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the following method:

[0023] Each current thread is accompanied by two pointers: the first pointer points to the first thread that last woke up the current thread, and the second pointer points to the second thread that woke up the first thread.

[0024] The wake-up status of each process is monitored by a preset circular linked list, and multiple sets of elements are filled in according to the wake-up status. Each set of elements stores three values, which are used to represent the second thread, the first thread, and the current thread, respectively.

[0025] Obtain the call relationship of each thread in the circular linked list for the preset sampling period;

[0026] Based on the calling relationship, determine the heavyweight thread associated with the thread of the previous frame among the various threads.

[0027] Optionally, when the computer program is executed by the processor, it is further configured to implement the steps of the following method:

[0028] Get the current application running status and system running status;

[0029] The current statistical period is set according to the application running status and the system running status, and the length of the circular linked list is determined according to the statistical period.

[0030] Optionally, when the computer program is executed by the processor, it is further configured to implement the steps of the following method:

[0031] Obtain the status values ​​of the application's running status and / or the system's running status;

[0032] The sampling interval for each group of elements is set according to the state value, and the values ​​stored in each group of elements are obtained according to the sampling interval.

[0033] Optionally, when the computer program is executed by the processor, it is further configured to implement the steps of the following method:

[0034] The thread wake-up frequency corresponding to each element is determined based on the calling relationship;

[0035] Obtain the target element whose thread wake-up frequency meets the preset frequency condition;

[0036] The target thread associated with the thread of the previous frame in each of the threads;

[0037] When the target element is the target thread, the target thread is designated as the load thread to be controlled.

[0038] The present invention also proposes a computer-readable storage medium storing a burdened thread identification program, which, when executed by a processor, implements the steps of the burdened thread identification method as described in any of the preceding claims.

[0039] The present invention provides a method, device, and computer-readable storage medium for identifying heavy threads. This is achieved by attaching two pointers to each current thread: a first pointer pointing to the first thread that last woke up the current thread, and a second pointer pointing to the second thread that woke up the first thread. A preset circular linked list is used to monitor the wake-up status of each process and fill in multiple sets of elements based on the wake-up status. Each set of elements stores three values, which respectively represent the second thread, the first thread, and the current thread. The call relationships of the threads in the circular linked list for a preset sampling period are obtained. Based on the call relationships, the heavy thread associated with the thread in the previous frame is determined. This provides an efficient and accurate heavy thread identification scheme, making resource scheduling of heavy threads more timely and effective, and greatly improving the operating efficiency of large applications. Attached Figure Description

[0040] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings:

[0041] Figure 1 This is a schematic diagram of the hardware structure of a mobile terminal according to the present invention;

[0042] Figure 2 This is the first flowchart of the method for identifying heavy threads in this invention;

[0043] Figure 3 This is the second flowchart of the method for identifying heavy threads in this invention;

[0044] Figure 4 This is the third flowchart of the method for identifying heavy threads in this invention;

[0045] Figure 5 This is the fourth flowchart of the method for identifying heavy threads in this invention;

[0046] Figure 6 This is the fifth flowchart of the method for identifying heavy threads in this invention. Detailed Implementation

[0047] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0048] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no specific meaning in itself. Therefore, "module," "part," or "unit" may be used interchangeably.

[0049] Terminals can be implemented in various forms. For example, the terminals described in this invention may include mobile terminals such as mobile phones, tablets, laptops, handheld computers, personal digital assistants (PDAs), portable media players (PMPs), navigation devices, wearable devices, smart bracelets, pedometers, etc., as well as fixed terminals such as digital TVs and desktop computers.

[0050] The following description will use a mobile terminal as an example. Those skilled in the art will understand that, apart from elements specifically designed for mobile purposes, the construction according to embodiments of the present invention can also be applied to fixed-type terminals.

[0051] Please see Figure 1This is a schematic diagram of the hardware structure of a mobile terminal implementing various embodiments of the present invention. The mobile terminal 100 may include: an RF (Radio Frequency) unit 101, a WiFi module 102, an audio output unit 103, an A / V (Audio / Video) input unit 104, a sensor 105, a display unit 106, a user input unit 107, an interface unit 108, a memory 109, a processor 110, and a power supply 111, etc. Those skilled in the art will understand that... Figure 1 The mobile terminal structure shown does not constitute a limitation on the mobile terminal. The mobile terminal may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0052] The following is combined Figure 1 A detailed introduction to each component of the mobile terminal:

[0053] The radio frequency unit 101 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with the processor 110; additionally, it transmits uplink data to the base station. Typically, the radio frequency unit 101 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, and a duplexer. Furthermore, the radio frequency unit 101 can also communicate wirelessly with networks and other devices. The aforementioned wireless communications may use any communication standard or protocol, including but not limited to GSM (Global System of Mobile communication), GPRS (General Packet Radio Service), CDMA2000 (Code Division Multiple Access 2000), WCDMA (Wideband Code Division Multiple Access), TD-SCDMA (Time Division-Synchronous Code Division Multiple Access), FDD-LTE (Frequency Division Duplexing-Long Term Evolution), and TDD-LTE (Time Division Duplexing-Long Term Evolution).

[0054] WiFi is a short-range wireless transmission technology. Mobile terminals using the WiFi module 102 can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 1 WiFi module 102 is shown, but it is understood that it is not a necessary component of a mobile terminal and can be omitted as needed without changing the nature of the invention.

[0055] The audio output unit 103 can convert audio data received by the radio frequency unit 101 or the WiFi module 102 or stored in the memory 109 into audio signals and output them as sound when the mobile terminal 100 is in call signal receiving mode, call mode, recording mode, voice recognition mode, broadcast receiving mode, etc. Furthermore, the audio output unit 103 can also provide audio output related to specific functions performed by the mobile terminal 100 (e.g., call signal receiving sound, message receiving sound, etc.). The audio output unit 103 may include a speaker, a buzzer, etc.

[0056] The A / V input unit 104 is used to receive audio or video signals. The A / V input unit 104 may include a graphics processing unit (GPU) 1041 and a microphone 1042. The GPU 1041 processes image data of still images or videos acquired by an image capture device (such as a camera) in video capture mode or image capture mode. The processed image frames can be displayed on the display unit 106. The image frames processed by the GPU 1041 can be stored in the memory 109 (or other storage medium) or transmitted via the radio frequency unit 101 or the WiFi module 102. The microphone 1042 can receive sound (audio data) in operating modes such as telephone call mode, recording mode, and voice recognition mode, and can process such sound into audio data. The processed audio (voice) data can be converted into a format that can be transmitted to a mobile communication base station via the radio frequency unit 101 in telephone call mode. The microphone 1042 can implement various types of noise cancellation (or suppression) algorithms to eliminate (or suppress) noise or interference generated during the reception and transmission of audio signals.

[0057] The mobile terminal 100 also includes at least one sensor 105, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 1061 according to the ambient light level, and the proximity sensor can turn off the display panel 1061 and / or backlight when the mobile terminal 100 is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used for applications that recognize the phone's posture (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition-related functions (such as pedometer, tapping), etc. Other sensors that may be configured in the phone, such as fingerprint sensors, pressure sensors, iris sensors, molecular sensors, gyroscopes, barometers, hygrometers, thermometers, and infrared sensors, will not be described in detail here.

[0058] The display unit 106 is used to display information input by the user or information provided to the user. The display unit 106 may include a display panel 1061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0059] User input unit 107 can be used to receive input numerical or character information, and generate key signal inputs related to user settings and function control of the mobile terminal. Specifically, user input unit 107 may include touch panel 1071 and other input devices 1072. Touch panel 1071, also known as touch screen, can collect touch operations on or near the user (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near touch panel 1071), and drive corresponding connection devices according to a pre-set program. Touch panel 1071 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, sends it to processor 110, and can receive and execute commands from processor 110. In addition, touch panel 1071 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 1071, the user input unit 107 may also include other input devices 1072. Specifically, other input devices 1072 may include, but are not limited to, one or more of the following: physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc., without being limited here.

[0060] Furthermore, the touch panel 1071 may cover the display panel 1061. When the touch panel 1071 detects a touch operation on or near it, it transmits the information to the processor 110 to determine the type of touch event. Subsequently, the processor 110 provides corresponding visual output on the display panel 1061 based on the type of touch event. Although in Figure 1 In this embodiment, the touch panel 1071 and the display panel 1061 are two independent components to realize the input and output functions of the mobile terminal. However, in some embodiments, the touch panel 1071 and the display panel 1061 can be integrated to realize the input and output functions of the mobile terminal. The specific implementation is not limited here.

[0061] Interface unit 108 serves as an interface through which at least one external device can connect to mobile terminal 100. For example, the external device may include a wired or wireless headset port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, and so on. Interface unit 108 may be used to receive input (e.g., data, power, etc.) from the external device and transmit the received input to one or more elements within mobile terminal 100, or it may be used to transmit data between mobile terminal 100 and the external device.

[0062] The memory 109 can be used to store software programs and various data. The memory 109 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, image playback, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the memory 109 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.

[0063] The processor 110 is the control center of the mobile terminal. It connects various parts of the mobile terminal via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 109, and by calling data stored in the memory 109, it performs various functions and processes data of the mobile terminal, thereby providing overall monitoring of the mobile terminal. The processor 110 may include one or more processing units; preferably, the processor 110 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 110.

[0064] The mobile terminal 100 may also include a power supply 111 (such as a battery) that supplies power to various components. Preferably, the power supply 111 can be logically connected to the processor 110 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0065] although Figure 1 As not shown, the mobile terminal 100 may also include a Bluetooth module, etc., which will not be described in detail here.

[0066] Based on the above-described mobile terminal hardware structure, various embodiments of the method of the present invention are proposed.

[0067] Figure 2 This is the first flowchart of the method for identifying overloaded threads according to the present invention. This embodiment proposes a method for identifying overloaded threads, which includes:

[0068] S1. Each current thread is attached with two pointers, wherein the first pointer points to the first thread that last woke up the current thread, and the second pointer points to the second thread that woke up the first thread.

[0069] S2. Monitor the wake-up status of each process through a preset circular linked list and fill in multiple sets of elements according to the wake-up status. Each set of elements stores three values, which are used to represent the second thread, the first thread, and the current thread, respectively.

[0070] S3. Obtain the calling relationship of each thread in the circular linked list of the preset sampling period;

[0071] S4. Determine the heavyweight thread associated with the previous frame thread among the various threads based on the calling relationship.

[0072] In this embodiment, we first analyze the approach to identifying heavy application threads in large-scale application scenarios such as games.

[0073] In this context, each application corresponds to a process; game applications are also within the category of ordinary applications; they follow similar rules, with each game application corresponding to a process.

[0074] In this embodiment, it is considered that in the process of a normal application, there must be a key thread responsible for submitting the application's interface data to the rendering system (SurfaceFlinger). This process is called the previous frame; this thread is usually called RenderThread.

[0075] Game applications fall under the same category as general applications and follow the same rules. However, there are some differences in games that require special consideration. For example, many games are now developed using the Unity-3D and UE4 engines. Games developed with these engines also have similar frame-up threads. The frame-up thread in Unity-3D is called UnityGfxDeviceW, while the thread in UE4 is often called Thread-xx (xx is a numerical number, such as Thread-59).

[0076] As game interfaces become increasingly complex, more and more commercial resources need to be added to the game layout. These game engines have gradually developed other sub-threads to share the load on the frame thread; for example, UnityMain and UnityMultiThread in Unity-3D, and FAsyncLoading in UE4.

[0077] Furthermore, the previous frame thread often has a calling relationship with the sub-threads that share these sub-tasks. The previous frame thread needs to wait for these sub-threads to complete their sub-tasks before it can perform the previous frame.

[0078] In current operating system kernel scheduling algorithms, this call relationship between one thread and another is often represented by the `wake_up` function. For example, thread A waits for a block of code in thread B to finish executing before being woken up. In this case, thread B is called `prev_task`, and thread A is called `next_task`. After thread B finishes executing its code, a wake-up relationship of `prev_task->wake_up->next_task` occurs, meaning that B wakes up the function execution of A.

[0079] Therefore, the following issues can be identified from the above information:

[0080] First, at this stage, it is not enough to simply focus on CPU resource scheduling for the game's previous frame thread.

[0081] Secondly, the sub-thread that assigns tasks has a calling relationship with the thread of the previous frame, and often blocks the rhythm of the previous frame.

[0082] Third, the previous frame thread has a calling relationship with the child thread that dispatches the task, as well as with other threads.

[0083] Fourth, the wake-up events that occur every moment in the kernel, and the high-frequency wake-up relationships among them, can express the calling relationship between the previous frame thread and important child threads.

[0084] Based on this, this embodiment proposes a new scheme for identifying the heavy-duty threads in game applications. Specifically, assume that `render_t` is the thread that woke up the previous frame, `render_st_1` is the child thread that woke up the previous frame, and `render_st_2` is the child thread that woke up the previous frame. The `wake_up` event occurs between two threads, which raises the issue of tracing depth. For example, if `render_st_1` wakes up `render_t`, this is relatively simple; as long as the kernel tells us which thread woke up the previous frame and the thread with the highest call frequency within a statistical period, it's easy to find the key child thread. This is the case where `render_st_1` wakes up `render_t`. However, this method cannot handle a triple call relationship where `render_st_2` wakes up `render_st_1` wakes up `render_t`.

[0085] Therefore, this embodiment designs the following algorithm: Each process is accompanied by two pointers, one pointing to the last time the current thread was woken up, called the last_task first process, and the other pointing to the waker that woke up last_task, called the prev_last_task second process.

[0086] Based on this, please refer to Table 1.

[0087]

[0088] Table 1

[0089] Here, `cur` represents the current task, i.e., `render_t`, `l_t` are `last_task`, and `p_l_k` are `prev_last_task`. The time in Table 1 above progresses from top to bottom. For example, the columns `f:` and `d:` indicate that thread `d` is awakened by thread `c`, and thread `c` is awakened by thread `b`. At this time, the pointer `last_task` of thread `d` points to thread `c`, and the pointer `prev_last_task` of thread `d` points to thread `b`. Therefore, when `render_t` is awakened, i.e., when `cur` is awakened, this embodiment can find the `last_task` that awakened `render_t`, thread `g`, and also find the `prev_last_task` that awakened `last_task`, thread `f`.

[0090] Furthermore, to determine which call relationships occur most frequently over a period of time, this embodiment defines a circular linked list called RingBuffer, the length of which can be dynamically changed. Each element in the linked list stores three values, namely the three threads mentioned above. tid0 represents prev_last_task, tid1 represents last_task, and tid3 represents render_t.

[0091] Based on this, please refer to Table 2.

[0092]

[0093] Table 2

[0094] Based on Table 2 above, this embodiment refers to the RingBuffer Item as RBItem, corresponding to each column in Table 2. The three values ​​in RBitem are tid0 (first row), tid1 (second row), and tid3 (third row). Therefore, the most frequent occurrence within a unit length of the linked list, i.e., a statistical duration of 3 seconds, is c->b->a. Optionally, the sampling interval between each group of Items is configurable, with a default of 300ms. That is, every 300ms, this embodiment searches for a call relationship associated with the thread of the previous frame. Using the above algorithm, this embodiment can obtain the corresponding call relationship. The key thread obtained is the burden thread required in this embodiment. Furthermore, this embodiment provides the thread number of the burden thread to the system's Usrspace scheduling thread, enabling targeted resource scheduling.

[0095] The beneficial effect of this embodiment lies in the following: By attaching two pointers to each current thread—the first pointer pointing to the first thread that last woke up the current thread, and the second pointer pointing to the second thread that woke up the first thread—and monitoring the wake-up status of each process using a preset circular linked list, multiple sets of elements are filled in according to the wake-up status. Each set of elements stores three values, which respectively represent the second thread, the first thread, and the current thread. The call relationships of each thread in the circular linked list for a preset sampling period are obtained. Based on the call relationships, the heavy-duty thread associated with the thread of the previous frame is determined. This achieves an efficient and accurate heavy-duty thread identification scheme, making the resource scheduling of heavy-duty threads more timely and effective, and greatly improving the operating efficiency of large applications.

[0096] Please refer to Figure 3 The method further includes:

[0097] S21. Obtain the current application running status and system running status;

[0098] S22. Set the current statistical period according to the application running status and the system running status, and determine the length of the circular linked list according to the statistical period.

[0099] Please refer to Figure 4 The method further includes:

[0100] S23. Obtain the status values ​​of the application running status and / or the system running status;

[0101] S24. Set the sampling interval for each group of elements according to the state value, and obtain each value stored in each group of elements according to the sampling interval.

[0102] Please refer to Figure 5 The method further includes:

[0103] S31. Determine the thread wake-up frequency corresponding to each element based on the calling relationship;

[0104] S32. Obtain the target element whose thread wake-up frequency meets the preset frequency condition.

[0105] Please refer to Figure 6 The method further includes:

[0106] S41, the target thread associated with the thread of the previous frame in each of the threads;

[0107] S42. When the target element is the target thread, the target thread is designated as the load thread to be controlled.

[0108] Based on the above embodiments, the present invention also proposes a heavy thread identification device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the following method:

[0109] Each current thread is accompanied by two pointers: the first pointer points to the first thread that last woke up the current thread, and the second pointer points to the second thread that woke up the first thread.

[0110] The wake-up status of each process is monitored by a preset circular linked list, and multiple sets of elements are filled in according to the wake-up status. Each set of elements stores three values, which are used to represent the second thread, the first thread, and the current thread, respectively.

[0111] Obtain the call relationship of each thread in the circular linked list for the preset sampling period;

[0112] Based on the calling relationship, determine the heavyweight thread associated with the thread of the previous frame among the various threads.

[0113] Optionally, when the computer program is executed by the processor, it is further configured to implement the steps of the following method:

[0114] Get the current application running status and system running status;

[0115] The current statistical period is set according to the application running status and the system running status, and the length of the circular linked list is determined according to the statistical period.

[0116] Optionally, when the computer program is executed by the processor, it is further configured to implement the steps of the following method:

[0117] Obtain the status values ​​of the application's running status and / or the system's running status;

[0118] The sampling interval for each group of elements is set according to the state value, and the values ​​stored in each group of elements are obtained according to the sampling interval.

[0119] Optionally, when the computer program is executed by the processor, it is further configured to implement the steps of the following method:

[0120] The thread wake-up frequency corresponding to each element is determined based on the calling relationship;

[0121] Obtain the target element whose thread wake-up frequency meets the preset frequency condition;

[0122] The target thread associated with the thread of the previous frame in each of the threads;

[0123] When the target element is the target thread, the target thread is designated as the load thread to be controlled.

[0124] It should be noted that the above-described device embodiments and method embodiments belong to the same concept. The specific implementation process can be found in the method embodiments, and the technical features in the method embodiments are also applicable to the device embodiments, which will not be repeated here.

[0125] Based on the above embodiments, the present invention also proposes a computer-readable storage medium storing a heavy thread identification program, which, when executed by a processor, implements the steps of the heavy thread identification method as described in any of the above embodiments.

[0126] It should be noted that the above-described medium embodiments and method embodiments belong to the same concept. The specific implementation process can be found in the method embodiments, and the technical features in the method embodiments are also applicable to the medium embodiments, which will not be repeated here.

[0127] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0128] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0129] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0130] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A method for identifying overloaded threads, characterized in that, The method includes: Each current thread is accompanied by two pointers: the first pointer points to the first thread that last woke up the current thread, and the second pointer points to the second thread that woke up the first thread. The wake-up status of each process is monitored by a preset circular linked list, and multiple sets of elements are filled in according to the wake-up status. Each set of elements stores three values, which are used to represent the second thread, the first thread, and the current thread, respectively. Obtain the call relationship of each thread in the circular linked list for the preset sampling period; Based on the calling relationship, determine the heavyweight thread associated with the thread of the previous frame in each thread; The method further includes: Get the current application running status and system running status; The current statistical period is set according to the application running status and the system running status, and the length of the circular linked list is determined according to the statistical period. Obtain the status values ​​of the application's running status and / or the system's running status; The sampling interval for each group of elements is set according to the state value, and the values ​​stored in each group of elements are obtained according to the sampling interval. The thread wake-up frequency corresponding to each element is determined based on the calling relationship; Obtain the target element whose thread wake-up frequency meets the preset frequency condition; Determine the target thread associated with the thread of the previous frame from among the various threads; When the target element is the target thread, the target thread is designated as the load thread to be controlled.

2. A load-bearing thread identification device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, performs the steps of the following method: Each current thread is accompanied by two pointers: the first pointer points to the first thread that last woke up the current thread, and the second pointer points to the second thread that woke up the first thread. The wake-up status of each process is monitored by a preset circular linked list, and multiple sets of elements are filled in according to the wake-up status. Each set of elements stores three values, which are used to represent the second thread, the first thread, and the current thread, respectively. Obtain the call relationship of each thread in the circular linked list for the preset sampling period; Based on the calling relationship, determine the heavyweight thread associated with the thread of the previous frame in each thread; in: Get the current application running status and system running status; The current statistical period is set according to the application running status and the system running status, and the length of the circular linked list is determined according to the statistical period. Obtain the status values ​​of the application's running status and / or the system's running status; The sampling interval for each group of elements is set according to the state value, and the values ​​stored in each group of elements are obtained according to the sampling interval. The thread wake-up frequency corresponding to each element is determined based on the calling relationship; Obtain the target element whose thread wake-up frequency meets the preset frequency condition; Determine the target thread associated with the thread of the previous frame from among the various threads; When the target element is the target thread, the target thread is designated as the load thread to be controlled.

3. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a heavy thread identification program, which, when executed by a processor, implements the steps of the heavy thread identification method as described in claim 1.

Images