Dynamic configuration method of thread parameters and dynamic management device of thread pool
By using the collaborative working mechanism between the client and the server in the dynamic management of thread pools, the thread parameters are dynamically configured, which solves the problem of large adaptation workload in the existing technology and reduces access and maintenance costs.
Patent Information
- Application Number
- CN202510189192.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-20
- Publication Date
- 2025-06-20
AI Technical Summary
In the dynamic management of prior art thread pools, monitoring components and configuration components need to be installed, resulting in large adaptation workloads and increasing access and maintenance costs.
Provides a dynamic configuration method of thread parameters, obtains the running status information of the target system through the client and sends it to the server. The server generates thread parameters based on the running status information, and the client then dynamically configures the thread pool of the target system based on the thread parameters.
It reduces the access and maintenance costs of dynamic configuration of thread parameters and reduces the complexity of system user operations. You only need to install a client in the target system to realize dynamic configuration of thread parameters.
Smart Images
Figure CN120179306A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of thread control, and in particular, to a method for dynamically configuring thread parameters and a device for dynamically managing a thread pool. Background Art
[0002] As a commonly used concurrent programming tool, the thread pool is widely used in scenarios such as processing asynchronous tasks, network requests, and parallel computing.
[0003] During the use of the thread pool, it is necessary to dynamically manage the thread parameters in the thread pool. Currently, the dynamic management of thread parameters mainly adopts the mode of a monitoring component + a configuration component. The monitoring component can specifically adopt SpringBoot Actuator, prometheus, grafana, etc. The configuration component can specifically adopt zookeeper, apollo, nacos, etc. In the dynamic management of the thread pool, first, for the thread pool to be managed, install the monitoring component and the configuration component in the system where the thread pool belongs, and adapt the monitoring component and the configuration component in the system respectively. Then, the system runs and normally calls the threads in the thread pool. Next, the monitoring component obtains the running state information of the system and displays the obtained running state information to relevant personnel. Based on the running state information, the relevant personnel judge whether to adjust the thread parameters in the thread pool of the system, and after determining that the thread pool parameters need to be adjusted, input the adjusted thread parameters into the configuration component, and the configuration component adjusts the thread parameters in the thread pool.
[0004] However, accessing the monitoring component and the configuration component in the system requires a large amount of adaptation work, and in the process of dynamically configuring thread parameters, the real-time participation of relevant personnel is also required. These all increase the complexity of the system user's operation, and further increase the access and maintenance costs of dynamically configuring thread parameters. Summary of the Invention
[0005] The purpose of the embodiments of this application is to provide a method for dynamically configuring thread parameters and a device for dynamically managing a thread pool, so as to reduce the access and maintenance costs of dynamically configuring thread parameters.
[0006] To solve the above technical problems, the embodiments of this application provide the following technical solutions:
[0007] The first aspect of the present application provides a method for dynamically configuring thread parameters. The method is applied to a thread pool dynamic management device, which includes a client and a server. The client is installed in the target system where thread parameter dynamic configuration is to be performed, and the server is installed in the background. The method includes: the client obtains the running state information of the target system; the client sends the running state information to the server so that the server generates thread parameters based on the running state information and sends the thread parameters to the client; the client receives the thread parameters sent by the server; the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters.
[0008] Compared with the prior art, in the method for dynamically configuring thread parameters provided by the first aspect of the present application, in the target system where thread parameter dynamic configuration is to be performed, only the client of the thread pool dynamic management device is installed. The client obtains the running state information of the target system, and then sends the obtained running state information to the server outside the target system so that the server determines the thread parameters of the target system based on the running state information of the target system. Thus, the client dynamically configures the thread parameters in the thread pool of the target system according to the determined thread parameters. In this way, only by installing the client in the target system can the dynamic configuration of thread parameters in the target system be achieved. There is no need to perform more component installation and adaptation work, reducing the complexity of system user operations, and thus reducing the access and maintenance costs of thread parameter dynamic configuration.
[0009] In some variant embodiments of the first aspect of the present application, the client stores the address of the server and the name of the server; the client sending the running state information to the server includes: the client sending the running state information and the name of the server to the server according to the address of the server, so that after the server passes the verification of the name of the server, it generates thread parameters based on the running state information.
[0010] When the client sends the running state information to the server, it also sends the name of the server to the server, so that the server can determine whether to determine the thread parameters according to the running state information it receives, avoiding determining thread parameters based on false running state information and feeding them back to the client, improving the security of the target system operation.
[0011] In some variant embodiments of the first aspect of the present application, during the installation process of the client in the target system, the address of the server and the name of the server are stored in a preset module in the target system that generates the running state information, and the preset module can send the running state information and the name of the server to the address of the server; the client sending the running state information and the name of the server to the address of the server includes: the client sending the running state information and the name of the server to the server according to the address of the server through the preset module.
[0012] When the client accesses the target system, only the address and name of the server are accessed to the target system, which can reduce the complexity of dynamically configuring the access of thread parameters.
[0013] In some modified implementation manners of the first aspect of the present application, the client includes a thread pool creation method and a thread pool closing method; before the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters, the method further includes: the client receives a call instruction sent by the target system; when the call instruction indicates to create a thread pool, the client sends the thread pool creation method to the target system, so that the target system creates a thread pool by using the thread pool creation method; when the call instruction indicates to close the thread pool, the client sends the thread pool closing method to the target system, so that the target system closes the currently used thread pool of the target system by using the thread pool closing method.
[0014] By presetting the thread pool creation method and the thread pool closing method in the client, when the target system needs to create or close a thread pool, the methods in the client can be directly called for creating or closing the thread pool. When developing the system, system developers only need to create corresponding call interfaces, which reduces the workload of system developers and improves the system development efficiency.
[0015] In some modified implementation manners of the first aspect of the present application, the device further includes a front-end page, and the front-end page displays the current thread parameters, the thread parameters to be updated, and parameter update options; before the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters, the method further includes: the client sends the thread parameters to the front-end page; the front-end page takes the thread parameters as the thread parameters to be updated, and displays the current thread parameters, the thread parameters to be updated, and the parameter update options; in response to the selection of the parameter update option, the front-end page sends a parameter configuration instruction to the server, so that the server sends the thread parameters to the client again, so that the client modifies the thread parameters in the thread pool of the target system according to the thread parameters received again.
[0016] By displaying the current and to-be-updated thread parameters to the user through the front-end page, providing parameter update options for the user to confirm whether to update the thread parameters, and adjusting the thread parameters in the target system after determining that the user confirms the update, the configuration of the thread parameters in the system is controllable, and the controllability of the dynamic configuration of the thread parameters is improved.
[0017] The second aspect of the present application provides a method for dynamically configuring thread parameters. The method is applied to a thread pool dynamic management device, which includes a client and a server. The client is installed in the target system to be dynamically configured with thread parameters, and the server is installed in the background. The method includes: the server receives the operation status information of the target system sent by the client; the server generates thread parameters based on the operation status information; the server sends the thread parameters to the client so that the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters.
[0018] Compared with the prior art, in the method for dynamically configuring thread parameters provided in the second aspect of the present application, in the target system to be dynamically configured with thread parameters, only the client of the thread pool dynamic management device is installed. The client obtains the operation status information of the target system and then sends the obtained operation status information to the server outside the target system, so that the server determines the thread parameters of the target system based on the operation status information of the target system. Then, the client dynamically configures the thread parameters in the thread pool of the target system according to the determined thread parameters. In this way, only the client needs to be installed in the target system to achieve the dynamic configuration of the thread parameters in the target system. There is no need to install and adapt more components, reducing the complexity of the system user's operation and thus reducing the access and maintenance costs of the dynamic configuration of thread parameters.
[0019] In some modified implementation manners of the second aspect of the present application, the operation status information includes the system name of the target system, the node name of the device where the target system is located, and the operation status information of each thread pool in the device. The device includes multiple systems, and different systems correspond to different thread pools. After the server generates thread parameters based on the operation status information, the method further includes: the server determines the total number of threads according to the node name; the server determines the target thread pool of the target system from all the thread pools of the device according to the system name; the server adjusts the thread parameters according to the total number of threads, the operation status information of the target thread pool, and the operation status information of other thread pools except the target thread pool in all the thread pools to obtain the final thread parameters of the target system.
[0020] When the server determines the thread parameters of the target system, it combines the operation conditions of other systems in the device where the target system is located and comprehensively determines the thread parameters of the target system, making the determination of the thread parameters of the target system more in line with the actual situation of the device where it is located and ensuring the normal operation of the device.
[0021] In some modified embodiments of the second aspect of the present application, the server sends thread parameters to the client, including: when the thread parameters change compared to the thread parameters currently configured in the target system, the server sends the thread parameters to the client in real time; when the thread parameters do not change compared to the thread parameters currently configured in the target system, the server sends the thread parameters to the client after a preset duration.
[0022] If the server determines that the thread parameters of the target system need to be adjusted, it immediately sends the determined thread parameters to the client to achieve efficient adjustment of the thread parameters. If the server determines that the thread parameters of the target system do not need to be adjusted, it can wait for a period of time before sending feedback to the client. This not only realizes the feedback of the server but also avoids preempting interaction resources, ensures the priority transmission of information related to parameter adjustment, and improves the efficiency of dynamic configuration of thread parameters.
[0023] The third aspect of the present application provides a thread pool dynamic management device. The device includes a client and a server. The client is installed in the target system to be dynamically configured with thread parameters, and the server is installed in the background. Among them, the client is used to obtain the running state information of the target system; the client is also used to send the running state information to the server so that the server generates thread parameters based on the running state information and sends the thread parameters to the client; the client is also used to receive the thread parameters sent by the server; the client is also used to dynamically configure the thread parameters in the thread pool of the target system according to the thread parameters.
[0024] The fourth aspect of the present application provides a thread pool dynamic management device. The device includes a client and a server. The client is installed in the target system to be dynamically configured with thread parameters, and the server is installed in the background. Among them, the server is used to receive the running state information of the target system sent by the client; the server is also used to generate thread parameters based on the running state information; the server is also used to send the thread parameters to the client so that the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters.
[0025] The fifth aspect of the present application provides an electronic device. The electronic device includes: a processor, a memory, and a bus; among them, the processor and the memory communicate with each other through the bus; the processor is used to call program instructions in the memory to execute the methods in the first aspect or the second aspect.
[0026] The sixth aspect of the present application provides a computer-readable storage medium. The storage medium includes: a stored program; among them, when the program runs, it controls the device where the storage medium is located to execute the methods in the first aspect or the second aspect.
[0027] The thread pool dynamic management device provided in the third and fourth aspects of this application, the electronic device provided in the fifth aspect, and the storage medium provided in the sixth aspect have the same or similar beneficial effects as the dynamic configuration method of thread parameters provided in the first and second aspects. BRIEF DESCRIPTION OF THE DRAWINGS
[0028] By reading the following detailed description with reference to the accompanying drawings, the above and other objects, features, and advantages of the exemplary embodiments of this application will become readily understandable. In the drawings, several embodiments of this application are shown in an exemplary rather than restrictive manner, with the same or corresponding reference numerals indicating the same or corresponding parts, where:
[0029] Figure 1 It is a schematic diagram of the application scenario architecture of the dynamic configuration method of thread parameters in the embodiments of this application;
[0030] Figure 2 It is a schematic flow chart of the dynamic configuration method of thread parameters in the embodiments of this application Figure 1 ;
[0031] Figure 3 It is a schematic flow chart of the dynamic configuration method of thread parameters in the embodiments of this application Figure 2 ;
[0032] Figure 4 It is a schematic structural diagram of the thread pool dynamic management device in the embodiments of this application;
[0033] Figure 5 It is a schematic structural diagram of the electronic device in the embodiments of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0034] The following will describe the exemplary embodiments of this application in more detail with reference to the accompanying drawings. Although the exemplary embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided so that this application can be more thoroughly understood and the scope of this application can be fully conveyed to those skilled in the art.
[0035] It should be noted that unless otherwise specified, the technical terms or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art to which this application belongs.
[0036] Currently, in order to implement the dynamic configuration of thread parameters, it is necessary to introduce a monitoring component and a configuration component in the target system. However, introducing components into the system requires a large amount of adaptation work, increasing the cost of accessing and maintaining the dynamic configuration of thread parameters.
[0037] In view of this, a dynamic configuration method for thread parameters and a thread pool dynamic management device involved in the embodiments of the present application provide a thread pool dynamic management device including a client and a server. The client is installed in the system to be dynamically configured with thread parameters, and the server is installed in the background. The client obtains the running state information of the system and sends the running state information to the server. The server determines the thread parameters based on the running state information and feeds back the thread parameters to the client. Finally, the client adjusts the thread parameters in the system. In this way, by introducing a client into the system, the access to the dynamic configuration of thread parameters can be realized, reducing the access cost and maintenance cost of the dynamic configuration of thread parameters.
[0038] It should be noted here that the client in the embodiments of the present application is installed in the system after obtaining the authorization of the system. Moreover, the client obtains the running state information from the system and also obtains the prior authorization of the system, all of which are legal and compliant.
[0039] First, the application scenario of the dynamic configuration method for thread parameters provided by the embodiments of the present application will be described.
[0040] Figure 1 For the application scenario architecture diagram of the dynamic configuration method for thread parameters in the embodiments of the present application, see Figure 1 As shown, the architecture may include: a target system 11 to be dynamically configured with thread parameters, a thread pool dynamic management device 12, and a background 13. The thread pool dynamic management device 12 may include: a client 121 and a server 122.
[0041] The target system 11 refers to a system that is correspondingly configured with a thread pool and needs to implement the dynamic configuration of thread parameters in the thread pool. For example: a logistics system, an order system, etc.
[0042] The thread pool dynamic management device 12 can be understood as a functional tool for obtaining the running state information from the target system 11 and determining the thread parameters based on the running state information, so as to determine whether to adjust the current thread parameters. For example: a newly developed Springboot starter common package.
[0043] The client 121 is installed in the target system 11 to obtain the running state information of the target system 11.
[0044] The server 122 is installed in the background 13, such as: the server of the service provider of the thread pool dynamic management device 12, the cloud, etc., to obtain the running state information sent by the client 121, so as to determine the thread parameters and feed back the determined thread parameters to the client 121.
[0045] Next, a detailed description of the dynamic configuration method for thread parameters provided in the embodiments of the present application will be given.
[0046] Figure 2 It is a flow schematic of the dynamic configuration method for thread parameters in the embodiments of the present application Figure 1 , see Figure 2 As shown, the method may include: S21 - S27.
[0047] S21: The client obtains the running status information of the target system.
[0048] After the client starts in the target system, the client begins to obtain the running status information of the target system.
[0049] The running status information may refer to any one or more types of information related to thread calls in the target system, such as: the number of active threads, the number of core threads, the maximum number of threads, the total amount of tasks planned to be executed, the total number of completed tasks, the remaining capacity of the queue, and so on.
[0050] When there is a real-time configuration requirement for thread parameters in the target system, the system user can input the running status information and its corresponding thread parameters in the configuration page provided by the server, and the server saves the running status information and its corresponding thread parameters input by the system user. The client can obtain the running status information of the target system in real-time or at a predetermined time interval, and then send it to the server for subsequent processing. The predetermined time interval can be 1s, 1min, etc. For the specific value of the predetermined time interval, it is not limited here.
[0051] S22: The client sends the running status information to the server.
[0052] After the client obtains the running status information of the target system, it will send the obtained running status information to the server.
[0053] Specifically when sending, the client can send the running status information to the server in the form of an http request. For example: sending an httppost request to the server, and the request body is data in JSON format. A long connection can also be established in advance between the client and the server, and the client can also use the running status information as a heartbeat packet and send it to the server through the long connection. For the specific way for the client to send the running status information to the server, it needs to be determined according to the actual interaction situation between the system where the client is located and the background where the server is located, and it is not specifically limited here.
[0054] S23: The server receives the running status information of the target system sent by the client.
[0055] After the server receives the running status information sent by the client, it can determine the corresponding thread parameters based on the received running status information, so as to determine whether the target system where the client is located currently needs to adjust the thread parameters, and then give the client corresponding feedback.
[0056] S24: The server generates thread parameters based on the running status information.
[0057] In the server, different running status information and their corresponding thread parameters are stored in advance. The thread parameters corresponding to these running status information are all thread parameters summarized in advance through experience, practice, testing, etc. In some embodiments, the thread parameters corresponding to the running status information are the optimal thread parameters summarized in advance through experience, practice, testing, etc. After the server receives the running status information, it matches the received running status information among the various running status information stored in advance, and then uses the thread parameters corresponding to the successfully matched running status information as the thread parameters determined this time.
[0058] The matching here can refer to similarity calculation. For successful matching, it can mean that the similarity is greater than a preset value. The specific size of the preset value can be determined according to the precision requirement for dynamic adjustment of thread parameters. The higher the precision requirement for dynamic adjustment of thread parameters, the larger the preset value. The lower the precision requirement for dynamic adjustment of thread parameters, the smaller the preset value.
[0059] In the server, a calculation model can also be configured in advance. This calculation model can calculate the corresponding thread parameters according to the input running status information. The calculation model can be a specific calculation formula. The calculation formula can be obtained according to the specific relationship between the running status information and the thread parameters. The calculation model can also be a neural network model. The neural network model can adopt a general model architecture and be trained with known and well-performing running status information and their corresponding thread parameters. After the server receives the running status information, it inputs the received running status information into the calculation model. The output of the calculation model is the thread parameters determined this time.
[0060] S25: The server sends the thread parameters to the client.
[0061] After the server determines the thread parameters for this time, it can directly send the determined thread parameters to the client so that the client can determine whether to adjust the current thread parameters based on the thread parameters determined this time. For example: The server determines the thread parameter 10, and the server sends the thread parameter 10 to the client. The client compares the received thread parameter 10 with the current thread parameter 8 and determines to modify the current thread parameter, so as to change the current thread parameter from 8 to 10. Another example: The server determines the thread parameter 8, and the server sends the thread parameter 8 to the client. The client compares the received thread parameter 8 with the current thread parameter 8 and determines that there is no need to modify the current thread parameter, thus ending the adjustment of the thread parameters for this time.
[0062] In the server, the thread parameters determined each time can also be stored. After the server determines the thread parameters for this time, it can first compare the thread parameters determined this time with the thread parameters determined in the previous time. If the comparison is inconsistent, it means that the optimal thread parameter configuration corresponding to the client has changed, and it is necessary to adjust the current thread parameters of the client, and then send the thread parameters determined this time to the client. If the comparison is consistent, it means that the optimal thread parameter configuration corresponding to the client has not changed. At this time, there is no need to adjust the current thread parameters of the client. However, in order to let the client know that the server has determined the thread parameters for this time, the thread parameters determined this time can still be sent to the client.
[0063] That is to say, the comparison of the thread parameters determined in the previous and current times can be implemented on the client side or on the server side.
[0064] In the implementation on the server side, when the server just starts running and the client sends the running status information to the server for the first time, it also needs to send the currently configured thread parameters to the server at the same time. In this way, after the server determines the thread parameters based on the running status information sent by the client, it can compare the determined thread parameters with the currently configured thread parameters of the client. When the determined thread parameters are different from the currently configured thread parameters of the client, the server sends the determined thread parameters to the client to adjust the thread parameters configured in the client. When the determined thread parameters are the same as the currently configured thread parameters of the client, the server can return a mark indicating no modification to the client.
[0065] Whether it is the thread parameters received by the server at the initial run from the client or the thread parameters determined subsequently based on the running status information sent by the client, the thread parameters and the acquisition time of the thread parameters will be stored correspondingly. In this way, when the server receives the running status information sent by the client at a certain time and determines the thread parameters based on the received running status information, it can compare the currently determined thread parameters with the thread parameters determined at the previous time, and then determine whether to send the currently determined thread parameters to the client based on whether the comparison is consistent. If the comparison is consistent, the currently determined thread parameters are sent. If the comparison is inconsistent, the currently determined thread parameters are not sent.
[0066] To save storage space in the server, only the most recently determined thread parameters can be stored in the server. For example: The client sends the currently configured thread parameter 0 and the running status information 1 to the server. The server stores the thread parameter 0 and determines the thread parameter 1 based on the running status information 1. The thread parameter 1 is inconsistent with the thread parameter 0. The server sends the thread parameter 1 to the client, deletes the thread parameter 0, and stores the thread parameter 1. Thereafter, the client sends the running status information 2 to the server. The server determines the thread parameter 2 based on the running status information 2. If the thread parameter 2 is inconsistent with the thread parameter 1. The server sends the thread parameter 2 to the client, deletes the thread parameter 1, and stores the thread parameter 2. If the thread parameter 2 is consistent with the thread parameter 1. The server does not send any information to the client and still saves the thread parameter 1.
[0067] With the continuous use of the client thread pool, the client will continuously send running status information to the server. The server will also determine the thread parameters based on the running status information sent by the client, and judge whether the newly determined thread parameters are the same as the previous thread parameters of the client thread pool. When they are different, the newly determined thread parameters and the modification flag are sent to the client, and when they are the same, the no-modification flag is sent to the client. If the client's thread pool is shut down midway, then when the thread pool is started again next time, the server determines new thread parameters based on the running status information sent by the client, so as to determine whether to send new thread parameters to the client.
[0068] S26: The client receives the thread parameters sent by the server.
[0069] After the client receives the thread parameters fed back by the server, it can configure the current thread parameters in the target system based on the received thread parameters.
[0070] S27: The client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters.
[0071] For thread parameters, it can include the number of active threads, the number of core threads, and the maximum number of threads. The number of active threads will change continuously as the target system runs. However, the number of core threads and the maximum number of threads will not change automatically as the target system runs. Therefore, what is dynamically configured and adjusted here are the number of core threads and the maximum number of threads.
[0072] Among the thread parameters sent from the server to the client, when there are multiple specific thread numbers, different specific thread numbers are configured with different identifiers. The identifier can uniquely represent the specific thread number. Different identifiers can distinguish different specific thread numbers in the thread parameters so that the client can accurately update the corresponding specific thread number based on the identifier. For example: The thread parameters sent from the server to the client include a-10, b-20. Among them, a is the identifier of the number of core threads, and b is the identifier of the maximum number of threads. After the client obtains the thread parameters, based on the identifier, it can configure the current number of core threads to 10 and the maximum number of threads to 20. Of course, a and b here are only examples of identifiers. For the specific content of the identifier, as long as different thread numbers can be distinguished, no specific limitation is made here.
[0073] After the client receives the thread parameters fed back by the server, it can compare the received thread parameters with the current thread parameters. If the comparison is consistent, it means that the current thread parameters of the target system are optimal and there is no need to adjust the thread parameters. If the comparison is inconsistent, it means that the current thread parameters of the target system are not optimal, and thus the current thread parameters are modified to the thread parameters received this time, realizing real-time and accurate adjustment of the thread parameters of the target system.
[0074] During the process of dynamic configuration, it can be set in the client that "the thread parameter is the parameter sent by the server". In this way, the parameter received by the client from the server can be automatically configured as the thread parameter. It can save the steps of the client comparing the thread parameters. In the case where the thread parameter comparison is inconsistent, it can more quickly realize the modification of the thread parameter configuration and improve the efficiency of modifying the thread parameter. In the case where the thread parameter comparison is consistent, it can continuously refresh the thread parameter configuration to ensure that the threads in the thread pool can be effectively called.
[0075] As can be seen from the above, in the target system where dynamic configuration of thread parameters is to be performed according to the embodiments of the present application, only the client of the thread pool dynamic management device is installed. The client obtains the running state information of the target system, and then sends the obtained running state information to the server outside the target system, so that the server determines the thread parameters of the target system based on the running state information of the target system. Then, the client dynamically configures the thread parameters in the thread pool of the target system according to the determined thread parameters. In this way, only the client needs to be installed in the target system to achieve dynamic configuration of the thread parameters in the target system. There is no need to install and adapt more components, reducing the complexity of the system user's operation, and further reducing the access and maintenance costs of dynamic configuration of thread parameters.
[0076] Further, as a refinement and extension of the Figure 2 method shown, the embodiments of the present application also provide a method for dynamically configuring thread parameters.
[0077] Figure 3 For the flow diagram of the method for dynamically configuring thread parameters in the embodiments of the present application Figure 2 , see Figure 3 shown. The method may include: S31 - S311.
[0078] S31: The client obtains the running state information of the target system.
[0079] The specific implementation manner of step S31 here is the same as that of step S21 in the foregoing embodiments. For relevant descriptions, reference can be made to the foregoing embodiments, and details will not be elaborated here.
[0080] S32: The client sends the running state information and the name of the server to the server according to the address of the server.
[0081] In the client, the address and name of the server need to be preset. In this way, the client can send the running state information and the name of the server to the server simultaneously based on the stored address.
[0082] Since the address and name of the server stored in the client are obtained and stored under the authorization of the server, the correct sending of the client running state information can be ensured according to the stored address.
[0083] While sending the running status information, also carrying the name of the server can enable the server to correctly distinguish the received information. Because under normal circumstances, the client only sends the running status data to the server according to the address. Here, however, the client will also carry the name of the server at the same time. And malicious third parties do not know that they need to carry the name of the server when sending running status information to the server. Therefore, in the interference information sent by malicious third parties to the server, there may only be running status information and not necessarily the name of the server. Moreover, the name of the server is also pre-agreed between the client and the server and is generally not known to the outside world. Even if a malicious third party carries the name of the server when sending false running status information to the server, the name carried may be incorrect. So, after the server receives the running status information, first, it can check whether the running status information carries the name of the server at the same time. If it does, continue with the next verification. If not, it is determined that there is a security problem with the received running status information, discard the running status information, and do not continue to process the running status information. Next, the server can check whether the name carried by the running status information is correct. If it is correct, it can be determined that the received running status information is sent normally by the client and continue to process. If it is incorrect, it is determined that there is a security problem with the received running status information, discard the running status information, and do not continue to process the running status information, thus avoiding congestion or even collapse of the server due to processing a large amount of false running status information and ensuring the safe and stable operation of the server.
[0084] In the client, there may be multiple addresses stored. Different addresses point to different locations. For example: Address 1 points to the server, and Address 2 points to other business systems, etc. When the client needs to send the obtained running status information to the server, it can also determine the address corresponding to the server from multiple addresses through the name of the server, so as to ensure the correct sending of the running status information.
[0085] In addition to the client directly sending the running status information to the server, the client can also control the target system to send its running status information to the server. Specifically, when the client is installed in the target system, the client stores the address and name of the server in the preset module that generates the running status information in the target system, and places a program in this preset module. This program can control the preset module to send the running status information to the server according to the stored name and address. The client also places a program in the preset module for managing the thread pool. This program can obtain the thread parameters fed back by the server and adjust the currently configured thread parameters based on these thread parameters.
[0086] Correspondingly, the above step S32 may include: The client sends the running status information and the name of the server to the server according to the address of the server through the preset module.
[0087] That is to say, in the target system, a client is installed. The client stores the name and address of the server in a preset module in the target system. Specifically, the preset module is a module in the target system that can obtain the running state information of the thread pool. After obtaining the running state information of the thread pool, the preset module can send the running state information and the stored name of the server to the server according to the stored address of the server.
[0088] Generally speaking, the above-mentioned preset module can adopt an existing module in the target system. In this way, the client installed in the target system only needs to have the implantation function of the name of the server, the address of the server, the instruction for the control module to send the running state information, etc., and does not need to have the functions of obtaining and sending the running state information, reducing the amount of data of the client itself, and thus reducing the storage burden of the target system. Moreover, after the client is installed, functions such as obtaining and sending the running state information are implanted into the corresponding preset module. Even if the user of the target system needs to uninstall some applications or tools for some reason and the client is selected to be uninstalled, the thread parameter dynamic configuration function can still be guaranteed to run in the target system, expanding the usage scenarios of the thread parameter dynamic configuration.
[0089] S33: The server receives the running state information and name of the target system sent by the client.
[0090] After receiving the running state information and name, the server first verifies the name. Specifically, it can compare the received name with its own name. If they are the same, it means that the expected destination of the client to send is the same as the actual destination, and the server can continue to determine the thread parameters based on the running state information. If they are different, it means that the expected destination of the client to send is different from the actual destination, which may be that the client mis-sends other information to the server. At this time, the server no longer determines the thread parameters based on the received information, and can directly discard the received information, or store the received information for subsequent verification, or feedback an error prompt to the client.
[0091] S34: The server generates thread parameters based on the running state information.
[0092] The specific implementation method of step S34 here is the same as that of step S24 in the foregoing embodiment. For relevant descriptions, reference can be made to the foregoing embodiment and will not be elaborated here.
[0093] Generally speaking, as a virtual system, the target system needs to be installed and run on a certain physical device. In the physical device, there may not only be the target system, but also multiple other systems. In the physical device, different systems are correspondingly configured with different thread pools, and thus correspondingly configured with separate thread parameters. Different systems belong to the same device, and the resources provided by the device are limited. Therefore, when adjusting the thread parameters of the target system, the running states of other systems also need to be considered.
[0094] In practical applications, the running state information may include the system name of the target system, the node name of the device where the target system is located, and the running state information of each thread pool in the device. Among them, the system name is used to distinguish different systems in the device. The node name is used to determine the device, and thus determine the upper limit of the number of threads in the device, that is, the total number of threads. In each thread pool, there are thread pools corresponding to the target system and other systems. The running state information of the thread pool can refer to any information related to thread calls in the thread pool, such as: the currently configured thread parameters, the priority of the system corresponding to the thread pool, etc.
[0095] S35: The server adjusts the generated thread parameters based on the actual situation of the device where the target system is located to obtain the final thread parameters of the target system.
[0096] Specifically, the above step S35 may include:
[0097] Step A1: The server determines the total number of threads according to the node name.
[0098] In a distributed system, according to the uses and importance levels of different nodes, different amounts of resources are allocated to different node devices, and thus the total number of threads corresponding to different devices is different. According to the node name of the device where the target system is located, the total number of threads of the device where the target system is located can be found in the preset table of the distributed system.
[0099] Step A2: The server determines the target thread pool of the target system from all the thread pools in the device according to the system name.
[0100] In the device, different systems correspond to different thread pools. Through the system name of the target system, the thread pool of the target system, that is, the target thread pool, can be accurately locked from all the thread pools in the device.
[0101] Step A3: The server adjusts the thread parameters according to the total number of threads, the running state information of the target thread pool, and the running state information of other thread pools in all the thread pools except the target thread pool to obtain the final thread parameters of the target system.
[0102] After determining the total number of threads of the device and differentiating the running status information of the target thread pool from that of other thread pools, it is possible to determine the differences between the target thread pool and other thread pools in terms of invocations and other situations. Furthermore, based on the total number of threads, it can be judged whether the currently generated thread parameters are reasonable, so that a reasonable set of thread parameters can ultimately be obtained for use by the target system, ensuring that other systems in the device where the target system is located can also obtain a reasonable number of threads for use, thereby ensuring the stable operation of the device.
[0103] In the adjustment of thread parameters, the increase, decrease, and the amount of increase or decrease of thread parameters are related to the total number of threads and the running status information of other thread pools. The more the total number of threads, the more idle the systems corresponding to other thread pools, and the lower the priority of the systems corresponding to other thread pools, the thread parameters can be appropriately increased. The fewer the total number of threads, the busier the systems corresponding to other thread pools, and the higher the priority of the systems corresponding to other thread pools, the thread parameters can be appropriately decreased. And the amount of increase or decrease of thread parameters can be specifically determined according to the specific relationship between the total number of threads and the running status information of other thread pools. For example: the change amount of thread parameters = the total number of threads - the number of threads actually required under the running status information of other thread pools. When the change amount of thread parameters is a positive number, it means that based on the currently generated thread parameters of the target system, the value of this change amount can be increased. When the change amount of thread parameters is a negative number, it means that based on the currently generated thread parameters of the target system, the value of this change amount needs to be decreased. Of course, for the calculation of the amount of increase or decrease of thread parameters, a coefficient can also be multiplied in the above calculation equation to make corresponding adjustments according to actual requirements. The specific calculation method for the amount of increase or decrease of thread parameters is not limited here.
[0104] After the server determines the thread parameters, in the server, the previously determined thread parameters are also stored. The server can compare the currently determined thread parameters with the previously determined thread parameters to determine whether the thread parameters currently configured for the target system need to be updated this time.
[0105] On the one hand, if the currently determined thread parameters are different from the thread parameters currently configured for the target system, in this case, thread parameter update is required, and the currently determined thread parameters can be immediately sent to the client so that the client can modify the thread parameters configured in the target system to the currently determined thread parameters, realizing efficient dynamic configuration of thread parameters. On the other hand, if the currently determined thread parameters are the same as the thread parameters currently configured for the target system, in this case, thread parameter update is not required, and after waiting for a period of time, the currently determined thread parameters can be informed to the client so that the client can be aware of the dynamic configuration of thread parameters.
[0106] S36: When the thread parameters change compared to the thread parameters currently configured in the target system, the server sends the thread parameters to the client in real time.
[0107] S37: When the thread parameters do not change compared to the thread parameters currently configured in the target system, the server sends the thread parameters to the client after a preset duration.
[0108] The preset duration here can be 30s, or 3min, etc. The specific size of the preset duration can be determined according to the accuracy requirements of the dynamic configuration of the actual thread parameters.
[0109] The thread parameters determined this time do not change compared to the currently configured thread parameters. During the waiting preset duration, if the thread parameters are determined next time and the thread parameters determined next time are different from the thread parameters determined this time, the server sends the thread parameters determined next time to the client in real time. And the thread parameters determined this time may no longer be sent to the client to save the number of times of sending thread parameters and improve the operating efficiency of the server.
[0110] S38: The client receives the thread parameters sent by the server.
[0111] After the client receives the thread parameters, before modifying the current configuration based on the thread parameters, the client can first analyze the thread parameters to determine whether a thread pool needs to be created for the target system or the current thread pool of the target system needs to be closed through the thread parameters. In this way, after determining to create or close the thread pool, there is no need to modify the thread parameters anymore, reducing the ineffective modification of the thread parameters and improving the efficiency of the dynamic configuration of the thread parameters.
[0112] S39: The client sends the thread parameters to the front-end page and dynamically configures the thread parameters in the thread pool of the target system according to the feedback of the thread parameters from the front-end page.
[0113] For the client, it can directly update the thread parameters in the thread pool according to the thread parameters first sent during the dynamic configuration process by the server, or it can display the thread parameters to the user of the target system and then update the thread parameters in the thread pool according to the instructions of the user.
[0114] For the latter case above, since the client belongs to the back-end service of the target system, therefore, it is also necessary to configure the front-end page of the target system, and the page displays the thread parameters to be updated this time to the user of the target system through the web page or browser, so as to determine whether the client modifies the thread parameters this time according to the instructions of the user.
[0115] Specifically, the above step S39 may include:
[0116] Step B1: The client sends the thread parameters to the front-end page.
[0117] After receiving the thread parameters sent by the server, the client does not immediately update the thread parameters in the target system. Instead, it sends the received thread parameters to the front-end page so that the users of the target system can determine whether to perform this update based on the thread parameters displayed on the front-end page.
[0118] Step B2: The front-end page takes the thread parameters as the thread parameters to be updated and displays the current thread parameters, the thread parameters to be updated, and the parameter update option.
[0119] After receiving the thread parameters sent by the client, the front-end page displays the received thread parameters as the thread parameters to be updated.
[0120] Meanwhile, the front-end page also displays the thread parameters currently configured in the target system. The current thread parameters can be obtained by the front-end page from the target system through the client for its current configured thread parameters, or the front-end page can take the thread parameters received most recently and confirmed by the user for update as the current thread parameters.
[0121] In addition, the front-end page also displays the parameter update option. If the parameter update option is selected, it indicates that dynamic configuration of the thread parameters needs to be performed based on the thread parameters to be updated. If the parameter update option is not selected, it indicates that dynamic configuration of the thread parameters does not need to be performed based on the thread parameters to be updated.
[0122] After seeing the thread parameters to be updated through the front-end page and comparing them with the current thread parameters, if the user of the target system determines that dynamic configuration of the thread parameters needs to be performed, then the user can select the parameter update option. If it is determined that dynamic configuration of the thread parameters is not required, the user does not need to select the parameter update option. After the front-end page displays the thread parameters to be updated for a period of time, if the parameter update option is not selected, it is determined that the parameter update option has been abandoned by the user, that is, this dynamic configuration of the thread parameters is not required.
[0123] For the specific selection method of the parameter update option, it can be pressing the button of the option, or entering a specified character in the option, etc.
[0124] Step B3: The front-end page sends a parameter configuration instruction to the server in response to the selection of the parameter update option.
[0125] After the parameter option is selected, the front-end page generates a parameter configuration instruction and then sends the generated parameter configuration instruction to the server. Here, the parameter configuration instruction can be any character that can represent the need to perform this update of the thread parameters, such as: update, 01, etc.
[0126] After the server receives the parameter configuration instruction, it will send the thread parameters and the corresponding identifier to the client again, so that the client can perform dynamic configuration of the thread parameters. The identifier here can be any pre-agreed character or string, such as: gx, 01, etc.
[0127] Step B4: The server sends the thread parameters to the client again, so that the client can modify the thread parameters in the thread pool of the target system according to the thread parameters received again.
[0128] After the client receives the thread parameters, if it also receives an identifier when receiving the thread parameters, it means that the system user this time needs to perform dynamic configuration of the thread parameters of the target system, then perform dynamic configuration based on the received thread parameters. If it does not receive an identifier when receiving the thread parameters, it means that the system user this time does not need to perform dynamic configuration of the thread parameters of the target system, then no longer perform dynamic configuration based on the received thread parameters.
[0129] S310: The client receives the call instruction sent by the target system.
[0130] Sometimes, for some purpose, the target system needs to close the thread pool in it, or create a new thread pool. At this time, the target system can directly generate a call instruction and send the call instruction to the client to borrow the methods provided in the client to create or close the thread pool.
[0131] S311: When the call instruction represents creating a thread pool, the client sends the thread pool creation method to the target system, so that the target system can create a thread pool using the thread pool creation method.
[0132] S312: When the call instruction represents closing the thread pool, the client sends the thread pool closing method to the target system, so that the target system can use the thread pool closing method to close the thread pool currently in use by the target system.
[0133] In the client, a thread pool creation method and a thread pool closing method are pre-configured, so that when the target system needs to create or close a thread pool, it can directly call the corresponding method. The call instruction can be implemented through an interface, which can reduce the development volume of the target system compared with the development of the thread pool creation and closing methods.
[0134] The thread pool creation method and the thread pool closing method here can adopt any one or more known methods for creating a thread pool and closing a thread pool. The specific types and quantities of the thread pool creation method and the thread pool closing method stored in the client are not limited here.
[0135] In a call instruction, an identifier can be included. This identifier is used to indicate the creation or shutdown of a thread pool. For example, when the identifier is 0, it represents shutting down the thread pool; when the identifier is 1, it represents creating the thread pool. It is also possible to determine the creation or shutdown of the thread pool based on the characters in the call instruction. When the call instruction contains words such as "create", it is determined that the call instruction represents creating the thread pool. When the call instruction contains words such as "close", it is determined that the call instruction represents shutting down the thread pool.
[0136] After the thread pool is created, it needs to be registered in the local cache of the target system. After the thread pool is shut down, the runtime information of the thread pool in the local cache of the target system needs to be deleted.
[0137] So far, the dynamic configuration method of thread parameters provided by the embodiments of this application has been fully described.
[0138] Based on the same inventive concept, as an implementation of the above method, the embodiments of this application also provide a thread pool dynamic management device.
[0139] Figure 4 For the structural schematic diagram of the thread pool dynamic management device in the embodiments of this application, see Figure 4 As shown, the device may include: a client 121 and a server 122. Among them, the client 121 is installed on the target system to be dynamically configured with thread parameters. The server 122 is installed in the background.
[0140] The client 121 is used to obtain the running state information of the target system.
[0141] The client 121 is further used to send the running state information to the server, so that the server generates thread parameters based on the running state information and sends the thread parameters to the client.
[0142] The client 121 is further used to receive the thread parameters sent by the server.
[0143] The client 121 is further used to dynamically configure the thread parameters in the thread pool of the target system according to the thread parameters.
[0144] The server 122 is used to receive the running state information of the target system sent by the client.
[0145] The server 122 is further used to generate thread parameters based on the running state information.
[0146] The server 122 is further used to send the thread parameters to the client, so that the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters.
[0147] Further, as for Figure 4For the refinement and expansion of the device shown, an embodiment of the present application further provides a thread pool dynamic management device.
[0148] Still referring to Figure 4 As shown, the device may include: a client 121 and a server 122.
[0149] When the address and name of the server 122 are stored in the client 121, the client 121 is specifically configured to send the running status information and the name of the server 122 to the server 122 according to the address of the server 122, so that after the name verification of the server 122 passes, thread parameters are generated based on the running status information.
[0150] During the installation process of the client 121 in the target system, the address and name of the server 122 are stored in a preset module in the target system that generates running status information, and the preset module can send the running status information and the name of the server 122 to the address of the server 122. In this case, the client 121 is specifically configured to send the running status information and the name of the server 122 to the server 122 according to the address of the server 122 through the preset module.
[0151] When the device further includes a front-end page that displays the current thread parameters, the thread parameters to be updated, and parameter update options, the client 121 is specifically configured to send the thread parameters to the front-end page.
[0152] The front-end page is configured to use the thread parameters as the thread parameters to be updated, and display the current thread parameters, the thread parameters to be updated, and parameter update options; in response to the selection of the parameter update option, send a parameter configuration instruction to the server 122, so that the server 122 sends the thread parameters to the client 121 again, so that the client 121 modifies the thread parameters in the thread pool of the target system according to the thread parameters received again.
[0153] When the client 121 includes a thread pool creation method and a thread pool closing method, the client 121 is further configured to receive a call instruction sent by the target system; when the call instruction indicates creating a thread pool, send the thread pool creation method to the target system, so that the target system creates a thread pool using the thread pool creation method; when the call instruction indicates closing the thread pool, send the thread pool closing method to the target system, so that the target system closes the currently used thread pool of the target system using the thread pool closing method.
[0154] When the running status information includes the system name of the target system, the node name of the device where the target system is located, and the running status information of each thread pool in the device, and the device includes multiple systems, and different systems correspond to different thread pools, the server 122 is further configured to determine the total number of threads according to the node name; determine the target thread pool of the target system from all the thread pools of the device according to the system name; adjust the thread parameters according to the total number of threads, the running status information of the target thread pool, and the running status information of other thread pools in all the thread pools except the target thread pool, so as to obtain the final thread parameters of the target system.
[0155] The server 122 is specifically configured to, when the thread parameters change compared with the thread parameters currently configured for the target system, send the thread parameters to the client 121 in real time; when the thread parameters do not change compared with the thread parameters currently configured for the target system, send the thread parameters to the client 121 after a preset time period.
[0156] It should be noted here that the description of the above device embodiments is similar to the description of the above method embodiments and has similar beneficial effects to the method embodiments. For the technical details not disclosed in the device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.
[0157] Based on the same inventive concept, an embodiment of the present application further provides an electronic device.
[0158] Figure 5 For the structural schematic diagram of the electronic device in the embodiment of the present application, see Figure 5 As shown, the electronic device may include: a processor 51, a memory 52, and a bus 53; wherein, the processor 51 and the memory 52 communicate with each other through the bus 53; the processor 51 is configured to call program instructions in the memory 52 to execute the methods in the above one or more embodiments.
[0159] It should be noted here that the description of the above electronic device embodiments is similar to the description of the above method embodiments and has similar beneficial effects to the method embodiments. For the technical details not disclosed in the electronic device embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.
[0160] Based on the same inventive concept, an embodiment of the present application further provides a computer-readable storage medium, which may include: a stored program; wherein, when the program runs, it controls the device where the storage medium is located to execute the methods in the above one or more embodiments.
[0161] It should be noted here that the description of the above storage medium embodiments is similar to that of the above method embodiments and has similar beneficial effects to those of the method embodiments. For the technical details not disclosed in the storage medium embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.
[0162] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present application, and all should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims
1. A method for dynamically configuring thread parameters, characterized in that: The method is applied to a thread pool dynamic management device, the device includes a client and a server, the client is installed in a target system to be dynamically configured with thread parameters, and the server is installed in the background, the method includes: The client obtains the operating status information of the target system; The client sends the running status information to the server, so that the server generates thread parameters based on the running status information and sends the thread parameters to the client; The client receives the thread parameter sent by the server; The client dynamically configures thread parameters in a thread pool of the target system according to the thread parameters.
2. The method according to claim 1, characterized in that The client stores the address and name of the server; The client sends the running status information to the server, including: The client sends the running status information and the name of the server to the server according to the address of the server, so that the server generates the thread parameter based on the running status information after verifying the name of the server.
3. The method according to claim 2, characterized in that During the installation of the client in the target system, the address and the name of the server are stored in a preset module for generating the operation status information in the target system, and the preset module is enabled to send the operation status information and the name of the server to the address of the server; The client sends the running status information and the name of the server to the address of the server, including: The client sends the running status information and the name of the server to the server according to the address of the server through the preset module.
4. The method according to any one of claims 1 to 3, characterized in that The client includes a thread pool creation method and a thread pool closing method; Before the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters, the method further includes: The client receives a call instruction sent by the target system; When the calling instruction represents the creation of a thread pool, the client sends the thread pool creation method to the target system, so that the target system adopts the thread pool creation method to create a thread pool; When the calling instruction represents closing the thread pool, the client sends the thread pool closing method to the target system, so that the target system uses the thread pool closing method to close the thread pool currently in use by the target system.
5. The method according to any one of claims 1 to 3, characterized in that The device also includes a front-end page, which displays current thread parameters, thread parameters to be updated, and parameter update options; Before the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters, the method further includes: The client sends the thread parameters to the front-end page; The front-end page uses the thread parameters as thread parameters to be updated, and displays the current thread parameters, the thread parameters to be updated, and parameter update options; In response to the selection of the parameter update option, the front-end page sends the parameter configuration instruction to the server, so that the server sends the thread parameters to the client again, so that the client modifies the thread parameters in the thread pool of the target system according to the thread parameters received again.
6. A method for dynamically configuring thread parameters, characterized in that: The method is applied to a thread pool dynamic management device, the device includes a client and a server, the client is installed in a target system to be dynamically configured with thread parameters, and the server is installed in the background, the method includes: The server receives the operating status information of the target system sent by the client; The server generates thread parameters based on the running status information; The server sends the thread parameters to the client, so that the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters.
7. The method according to claim 6, characterized in that The running status information includes the system name of the target system, the node name of the device where the target system is located, and the running status information of each thread pool in the device, the device includes multiple systems, and different systems correspond to different thread pools; After the server generates thread parameters based on the running status information, the method further includes: The server determines the total number of threads according to the node name; The server determines the target thread pool of the target system from all thread pools of the device according to the system name; The server adjusts the thread parameters according to the total number of threads, the running status information of the target thread pool, and the running status information of other thread pools in all thread pools except the target thread pool, to obtain the final thread parameters of the target system.
8. The method according to claim 6, characterized in that The server sends the thread parameter to the client, including: When the thread parameter changes compared to the thread parameter currently configured in the target system, the server sends the thread parameter to the client in real time; When the thread parameter does not change compared to the thread parameter currently configured in the target system, the server sends the thread parameter to the client after a preset time.
9. A thread pool dynamic management device, characterized in that: The device includes a client and a server, wherein the client is installed in a target system to be dynamically configured with thread parameters, and the server is installed in the background; wherein, The client is used to obtain the operating status information of the target system; The client is further configured to send the running status information to the server, so that the server generates thread parameters based on the running status information and sends the thread parameters to the client; The client is further used to receive the thread parameters sent by the server; The client is also used to dynamically configure the thread parameters in the thread pool of the target system according to the thread parameters.
10. A thread pool dynamic management device, characterized in that: The device includes a client and a server, wherein the client is installed in a target system to be dynamically configured with thread parameters, and the server is installed in the background; wherein, The server is used to receive the operating status information of the target system sent by the client; The server is further configured to generate thread parameters based on the running status information; The server is further configured to send the thread parameters to the client, so that the client dynamically configures the thread parameters in the thread pool of the target system according to the thread parameters.