Method and device for dynamically adjusting threads of thread pool, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, can be applied to the field of science and technology finance / digital medical treatment, and discloses a method and device for dynamically adjusting threads of a thread pool, electronic equipment and a storage medium. The method comprises the steps that initialization setting is conducted on thread pool parameters through a management center of a target service system; when a thread pool parameter adjustment request is received, generating a first thread pool parameter according to the thread pool parameter adjustment request; receiving a configuration change event through a configuration change monitor, and analyzing the configuration change event to obtain a first thread pool parameter; positioning a thread pool configuration field of the distributed service instance according to a mapping relation between a program entity factory and a parameter cache; injecting the first thread pool parameter into a thread pool component instance of the distributed service instance; and calling the setting function of the distributed service instance, and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance. The method improves the adaptability of the system to load change, and breaks through the system performance bottleneck.

Description

Technical Field

[0001] The present application relates to the field of computer technology and can be applied to the fields of science and technology finance / digital medicine, and in particular to a method, apparatus, and related equipment for dynamically adjusting thread pool threads. Background Art

[0002] In financial sectors like health insurance, core insurance systems generally feature three generations of architectures coexisting. From the early first-generation architecture, based on Enterprise JavaBeans (EJB), to the second-generation architecture, based on Enterprise Service Bus (ESB), to the current third-generation architecture, which is primarily based on microservices, thread pools, as core components of microservices architectures, are valued for improving the system's concurrent processing capabilities, optimizing resource utilization, and reducing customer synchronization wait times through asynchronous processing (e.g., responsiveness to insurance policy information modifications, claims applications, and other insurance preservation operations). However, existing thread pool technology has significant limitations: core parameters such as the number of threads and queue length are typically fixed and pre-set. Adjusting these parameters requires stopping and restarting the service, making it impossible to dynamically scale based on real-time load. For example, during the health insurance industry's "opening red" rush sales or limited-time insurance product promotions, the system may handle tens of thousands of customer preservation requests (such as policy appointments, rights changes) in a short period of time. The fixed thread pool may have insufficient threads, resulting in tasks piling up in the queue, causing the response time to instantly surge from the normal millisecond level to the second level, or even causing the system to freeze due to processing bottlenecks. Similar problems are also common in medical scenarios: taking the hospital appointment registration system as an example, instantaneous high-concurrency requests often occur during the flu season or when specialist appointments are released. If the fixed thread pool does not reserve enough thread resources, it may cause slow page loading, repeated user refreshes causing traffic avalanches, or even system crashes. Conversely, during non-peak hours (such as at night), maintaining a high thread configuration in the fixed thread pool will result in a waste of resources. In addition, the "black box" nature of parameter configuration further exacerbates technical risks. Developers lack real-time data support and can only rely on experience to set the number of core threads (for example, the common "20-thread threshold", while actual business peaks may require more than 50 threads for smooth operation). The aforementioned configuration method that relies on manual experience poses high technical risks in delay-sensitive scenarios such as real-time computing of financial risk control and AI analysis of medical images. Summary of the Invention

[0003] The main technical problem solved by the implementation method of this application is that the existing thread pool parameters are fixed and require shutdown for adjustment, which cannot cope with the resource waste and performance bottleneck caused by load changes.

[0004] To solve the above technical problems, the first technical solution adopted in the embodiment of the present application is: providing a method for dynamically adjusting thread pool threads, including: initializing and setting the thread pool parameters of the target business system through a management center composed of a target management component in the target business system; when a thread pool parameter adjustment request is received, the management center generates a first thread pool parameter according to the thread pool parameter adjustment request, synchronously stores the first thread pool parameter to the database, and broadcasts a configuration change event containing the first thread pool parameter; receives the configuration change event through a configuration change listener registered when the distributed service instance is started, and parses the configuration change event to obtain the first thread pool parameter; locates the corresponding thread pool configuration field in the thread pool component of the distributed service instance according to the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized; injects the first thread pool parameter into the thread pool component instance of the distributed service instance through a field accessor in a preset reflection toolkit to overwrite the old thread pool configuration field in the thread pool component instance; calls the setting function of the distributed service instance to reset the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field.

[0005] Optionally, the step of injecting the first thread pool parameter into the thread pool component instance of the distributed service instance through the field accessor in the preset reflection toolkit to overwrite the old thread pool configuration field in the thread pool component instance includes: obtaining the class object corresponding to the thread pool component through the class loader of the distributed service instance, and generating a reflection instance based on the class object; searching for the corresponding target field in the reflection instance according to the name of the thread pool configuration field, calling the accessibility setting function of the target field to set the target field to be modifiable; converting the first thread pool parameter into the native data class corresponding to the target field. type, injecting the converted first thread pool parameters into the thread pool component instance through the accessor of the target field to overwrite the old thread pool configuration fields in the thread pool component instance; when the injection process is completed, calling the parameter verification function of the thread pool component instance to check whether the injected new parameters meet the preset constraints. If the check passes, the status update mark inside the thread pool in the distributed service instance is triggered; the change record of the first thread pool parameters is stored in the local cache of the distributed service instance, and a configuration change audit log is generated, which includes recording the change time, the parameter values ​​before and after the change, and the service instance identifier that performs the change.

[0006] Optionally, the step of calling the setting function of the distributed service instance and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field includes: judging the parameter change type corresponding to the thread pool parameter adjustment request according to the overwritten thread pool configuration field, and generating a configuration change instruction according to the parameter change type; calling the parameter setting function of the thread pool component according to the configuration change instruction, and synchronizing the changed parameter value to the runtime state of the thread pool component; calling the state adjustment function of the thread pool component to perform corresponding thread operations according to the new parameter value, if the number of core threads increases, creating a new worker thread; if the number of core threads decreases, terminating the idle worker thread; if the queue capacity changes, adjusting the maximum capacity of the task queue; calling the state query function of the thread pool component to obtain the current actual running parameters of the thread pool component instance, comparing the obtained current actual running parameters with the overwritten thread pool configuration field, and confirming that the configuration parameter change has been successfully effective; and publishing a configuration change success event containing the changed configuration parameters and the effective timestamp through the event publishing mechanism of the distributed service instance.

[0007] Optionally, when a thread pool parameter adjustment request is received, the step of generating the first thread pool parameter according to the thread pool parameter adjustment request by the management center includes: parsing the thread pool parameter adjustment request, and determining whether the request type of the thread pool parameter adjustment request is a manual adjustment request or an automatic adjustment request; calling a preset parameter calculation strategy according to the request type; if the request type is a manual adjustment request, using the parameter value manually entered in the thread pool parameter adjustment request as the first thread pool parameter; if the request type is an automatic adjustment request, calculating the first thread pool parameter according to preset load monitoring indicator data and a preset dynamic adjustment algorithm.

[0008] Optionally, after the step of calculating the first thread pool parameters based on the preset load monitoring indicator data and the preset dynamic adjustment algorithm, the step also includes: performing a compliance check on the generated first thread pool parameters; if the compliance check passes, then synchronously generating a thread pool parameter change plan, the thread pool parameter change plan including a parameter snapshot before the change, an expected performance impact assessment, a change rollback condition, and a change rollback operation step; judging whether the first thread pool parameters need to be reviewed based on a preset approval policy; if a review is required, then pushing the thread pool parameter adjustment request and the thread pool parameter change plan to the review process; if the result of the review process is that the review is passed, or if a review is not required, then continuing to execute the steps between the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance based on the overwritten thread pool configuration field.

[0009] Optionally, after the step of calling the setting function of the distributed service instance and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field, the method further includes: extracting the multidimensional load characteristics of the target business system, and constructing a historical feature vector including the distribution of business request types, time characteristics, and resource consumption; using the historical feature vector and preset system performance indicators to train a load prediction model based on a long short-term memory network; constructing a reinforcement learning environment with the optimization goals of maximizing the throughput and minimizing the response time of the target business system, and dynamically adjusting the weights of the system throughput and the response time according to the service level agreement priority of the target business system through the hierarchical analysis method; using The policy gradient algorithm trains the intelligent agent in the reinforcement learning environment, and generates a thread pool parameter decision model by interacting with the simulated business system behavior; deploys the trained load prediction model and the thread pool parameter decision model to the inference engine of the distributed service instance, and receives the preset type of monitoring data of the target business system in real time; inputs the monitoring data to the load prediction model to obtain the first load prediction result of the target business system, inputs the first load prediction result to the thread pool parameter decision model to obtain the new first thread pool parameters that match the current load of the target business system; and uses the new first thread pool parameters to reset the corresponding configuration parameters in the thread pool component of the distributed service instance.

[0010] Optionally, after the step of using the new first thread pool parameters to reset the corresponding configuration parameters in the thread pool component of the distributed service instance, it also includes: regularly collecting multi-dimensional operation data and operation performance indicator data of the target business system, constructing a new feature vector including business request type distribution, time characteristics, and resource consumption, and using the new feature vector and the operation performance indicator data to construct an incremental training data set; using the incremental training data set to incrementally train the load prediction model and the thread pool parameter decision model through a transfer learning mechanism, and fine-tuning the model parameters through a batch gradient descent algorithm; incrementally updating the load prediction model and the thread pool parameter decision model after the incremental training is completed, and when a new thread pool parameter adjustment request is received, generating new first thread pool parameters through the incrementally updated load prediction model and the thread pool parameter decision model.

[0011] In order to solve the above technical problems, the second technical solution adopted by the embodiment of the present application is: to provide a device for dynamically adjusting thread pool threads, including: a thread pool parameter initialization module, which is used to initialize and set the thread pool parameters of the target business system through a management center composed of target management components in the target business system; a thread pool parameter adjustment request module, which is used to generate a first thread pool parameter according to the thread pool parameter adjustment request through the management center when receiving a thread pool parameter adjustment request, synchronously store the first thread pool parameter in a database, and broadcast a configuration change event containing the first thread pool parameter; a configuration change event listening module, which is used to receive the configuration change event through a configuration change listener registered when the distributed service instance is started, Parse the configuration change event to obtain the first thread pool parameters; a thread pool configuration field module is used to locate the corresponding thread pool configuration field in the thread pool component of the distributed service instance according to the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized; a thread pool parameter reflection injection module is used to inject the first thread pool parameters into the thread pool component instance of the distributed service instance through the field accessor in the preset reflection toolkit to overwrite the old thread pool configuration field in the thread pool component instance; a thread pool parameter reset module is used to call the setting function of the distributed service instance to reset the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field.

[0012] To solve the above technical problems, the third technical solution adopted in the implementation of the present application is: to provide an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method for dynamically adjusting thread pool threads as described above.

[0013] In order to solve the above technical problems, the fourth technical solution adopted in the implementation of the present application is: providing a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are executed by an electronic device, the electronic device executes the method for dynamically adjusting thread pool threads as described above.

[0014] Different from the related technologies, this application realizes the centralized dynamic management of thread pool parameters through the management center, and uses the distributed event monitoring mechanism to ensure the real-time synchronization of configuration changes, avoiding the response lag problem of traditional static configuration. Utilizing the reflection mechanism and parameter mapping relationship, the thread pool parameters are accurately located and safely injected to solve the consistency problem in a multi-threaded environment. Combined with database transactions, compliance verification and audit logs, a technical closed loop for parameter adjustment is formed to improve system stability and traceability. Compared with manual experience or simple threshold strategies, this application reduces operation and maintenance costs and optimizes resource utilization through automated processes. It is especially suitable for scenarios with high requirements for real-time and reliability such as finance and medical care, and significantly enhances the system's adaptability under dynamic loads. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] One or more embodiments are exemplarily illustrated by corresponding drawings, which do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0016] Figure 1 This is a schematic diagram of the operating environment of the method for dynamically adjusting thread pool threads provided in an embodiment of the present application.

[0017] Figure 2 This is a schematic diagram of the execution flow of the method for dynamically adjusting thread pool threads provided in an embodiment of the present application.

[0018] Figure 3 This is a schematic diagram of the execution flow of reflective injection of thread pool parameters in the method for dynamically adjusting thread pool threads provided in an embodiment of the present application.

[0019] Figure 4 This is a schematic diagram of the execution flow of obtaining thread pool parameters through an intelligent model in the method for dynamically adjusting thread pool threads provided in an embodiment of the present application.

[0020] Figure 5 This is a schematic diagram of the system structure of the device for dynamically adjusting thread pool threads provided in an embodiment of the present application.

[0021] Figure 6 This is a hardware structure diagram of an electronic device that executes the method for dynamically adjusting thread pool threads provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0023] It should be noted that, if there is no conflict, the various features in the embodiments of the present application can be combined with each other and are all within the scope of protection of the present application. In addition, although the functional modules are divided in the device schematics and the logical order is shown in the flow charts, in some cases, the steps shown or described can be performed in a different order than the module division in the device schematics or the order in the flow charts.

[0024] Unless otherwise defined, all technical and scientific terms used in this specification have the same meanings as those commonly understood by those skilled in the art to which this application belongs. The terms used in this specification are intended only to describe specific embodiments and are not intended to limit this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the relevant listed items.

[0025] To facilitate understanding of this embodiment, first, a method for dynamically adjusting thread pool threads disclosed in the embodiment of this application is described in detail. Figure 1 , Figure 1 Schematic diagram of the operating environment of the method for dynamically adjusting thread pool threads provided in the embodiment of the present application, such as Figure 1 As shown, the execution subject of the method for dynamically adjusting thread pool threads provided in the embodiment of the present application is generally an electronic device with certain computing capabilities, such as a computer device. In some possible implementations, the method for dynamically adjusting thread pool threads can be implemented by a processor calling computer-readable instructions stored in a memory. Figure 1The computer device in the above can be a server. The server can be an independent server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. It can be understood that Figure 1 The number of computer devices in the figure is only for reference and can be expanded to any number according to actual needs.

[0026] Please continue reading Figure 2 , Figure 2 Schematic diagram of the execution flow of the method for dynamically adjusting thread pool threads provided in the embodiment of the present application, such as Figure 2 As shown, the following steps are included:

[0027] S1. Initialize and set the thread pool parameters of the target business system through a management center based on target management components in the target business system.

[0028] The management center, as the core component of the dynamic adjustment mechanism of the entire application, is usually built based on a distributed architecture and consists of target management components (such as a configuration center, a monitoring module, a decision engine, etc.). The configuration center is responsible for storing and managing the basic configuration of the thread pool, the monitoring module collects the target business system operation data in real time, and the decision engine generates parameter adjustment strategies based on preset rules or algorithms. The aforementioned components implement data interaction and collaborative work through message queues (such as Kafka, RabbitMQ) or RPC frameworks (such as Dubbo, gRPC), ensuring that the management center has high availability and scalability.

[0029] Thread pool parameters include but are not limited to: the number of core threads, the maximum number of threads, and the queue capacity. The number of core threads determines the number of threads that the thread pool maintains in the long term and is suitable for processing regular loads. The maximum number of threads is the upper limit of the maximum number of threads that the thread pool can accommodate and is used to cope with sudden traffic. The queue capacity limits the number of cached tasks to be processed. During initialization, the initial parameter values ​​need to be set in combination with the application characteristics of the target business system (such as peak request volume, task type, and resource limitations). For example, for IO-intensive businesses, the number of core threads can be appropriately increased to improve concurrent processing capabilities. For CPU-intensive businesses, the number of threads needs to be controlled to avoid excessive competition for resources.

[0030] As an example, in a financial trading system, a management center is built on a distributed architecture. The configuration center stores thread pool parameters. The monitoring module collects data such as transaction request volume and order processing time in real time, and the decision engine generates adjustment strategies based on preset algorithms. During thread pool initialization, the number of core threads is set to twice the number of CPU cores to quickly respond to high-frequency requests, considering that thousands of orders may be generated per second during peak trading periods. Furthermore, most transaction requests are I / O-intensive, involving database queries, network communications, and other operations. Therefore, the number of core threads is set to twice the number of CPU cores to quickly respond to high-frequency requests. The maximum number of threads is set to three times the number of core threads based on the server's resource limit to cope with extreme traffic. The queue capacity is set based on the historical peak order backlog to ensure that transaction requests are not lost.

[0031] As another example, in a medical imaging diagnosis system, the management center also adopts a distributed architecture, with various components working together through message queues. When the thread pool is initialized, computations involving 3D reconstruction of medical images, deep learning-assisted diagnosis, and other GPU-intensive tasks require thread parameters to be set based on the number of GPU cores and video memory capacity. However, basic image preprocessing, such as format conversion and noise reduction filtering, still primarily relies on the CPU. Therefore, the number of core threads can be initially set to equal the number of server CPU cores to avoid resource preemption caused by excessive threads. The maximum number of threads is slightly higher than the number of core threads to accommodate multiple users uploading images simultaneously. The queue capacity is conservatively set based on the system's expected concurrent request volume, while a GPU resource scheduling interface is reserved. When the GPU load is low, an appropriate number of threads are allowed to access GPU resources for accelerated processing, preventing diagnostic delays caused by task backlogs and thus ensuring the timeliness and accuracy of medical data processing.

[0032] S2. When a thread pool parameter adjustment request is received, the management center generates first thread pool parameters according to the thread pool parameter adjustment request, synchronously stores the first thread pool parameters in a database, and broadcasts a configuration change event including the first thread pool parameters.

[0033] Among them, the management center receives thread pool parameter adjustment requests through API interfaces or message queues (such as Kafka), and uses an event-driven model to trigger subsequent processing procedures. Request data usually contains metadata such as request type (manual / automatic), trigger conditions (such as manual triggering or system automatic triggering), and business scenario identification to ensure the traceability of request processing. The first thread pool parameters generated are synchronously stored in the configuration center database (such as MySQL+InnoDB) through the database transaction mechanism to ensure the atomicity of parameter storage and configuration change event broadcasting, and avoid data inconsistency caused by network fluctuations. The broadcast is based on the publish-subscribe model (such as Spring Cloud Stream). The management center encapsulates the parameter change event into a JSON format message (including parameter version number, effective time, and adjustment content), and broadcasts it to all distributed service instances through the message bus to ensure the real-time and eventual consistency of the parameter change.

[0034] As an optional implementation, the above step S2 may include the following steps S21 to S24.

[0035] S21. Parse the thread pool parameter adjustment request to determine whether the request type of the thread pool parameter adjustment request is a manual adjustment request or an automatic adjustment request.

[0036] For example, if the request is transmitted via HTTP, parse the request_type field in the URL path or request body (for example, {"type":"auto","trigger":"load_threshold"}). If the request is an RPC call, directly obtain the request type enumeration value through the service interface parameters.

[0037] S22. Call the preset parameter calculation strategy according to the request type.

[0038] S23: If the request type is a manual adjustment request, use the parameter value manually input in the thread pool parameter adjustment request as the first thread pool parameter.

[0039] For example, the manually entered number of core threads, maximum number of threads, and queue capacity are verified within a numerical range (for example, the number of core threads ≥ 1, the queue capacity ≥ 0), and verified by business rules (for example, the maximum number of threads must not exceed 4 times the number of server CPU cores). In addition, the operator who made the manual adjustment, the adjustment time, the original parameter value, and the new parameter value are recorded, and the request ID is associated through a distributed link tracking system (such as OpenTelemetry) to meet the compliance audit requirements of industries such as finance and healthcare. It is optional to implement grayscale release of parameters, that is, first send the manually adjusted parameters to some service instances (for example, 10% of the nodes), observe the system stability, and then release them in full, thereby reducing the operational risks of manual adjustments.

[0040] S24: If the request type is an automatic adjustment request, calculate and obtain first thread pool parameters according to preset load monitoring indicator data and a preset dynamic adjustment algorithm.

[0041] For example, metrics such as CPU utilization, memory usage, thread pool queue wait time, and request response time are collected in real time through monitoring tools like Prometheus and stored in a time-series database (such as InfluxDB) for algorithm invocation. Furthermore, the calculated first thread pool parameters must undergo a reverse validation (for example, ensuring the number of core threads ≤ the maximum number of threads) and be assigned a confidence score (for example, a 90% probability of increased throughput) for decision-making by the management center. At the dynamic adjustment algorithm level, simple threshold rules can be preset (for example, increasing the number of core threads when queue wait time > 500ms), or machine learning models (such as LSTM models combined with reinforcement learning models) can be integrated to map parameters to performance metrics using historical load data to generate the optimal parameter combination. This technical design allows for the flexibility of manual intervention while improving the efficiency and accuracy of parameter adjustment through automated algorithms. It is suitable for business scenarios with high stability and real-time requirements (such as financial transactions and real-time medical data processing).

[0042] As an example, in a securities trading system, during peak trading periods such as opening and closing, the system may generate tens of thousands of order requests per second, triggering automatic adjustment requests. After parsing the request type, the management center enables a dynamic adjustment strategy based on reinforcement learning. It combines real-time order submission volume, matching engine response time, database connection pool utilization and other indicators to calculate the optimized thread pool parameters. For example, the maximum number of threads can be temporarily increased from 500 to 800 to ensure the rapid processing of trading orders. If it is a manual adjustment request, when the operation and maintenance personnel detect abnormal fluctuations in the exchange interface in a certain region, they can manually modify the thread pool parameters, such as lowering the priority of the thread interacting with the interface. After the new parameters are stored, they will be immediately broadcast to all trading nodes through the message queue to ensure the stable operation of the trading system and avoid order backlogs or transaction delays due to improper parameter configuration.

[0043] As another example, in a medical information system, when the hospital's radiology department conducts centralized film reading, the transmission and processing of a large amount of image data will cause a surge in the system load. At this time, the management center may receive an automatic adjustment request. The management center first parses the request to confirm that it is an automatic adjustment type, and then calls a dynamic adjustment algorithm trained based on historical film reading peak data. The algorithm calculates the adaptive thread pool parameters based on monitoring indicators such as the current PACS system's image transmission queue length, server CPU and GPU utilization, such as increasing the number of core threads from 20 to 35 to speed up image processing. If it is a manual adjustment request, when the information department engineer finds that the image processing delay is too high during a certain period of time, he can manually enter the parameters through the management background, such as increasing the queue capacity from 500 to 800. After the adjustment is completed, the new parameters are synchronized and stored in the database, and the configuration change event is broadcast.

[0044] As another optional implementation, after the above step S24, a compliance check may be performed, which may specifically include the following steps S25 to S29.

[0045] S25. Perform compliance check on the generated first thread pool parameters.

[0046] Among them, compliance verification can be implemented through a rule engine. For example, Drools or a self-developed rule engine can be used to define a set of verification rules. For example, business rules may include: the number of core threads ≤ the maximum number of threads, the queue capacity ≥ 0, system constraints may include: the number of threads does not exceed the number of server CPU cores × 2 (to avoid resource exhaustion), and industry compliance may include: medical systems must meet HIPAA regulations, and financial systems must comply with PCI-DSS requirements. During verification, the first thread pool parameters can be encapsulated as a verification object, and the verification is performed through the rule engine, returning the verification results (pass / fail) and a list of violation reasons. If the verification fails, the system rejects the parameter change and triggers an alarm (such as SMS or email notification to the operation and maintenance personnel), and records the violation log for auditing.

[0047] S26. If the compliance check passes, a thread pool parameter change plan is generated synchronously. The thread pool parameter change plan includes a parameter snapshot before the change, an expected performance impact assessment, change rollback conditions, and change rollback operation steps.

[0048] Among them, the parameter snapshot before the change can be intercepted by Spring AOP before the thread pool parameters are changed, and the complete state of the current parameters is saved using deep copy technology (such as Jackson serialization), stored in a distributed cache (such as Redis) and timestamped. The expected performance impact assessment can be based on historical data and simulation tests, using chaos engineering tools (such as Gremlin) to estimate the impact of parameter changes on system throughput and response time, and generate a confidence interval report (such as "expected throughput increase of 5%-10%"). When designing the rollback mechanism, you can define the rollback conditions (such as an increase in the error rate of more than 20% within 5 minutes after the change) and the operation steps (automatic rollback through the configuration center or triggering script execution).

[0049] S27. Determine whether the first thread pool parameters need to be reviewed based on a preset approval policy.

[0050] S28. If review is required, push the thread pool parameter adjustment request and thread pool parameter change plan to the review process.

[0051] S29. If the result of the audit process is that the audit is passed, or if no audit is required, continue to execute the steps between the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field.

[0052] As an example, in a securities trading system, an automatic adjustment algorithm, based on a surge in order requests during the opening hours, calculated that the number of core threads needed to be increased from 300 to 500 to ensure efficient trading. The system then initiated a compliance check to verify that the new parameters met the real-time requirements of securities trading and the system's resource limits, confirming that they did not exceed the server's CPU core count limit. Once the check passed, the system generated a change plan, documenting a snapshot of the pre-change parameters and assessing the estimated 15% reduction in order processing latency after the adjustment. A rollback was also triggered if the error rate exceeded 5%. Due to the significant magnitude of the adjustment during peak trading hours, the system determined that a review was required. The adjustment request and plan were then forwarded to the head of the trading department and risk control specialists for multi-level review. Once approved, the new parameters were distributed to all trading nodes through the configuration center, ensuring the stable processing of tens of millions of orders.

[0053] As another example, in the hospital's electronic medical record system, the automatic adjustment algorithm generates a plan to increase the maximum number of threads from 200 to 300 in response to the increased system load caused by the centralized entry of medical records in the inpatient department. During the compliance verification phase, the system confirms that the new parameters meet HIPAA's requirements for the isolation of patient data processing threads and do not affect the priority of emergency channel data. After the verification is passed, the system generates a contingency plan, records the original parameter configuration, and estimates that the medical record loading speed will increase by 20% after the adjustment. It also specifies that if the response time exceeds 1 second, it will be rolled back immediately. Because it involves core medical data processing, the system triggers the review process and pushes the request and plan to the director of the Information Department and the Medical Affairs Office for joint review. After the review is passed, the new parameters are synchronized to all terminals in the hospital to ensure that doctors can quickly retrieve patient medical records.

[0054] S3. Receive a configuration change event through a configuration change listener registered when the distributed service instance is started, and parse the configuration change event to obtain a first thread pool parameter.

[0055] When a distributed service instance starts, it registers a configuration change listener with the management center (e.g., by subscribing to a topic through a message queue) to ensure that parameter change events can be captured in real time. The management center broadcasts configuration change events through the message queue. The event content includes new thread pool parameters (such as the number of core threads, queue capacity, etc.). After receiving the event, the service instance parses the event data and verifies its integrity (e.g., through signature verification to prevent data tampering). In addition, the parameter version number in the event is compared with the locally cached version. The update process is triggered only when the new version parameters are valid, avoiding duplicate or invalid updates.

[0056] S4. According to the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized, the corresponding thread pool configuration field in the thread pool component of the distributed service instance is located.

[0057] Among them, when the target business system is initialized, the configuration fields of the thread pool component (such as the number of core threads, the maximum number of threads) are mapped to the program entity factory (such as the thread pool instance creation factory) through the configuration center and stored in the memory registry (such as in the form of key-value pairs). After the service instance receives the new parameters, it finds the configuration fields corresponding to the thread pool component according to the mapping relationship in the registry (such as indexed by component name and parameter name), and uses reflection or dependency injection technology (such as Bean management of the Spring framework) to access and modify the real-time configuration of the thread pool component. In addition, when updating the configuration fields, a locking mechanism (such as ReentrantLock) or atomic operations are used to ensure parameter consistency in a multi-threaded environment to avoid system anomalies caused by concurrent modifications.

[0058] S5. Inject the first thread pool parameter into the thread pool component instance of the distributed service instance through the field accessor in the preset reflection toolkit to overwrite the old thread pool configuration field in the thread pool component instance.

[0059] For example, use a pre-defined reflection toolkit (such as Apache Commons Lang's FieldUtils or Spring's ReflectionUtils) to gain access to the thread pool component's private fields. Then, use field accessors (such as the Field.set() method) to write new parameter values ​​(such as the number of core threads) directly into the thread pool instance, overwriting the original configuration. During the injection process, use Field.setAccessible(true) to overcome Java's access control modifier restrictions. Before injection, lock the thread pool instance with ReentrantLock to avoid parameter modification conflicts in a multi-threaded environment and ensure the atomicity of the injection operation.

[0060] As an optional implementation, please continue to refer to Figure 3 , Figure 3 This is a schematic diagram of the execution flow of the reflective injection thread pool parameters in the method for dynamically adjusting the thread pool threads provided by the embodiment of the present application, such as Figure 3 As shown, the following steps S51 to S55 may be included.

[0061] S51. Obtain the class object corresponding to the thread pool component through the class loader of the distributed service instance, and generate a reflection instance according to the class object.

[0062] For example, load the thread pool component class (such as ThreadPoolExecutor) through the context class loader of the distributed service instance (such as Thread.currentThread().getContextClassLoader()). Call Class.forName() to obtain the class object, and then create a reflection instance through newInstance() or getDeclaredConstructor().newInstance() to prepare for subsequent field operations. Verify the class version when loading the class (such as through Package.getImplementationVersion()) to ensure that the target class of the reflection operation is consistent with the compile time to avoid NoSuchFieldException caused by version differences.

[0063] S52. According to the name of the thread pool configuration field, the corresponding target field is searched in the reflection instance, and the accessibility setting function of the target field is called to set the target field to be modifiable.

[0064] For example, use the Class.getDeclaredField() method to search for a target field by field name (e.g., corePoolSize ), supporting nested searches (e.g., traversing parent class fields using getSuperclass() ). Calling Field.setAccessible(true) disables Java's access checking mechanism, allowing modifications to private / protected fields. This operation requires catching a SecurityException and performing a permission check (e.g., using a custom security manager). Use a Field object caching mechanism (e.g., ConcurrentHashMap ) to avoid repeated reflection searches and improve field access efficiency.

[0065] S53. Convert the first thread pool parameter to the native data type corresponding to the target field, and inject the converted first thread pool parameter into the thread pool component instance through the accessor of the target field to overwrite the old thread pool configuration field in the thread pool component instance.

[0066] For example, convert the first thread pool parameter (such as {"corePoolSize":10} in JSON format) to the native type of the target field (such as int) and implement type adaptation using utility classes such as NumberUtils.toInt(). Call the Field.set(object, value) method to inject the converted parameter value into the thread pool instance. For final fields, first modify the final modifier through reflection (for example, using the Unsafe class). Catch exceptions such as IllegalArgumentException, log type mismatch errors, and trigger rollback logic to ensure the safety of parameter injection.

[0067] S54. When the injection process is completed, the parameter verification function of the thread pool component instance is called to check whether the injected new parameters meet the preset constraints. If the check passes, the status update mark inside the thread pool in the distributed service instance is triggered.

[0068] For example, calling the thread pool component's validation function (such as preStartCoreThread()) checks parameter validity (for example, the number of core threads ≤ the maximum number of threads). If the validity is not met, an IllegalStateException is thrown. Calling the thread pool's private methods (such as setCorePoolSize()) through reflection triggers internal state updates and recalculates key indicators such as the number of threads and queue capacity.

[0069] S55: Store the change record of the first thread pool parameters in the local cache of the distributed service instance, and generate a configuration change audit log including the change time, parameter values ​​before and after the change, and the identifier of the service instance that performs the change.

[0070] For example, store parameter change records (e.g., {oldValue: 5, newValue: 10}) in a local cache (e.g., Caffeine) and set a TTL (e.g., 24 hours) to ensure data timeliness. Build a JSON-formatted log containing the change timestamp, service instance ID (e.g., container IP), and operation type, and write it to a distributed logging system (e.g., ELK Stack) using SLF4J.

[0071] As an example, in a bank's core transaction system, in response to peak business such as year-end wealth management sales, the management center issues thread pool parameter adjustment instructions. The system obtains the ThreadPoolExecutor class object through the service instance's class loader. After generating a reflection instance, the system locates private fields such as the number of core threads and the maximum number of threads, overcomes access restrictions, converts the new parameter values ​​from the configuration format to the corresponding native data types, and then injects them into the thread pool component. After injection, a parameter validation function is called to check whether the new parameters comply with the transaction system's resource constraints and risk control rules, such as the core thread number must not exceed three times the number of server CPU cores and the maximum thread number must reserve 20% resource redundancy. If verification passes, the system triggers a thread pool status update, stores the change time, parameter values ​​before and after the change, and the IP address of the service node that executed the change in the local cache, and generates an audit log, ensuring that transaction processing capabilities are improved while meeting the compliance audit requirements of financial regulators.

[0072] As another example, on a regional medical image sharing platform, when multiple hospitals simultaneously upload CT, MRI, and other examination images, the system load increases dramatically. The platform dynamically adjusts the thread pool through a reflection mechanism, using the class loader to obtain the class object of the image processing thread pool component. Through reflection operations, it modifies the access permissions of private fields such as the queue capacity and the number of core threads. The new parameters calculated by the management center (for example, increasing the number of core threads from 15 to 25 and the queue capacity to 500) are converted to the corresponding data type and injected into the thread pool instance. After injection, the system calls the thread pool's parameter validation function to ensure that the new parameters comply with the priority rules and resource allocation policies for medical data processing. For example, the priority of emergency image processing threads is always higher than that of regular images. After verification, the thread pool status is updated to enable the new configuration. The system also records the change details and generates an audit log containing information such as the image processing task type and the level of patient privacy data protection. This improves image processing efficiency while ensuring medical data security and compliance.

[0073] S6. Call the setting function of the distributed service instance and reset the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field.

[0074] Among them, step S6 implements the overwritten thread pool configuration fields into the actually running thread pool component by calling the setting function of the distributed service instance to ensure that the parameter adjustment takes effect. The core is to apply the configuration changes safely and accurately to the system operation state through a standardized function calling process to ensure that the thread pool resource allocation matches the business load.

[0075] As an optional implementation, the above step S6 may specifically include the following steps S61 to S65.

[0076] S61. Determine the parameter change type corresponding to the thread pool parameter adjustment request based on the overwritten thread pool configuration field, and generate a configuration change instruction based on the parameter change type.

[0077] The system determines the type of parameter change based on the overwritten thread pool configuration fields (e.g., the number of core threads, queue capacity, and other parameters, compared with the old and new values) and can determine whether the parameter was added, removed, or adjusted. Depending on the type of change, the system generates corresponding configuration change instructions, such as "add 5 core threads" or "increase queue capacity to 800." The instructions include the operation type, target parameter, and the changed value.

[0078] S62. According to the configuration change instruction, the parameter setting function of the thread pool component is called to synchronize the changed parameter value to the runtime state of the thread pool component.

[0079] Based on the configuration change instructions, the system calls the parameter setting functions of the thread pool component (such as setCorePoolSize and setMaximumPoolSize), synchronizing the changed parameter values ​​to the runtime state of the thread pool component. This process directly modifies the internal parameter variables of the thread pool instance through memory operations, ensuring that the new parameters are immediately applied to the thread pool operation logic, realizing dynamic update of parameter configuration.

[0080] S63. Call the state adjustment function of the thread pool component and execute the corresponding thread operation according to the new parameter value. If the number of core threads increases, a new worker thread is created. If the number of core threads decreases, the idle worker thread is terminated. If the queue capacity changes, the maximum capacity of the task queue is adjusted.

[0081] S64. Call the status query function of the thread pool component to obtain the current actual running parameters of the thread pool component instance, compare the obtained current actual running parameters with the overwritten thread pool configuration fields, and confirm that the configuration parameter changes have successfully taken effect.

[0082] For example, by calling the thread pool component's status query functions (such as getCorePoolSize and getQueue().remainingCapacity), you can obtain the current actual operating parameters of the thread pool component instance. These parameters are compared with the overwritten thread pool configuration fields to verify that the parameter changes have taken effect. If there are any inconsistencies, the exception handling process is triggered to investigate the reasons for the configuration failure, such as function call failures and concurrency conflicts, to ensure that the configuration changes are accurate.

[0083] S65. Publish a configuration change success event including the changed configuration parameters and the effective timestamp through the event publishing mechanism of the distributed service instance.

[0084] After the parameter change takes effect, the distributed service instance broadcasts a configuration change success event through an event publishing mechanism (such as a message queue or event bus), including the changed configuration parameters (such as the latest number of core threads and queue capacity) and the effective timestamp. This event is used to notify the management center, monitoring system, and other related services to update their status in a timely manner, and also provides a basis for subsequent system operation and maintenance, auditing, and performance analysis.

[0085] For example, in a bank's credit card transaction system, to cope with a surge in transaction traffic during a shopping festival, the management center calculated that the number of core threads needed to be increased from 300 to 500 and the queue capacity from 2000 to 5000. The system first determined the change type to be "thread expansion + queue expansion" and generated configuration instructions containing the new parameters. By calling the thread pool's setCorePoolSize and setQueueCapacity functions, the parameters were synchronized to the runtime state. The thread pool then created 200 new worker threads to handle the surge in transaction requests and adjusted the maximum capacity of the task queue. During the verification phase, the system compared the actual operating parameters with the configured fields. Once the changes were confirmed to be effective, it published a success event containing the new parameters (e.g., corePoolSize = 500) and the effective time (e.g., 2025-11-11T20:00:00Z), notifying the risk control system to strengthen real-time monitoring. This ensured the transaction processing system operated stably under high concurrency while meeting the stringent transaction response time requirements of the financial industry.

[0086] As another example, in a hospital HIS system, a public health emergency causes a surge in outpatient volume, and the system needs to increase the number of core threads from 100 to 150 and the maximum number of threads from 200 to 300. The system determines that the change type is "urgent expansion", generates a configuration instruction, and then calls the parameter setting function of the thread pool through reflection to update the runtime state. The thread pool immediately creates 50 new core threads and increases the maximum thread limit to 300 to cope with the surge in patient registration, test and examination requests. After the verification parameters take effect, the system publishes a success event containing the new configuration (such as maxPoolSize=300) and a timestamp (such as 2025-05-21T14:30:00Z), notifying the medical data security module to strengthen the monitoring of patient privacy data processing threads, ensuring compliance with medical data protection regulations such as HIPAA while the system expands, and ensuring patient information security and a smooth diagnosis and treatment process.

[0087] As a preferred embodiment, please continue to refer to Figure 4 , Figure 4 This is a schematic diagram of the execution flow of obtaining thread pool parameters through an intelligent model in the method for dynamically adjusting thread pool threads provided by an embodiment of the present application, such as Figure 4 As shown, the following steps S71 to S77 may be included.

[0088] S71. Extract multi-dimensional load characteristics of the target business system and construct a historical feature vector including business request type distribution, time characteristics, and resource consumption.

[0089] For example, we extract multi-dimensional load characteristics from the historical operational data of the target business system, including the distribution ratio of business request types (such as transaction requests and query requests), temporal characteristics (such as weekday / weekend patterns and peak hour patterns), and resource consumption indicators (such as CPU utilization and memory usage). These characteristics are quantized into vector form (such as [percentage of request type A, percentage of request type B, hour, minute, CPU utilization, memory utilization]) and constructed into a historical feature vector dataset, providing basic input for subsequent model training and ensuring that the model can learn the complex patterns and inherent laws of business load.

[0090] S72. Use historical feature vectors and preset system performance indicators to train a load forecasting model based on a long short-term memory network.

[0091] The historical feature vectors constructed in step S71 and preset system performance indicators (such as throughput and response time) are used to train a load forecasting model based on a long short-term memory (LSTM) network. LSTM, due to its ability to process sequential data, can capture the temporal dependencies and long-term trends of business loads, such as identifying the daily peak transaction pattern between 10:00 AM and 11:00 AM. The model optimizes parameters using a backpropagation algorithm to minimize the error between predicted and actual values. Ultimately, it learns the mapping from load characteristics to future load states, achieving accurate predictions of business system loads.

[0092] S73. Construct a reinforcement learning environment with the optimization goals of maximizing the throughput and minimizing the response time of the target business system, and dynamically adjust the weights of the system throughput and response time according to the service level agreement priority of the target business system through the hierarchical analysis method.

[0093] A reinforcement learning environment is built with the dual objectives of maximizing system throughput and minimizing response time. The state space contains current thread pool parameters, load forecast results, and other parameters, while the action space consists of adjustable thread pool parameters (such as the number of core threads and queue capacity). Using the Analytic Hierarchy Process (AHP), the weights of throughput and response time are dynamically adjusted based on the service-level agreement (SLA) priorities of the business system. For example, for payment services with high real-time requirements, the weight of response time is increased, while for batch data processing services, the emphasis is on throughput optimization, achieving a dynamic balance among multiple objectives.

[0094] S74. Use the policy gradient algorithm to train the intelligent agent in a reinforcement learning environment, and generate a thread pool parameter decision model by interacting with the simulated business system behavior.

[0095] The agent is trained in a reinforcement learning environment using a policy gradient algorithm (such as PPO and A2C). The agent interacts with simulated business system behavior, continuously trying different parameter adjustment strategies and optimizing them based on preset reward functions (such as rewards for increased throughput and reduced response time). During training, the agent learns the decision-making rules for selecting optimal thread pool parameters under different load conditions, ultimately generating a thread pool parameter decision model. This model outputs the optimal parameter configuration based on load prediction results, enabling intelligent decision-making for thread pool parameters.

[0096] S75. Deploy the trained load prediction model and thread pool parameter decision model to the inference engine of the distributed service instance, and receive monitoring data of preset types of the target business system in real time.

[0097] For example, trained load prediction models and parameter decision models are deployed to the inference engine of a distributed service instance (such as TensorFlow Serving or ONNX Runtime). The inference engine receives real-time monitoring data of pre-defined types from the target business system, including metrics such as real-time request volume, resource utilization, and response time. After preprocessing (such as normalization and feature extraction), this data is provided as input to the load prediction model, supporting the model's real-time inference capabilities and ensuring that the system can dynamically adjust thread pool parameters based on the latest operating status.

[0098] S76. Input the monitoring data into the load prediction model to obtain a first load prediction result of the target business system, input the first load prediction result into the thread pool parameter decision model to obtain a new first thread pool parameter that matches the current load of the target business system.

[0099] The inference engine inputs real-time monitoring data into the load prediction model to obtain load prediction results (such as request peaks and resource consumption trends) for a short period of time in the future (e.g., 5 minutes). This prediction result is then input into the thread pool parameter decision model. Based on the strategy obtained through reinforcement learning training, the model calculates new first thread pool parameters that match the current load (for example, recommending a 20% increase in the number of core threads and a 10% reduction in queue capacity), achieving end-to-end intelligent optimization from load prediction to parameter decision-making.

[0100] S77: Use the new first thread pool parameters to reset the corresponding configuration parameters in the thread pool component of the distributed service instance.

[0101] For example, using the new thread pool parameters generated in step S76, the corresponding configuration parameters in the thread pool component of the distributed service instance are reset through the reflection mechanism or the configuration center interface (for example, modifying corePoolSize and maximumPoolSize). After the parameters are updated, the thread pool component adjusts the number of worker threads and task queue capacity according to the new configuration, dynamically matching system resource allocation with business load, ultimately achieving automated and intelligent adjustment of thread pool parameters, improving system performance and resource utilization.

[0102] As an example, in a high-frequency securities trading system, the system collects features such as order type distribution (e.g., the proportion of market orders and limit orders), trading period characteristics (e.g., opening call auction, closing matching peak), and instantaneous CPU and memory utilization to construct a historical feature vector containing nanosecond time slices, order flow density, and cache hit rate. After training, the LSTM model can predict the peak order volume from 2:57 PM to 3:00 PM before the market closes on a specific trading day (e.g., an estimated 500,000 orders per second). In a reinforcement learning environment, based on the trading system's SLA requirements for throughput (60% weighted) and latency (40% weighted), the intelligent agent is trained using the PPO algorithm to generate a decision model that dynamically adjusts the thread pool partitioning strategy under high concurrency (e.g., dividing core threads into market order processing groups and limit order processing groups based on order type). After the model is deployed to the trading node, it obtains data such as order book depth and transaction return delay in real time. When the closing peak is predicted, the core threads for market order processing will be automatically increased from 800 to 1200. The queue capacity is set in layers according to order priority to ensure that the order processing delay is stable within 50 microseconds under extreme traffic, and the throughput is increased by 40%. At the same time, backtesting verifies that the parameter adjustment does not trigger the risk control threshold, ensuring the stability and compliance of the trading system under extreme market conditions.

[0103] As another example, in a medical imaging cloud platform, the system extracts multi-dimensional features such as the image upload volume (e.g., the proportion of CT and MRI images) at each time of the day, the frequency of doctor diagnosis requests, and GPU resource utilization, and constructs a historical feature vector containing timestamps (e.g., 9-11 a.m. is the peak time for diagnosis), request type distribution (e.g., emergency imaging accounts for 20%), and resource consumption (e.g., GPU memory utilization exceeds 80%). Through LSTM model training, the image processing load peak for the next morning is predicted. For example, it is expected that the number of emergency image uploads will surge by 30% at 10 a.m. In a reinforcement learning environment, based on the hospital's SLA requirements for emergency imaging response time (priority weight accounts for 70%), the agent learns through a policy gradient algorithm to generate a parameter decision model for increasing the number of GPU acceleration threads and prioritizing the emergency queue under high emergency load. After the model is deployed, it receives data such as image upload rate and diagnostic response time in real time. When an emergency peak is predicted, the number of GPU core threads is automatically increased from 150 to 200, and the queue capacity is adjusted to prioritize emergency tasks, ensuring that critical patient images are processed and pushed to the diagnostic end within 10 minutes. At the same time, through monitoring and verification, the average response time for emergency images was shortened from 12 minutes to 8 minutes after the parameter adjustment, meeting medical timeliness standards.

[0104] As another preferred implementation, after the above step S77, the above load prediction model and thread pool parameter decision model may be incrementally trained, specifically, including the following steps S81 to S83.

[0105] S81. Regularly collect multi-dimensional operation data and operation performance indicator data of the target business system, construct a new feature vector containing business request type distribution, time characteristics, and resource consumption, and use the new feature vector and operation performance indicator data to construct an incremental training data set.

[0106] For example, multi-dimensional operational data (such as real-time request volume and resource utilization) and performance indicators (such as throughput and response time) are collected from the target business system on a regular basis (e.g., hourly / daily) to construct new feature vectors that include the distribution of business request types (e.g., changes in the proportion of transaction-type requests), time characteristics (e.g., newly added holiday modes), and resource consumption (e.g., fluctuations in GPU utilization). These new feature vectors are combined with the performance indicator data for the corresponding time period to form an incremental training dataset. This dataset retains the distribution characteristics of historical data while incorporating newly emerging business models (e.g., traffic surges caused by promotional activities), ensuring that the model can learn the dynamic changes in the system's operating mode and provide the latest learning materials for subsequent incremental training.

[0107] S82. Use the incremental training dataset to perform incremental training on the load prediction model and thread pool parameter decision model through the transfer learning mechanism, and fine-tune the model parameters through the batch gradient descent algorithm.

[0108] Among them, the incremental training data set constructed in step S81 is used to perform incremental training on the existing load prediction model and thread pool parameter decision model through the transfer learning mechanism. Transfer learning retains the common features learned by the model on historical data (such as the periodic pattern of load), and only adjusts parameters for the unique patterns in the new data (such as sudden traffic peaks). Use a batch gradient descent algorithm (such as the Adam optimizer) to fine-tune the model parameters on the incremental data set to gradually adapt to the new business model. For example, when the system finds that the proportion of a certain type of new business request (such as API gateway calls) continues to rise, the model improves the prediction accuracy of such requests by fine-tuning the weights, while maintaining the prediction ability of the original business type, to achieve continuous optimization of model performance.

[0109] S83. Incrementally update the load prediction model and thread pool parameter decision model after the incremental training is completed. When a new thread pool parameter adjustment request is received, generate new first thread pool parameters through the incrementally updated load prediction model and thread pool parameter decision model.

[0110] Among them, the load prediction model and thread pool parameter decision model after incremental training are deployed to the production environment, replacing the original model to achieve incremental updates. A hot deployment mechanism (such as using a model version control tool) is used during the update process to ensure uninterrupted service. When a new thread pool parameter adjustment request is received, the system uses the incrementally updated model for load prediction and parameter decision-making to generate the first thread pool parameters that are more in line with the current business operation mode. For example, the incrementally trained model can identify and adapt to seasonal business peaks (such as the surge in payment traffic during the Spring Festival), dynamically adjust the thread pool configuration, improve the system's performance in special scenarios, and achieve the synchronous evolution of model capabilities and business needs.

[0111] As an example, in a bank's credit card transaction system, the system collects transaction data from the previous 24 hours every morning (such as transaction type distribution, response time, and CPU utilization). This data is then used to construct a new vector set containing high-frequency transaction features during promotional events like "Double 11," forming an incremental training dataset. Transfer learning preserves the model's predictive power for regular transaction patterns. Batch gradient descent is used to fine-tune the parameters of the LSTM prediction model and reinforcement learning decision model to address new features emerging during promotional events (such as a surge in the proportion of installment payments), enabling the model to more accurately predict traffic peaks during promotional periods. After deploying the incrementally trained model to transaction nodes, the system was able to predict a 200% increase in payment requests 30 minutes in advance during subsequent promotional events. The system automatically increased the number of core threads from 500 to 1500 and adjusted the queue capacity to a tiered priority model. This improved the system's transaction success rate from 98% to 99.5% during the promotional period, while maintaining an average response time below 200 milliseconds, meeting the stringent high availability and low latency requirements of financial systems.

[0112] As another example, within a regional medical imaging platform, the system collects imaging data uploaded by hospitals weekly (e.g., CT / MRI ratio, diagnostic report generation time, and GPU resource consumption) to construct a new vector set encompassing chest CT screening features, which surged during the pandemic. Using a transfer learning mechanism, while retaining the existing disease diagnosis model, the LSTM prediction model and reinforcement learning decision model were fine-tuned to address the new "rapid screening" business needs of the pandemic. For example, after learning that chest CT uploads tripled during the pandemic at 10:00 a.m. on weekdays, the model optimized the thread pool parameter decision strategy, automatically increasing the number of GPU core threads from 100 to 300 during this period and prioritizing emergency image processing. After deploying this incrementally updated model, the system was able to reduce the average processing time for emergency images from 15 minutes to 8 minutes during periods of resurgence, while maintaining the same efficiency for standard image processing. This dynamic adaptation to changing business needs enhanced the medical system's ability to respond to public health emergencies.

[0113] The method for dynamically adjusting thread pool threads provided in the embodiment of the present application realizes dynamic optimization and full life cycle management of thread pool parameters through the collaborative design of a distributed management center and an intelligent algorithm. Based on the distributed architecture of the management center, parameter initialization is completed in combination with business characteristics. During runtime, manual / automatic adjustment modes and message queue broadcast mechanisms are used to ensure the real-time and consistency of parameter changes. The reflection mechanism is used to break through access restrictions, and the lock mechanism is used to realize runtime security injection of thread pool parameters to ensure parameter consistency in a multi-threaded environment. The LSTM load prediction and reinforcement learning decision model is introduced to automatically learn the time dependency and multi-objective optimization strategy of the business load, and realize end-to-end intelligent decision-making from load characteristics to optimal parameters. In addition, by regularly collecting new business data to build an incremental training set, combined with transfer learning and batch gradient descent algorithms, the model can continuously adapt to changes in business models. The compliance verification rule engine and change plan mechanism ensure that parameter adjustments meet industry regulatory requirements, improve the resource utilization and stability of the system under dynamic loads, and significantly reduce manual operation and maintenance costs. It is suitable for scenarios with high requirements for real-time and reliability such as finance and medical care.

[0114] Please continue reading Figure 5 , Figure 5 Schematic diagram of the system structure of the device for dynamically adjusting thread pool threads provided by the embodiment of the present application, such as Figure 5 As shown, the dynamic thread pool thread adjustment device 50 includes: a thread pool parameter initialization module 51, a thread pool parameter adjustment request module 52, a configuration change event monitoring module 53, a thread pool configuration field module 54, a thread pool parameter reflection injection module 55 and a thread pool parameter reset module 56.

[0115] The thread pool parameter initialization module 51 is specifically used to initialize and set the thread pool parameters of the target business system through a management center composed of target management components in the target business system.

[0116] The thread pool parameter adjustment request module 52 is specifically used to generate a first thread pool parameter according to the thread pool parameter adjustment request through the management center when a thread pool parameter adjustment request is received, synchronously store the first thread pool parameter in the database, and broadcast a configuration change event including the first thread pool parameter.

[0117] The configuration change event monitoring module 53 is specifically configured to receive the configuration change event through a configuration change listener registered when the distributed service instance is started, and parse the configuration change event to obtain the first thread pool parameter.

[0118] The thread pool configuration field module 54 is specifically used to locate the corresponding thread pool configuration field in the thread pool component of the distributed service instance according to the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized.

[0119] The thread pool parameter reflection injection module 55 is specifically used to inject the first thread pool parameters into the thread pool component instance of the distributed service instance through the field accessor in the preset reflection toolkit to overwrite the old thread pool configuration fields in the thread pool component instance.

[0120] The thread pool parameter resetting module 56 is specifically used to call the setting function of the distributed service instance and reset the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration fields.

[0121] As an optional implementation, the thread pool parameter reflection injection module 55 is also specifically used to obtain the class object corresponding to the thread pool component through the class loader of the distributed service instance, and generate a reflection instance based on the class object; according to the name of the thread pool configuration field, find the corresponding target field in the reflection instance, call the accessibility setting function of the target field to set the target field to be modifiable; convert the first thread pool parameter into the native data type corresponding to the target field, and inject the converted first thread pool parameter into the thread pool component instance through the accessor of the target field to overwrite the old thread pool configuration field in the thread pool component instance; when the injection process is completed, call the parameter verification function of the thread pool component instance to check whether the injected new parameter meets the preset constraints. If the check passes, the status update mark inside the thread pool in the distributed service instance is triggered; the change record of the first thread pool parameter is stored in the local cache of the distributed service instance, and a configuration change audit log is generated, which includes recording the change time, the parameter values ​​before and after the change, and the service instance identifier that performs the change.

[0122] As an optional implementation, the thread pool parameter reset module 56 is also specifically used to determine the parameter change type corresponding to the thread pool parameter adjustment request based on the overwritten thread pool configuration field, and generate a configuration change instruction based on the parameter change type; according to the configuration change instruction, call the parameter setting function of the thread pool component to synchronize the changed parameter value to the runtime state of the thread pool component; call the state adjustment function of the thread pool component to perform corresponding thread operations according to the new parameter value, if the number of core threads increases, create a new worker thread, if the number of core threads decreases, terminate the idle worker thread, if the queue capacity changes, adjust the maximum capacity of the task queue; call the state query function of the thread pool component to obtain the current actual operating parameters of the thread pool component instance, compare the obtained current actual operating parameters with the overwritten thread pool configuration field, and confirm that the configuration parameter change has successfully taken effect; publish a configuration change success event containing the changed configuration parameters and the effective timestamp through the event publishing mechanism of the distributed service instance.

[0123] As an optional implementation, the thread pool parameter adjustment request module 52 is also specifically used to parse the thread pool parameter adjustment request, determine whether the request type of the thread pool parameter adjustment request is a manual adjustment request or an automatic adjustment request; call the preset parameter calculation strategy according to the request type; if the request type is a manual adjustment request, use the parameter value manually entered in the thread pool parameter adjustment request as the first thread pool parameter; if the request type is an automatic adjustment request, calculate the first thread pool parameter according to the preset load monitoring indicator data and the preset dynamic adjustment algorithm.

[0124] As an optional implementation, the thread pool parameter adjustment request module 52 is also specifically used to perform compliance verification on the generated first thread pool parameters; if the compliance verification passes, a thread pool parameter change plan is synchronously generated, and the thread pool parameter change plan includes a parameter snapshot before the change, an expected performance impact assessment, a change rollback condition, and a change rollback operation step; according to a preset approval policy, whether the first thread pool parameters need to be reviewed is determined; if review is required, the thread pool parameter adjustment request and the thread pool parameter change plan are pushed to the review process; if the result of the review process is that the review is passed, or if review is not required, the steps of resetting the corresponding configuration parameters in the thread pool component of the distributed service instance according to the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized to the overwritten thread pool configuration field are continued.

[0125] As an optional implementation, the dynamically adjusting thread pool thread device 50 further includes a thread pool parameter adjustment model module, which is specifically used to extract the multi-dimensional load characteristics of the target business system, and construct a historical feature vector including business request type distribution, time characteristics, and resource consumption; use the historical feature vector and preset system performance indicators to train a load prediction model based on a long short-term memory network; construct a reinforcement learning environment with the optimization goals of maximizing the throughput and minimizing the response time of the target business system, and dynamically adjust the weights of the system throughput and the response time according to the service level agreement priority of the target business system through the hierarchical analysis method; use the policy gradient algorithm to The intelligent agent is trained in the reinforcement learning environment to generate a thread pool parameter decision model by interacting with the simulated business system behavior; the trained load prediction model and the thread pool parameter decision model are deployed to the inference engine of the distributed service instance, and preset types of monitoring data of the target business system are received in real time; the monitoring data is input into the load prediction model to obtain a first load prediction result of the target business system, and the first load prediction result is input into the thread pool parameter decision model to obtain new first thread pool parameters that match the current load of the target business system; the new first thread pool parameters are used to reset the corresponding configuration parameters in the thread pool component of the distributed service instance.

[0126] As an optional implementation, the thread pool parameter adjustment model module is also specifically used to regularly collect multi-dimensional operation data and operation performance index data of the target business system, construct a new feature vector including business request type distribution, time characteristics, and resource consumption, and use the new feature vector and the operation performance index data to construct an incremental training data set; use the incremental training data set to incrementally train the load prediction model and the thread pool parameter decision model through a transfer learning mechanism, and fine-tune the model parameters through a batch gradient descent algorithm; incrementally update the load prediction model and the thread pool parameter decision model after the incremental training is completed, and when a new thread pool parameter adjustment request is received, generate new first thread pool parameters through the incrementally updated load prediction model and the thread pool parameter decision model.

[0127] It should be noted that the above-mentioned dynamically adjusting thread pool thread device can execute the dynamically adjusting thread pool thread method provided in the embodiment of this application, and has the corresponding functional modules and beneficial effects of the execution method. For technical details not fully described in the embodiment of the dynamically adjusting thread pool thread device, please refer to the dynamically adjusting thread pool thread method provided in the embodiment of this application.

[0128] Figure 6Schematic diagram of the hardware structure of the electronic device 600 for dynamically adjusting the thread pool thread method provided in the embodiment of the present application, such as Figure 6 As shown, the electronic device 600 includes:

[0129] One or more processors 610 and memory 620, Figure 6 A processor 610 is taken as an example.

[0130] The processor 610 and the memory 620 may be connected via a bus or other means. Figure 6 The bus connection is taken as an example.

[0131] Memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs, and modules, such as the program instructions / modules corresponding to the method for dynamically adjusting thread pool threads in the embodiments of the present application. Processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in memory 620, thereby implementing the method for dynamically adjusting thread pool threads in the above method embodiment.

[0132] The memory 620 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the dynamically adjusted thread pool thread device, etc. In addition, the memory 620 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 620 may optionally include a memory remotely located relative to the processor 610, and these remote memories may be connected to the dynamically adjusted thread pool thread device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0133] The one or more modules are stored in the memory 620, and when executed by the one or more processors 610, the method for dynamically adjusting thread pool threads in any of the above method embodiments is executed, for example, the method described above is executed. Figure 2 Steps S1 to S6 of the method, Figure 3 Steps S51 to S55 of the method, Figure 4 Steps S71 to S77 of the method are implemented Figure 5 The functions of modules 51-56 in.

[0134] The above-mentioned product can execute the method provided in the embodiment of this application, and has the functional modules and beneficial effects corresponding to the execution method. For technical details not fully described in this embodiment, please refer to the method provided in the embodiment of this application.

[0135] An embodiment of the present application provides a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are executed by one or more processors, for example Figure 6 A processor 610 in the embodiment may enable the one or more processors to execute the method for dynamically adjusting thread pool threads in any of the above method embodiments, for example, executing the above described Figure 2 Steps S1 to S6 of the method, Figure 3 Steps S51 to S55 of the method, Figure 4 Steps S71 to S77 of the method are implemented Figure 5 The functions of modules 51-56 in.

[0136] The embodiment of the present application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by the electronic device, the electronic device is enabled to perform the method for dynamically adjusting thread pool threads in any of the above method embodiments, for example, performing the above-described Figure 2 Steps S1 to S6 of the method, Figure 3 Steps S51 to S55 of the method, Figure 4 Steps S71 to S77 of the method are implemented Figure 5 The functions of modules 51-56 in.

[0137] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of this embodiment.

[0138] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course by hardware. Those skilled in the art can understand that all or part of the processes in the above embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0139] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Based on the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the present application as described above. For the sake of simplicity, they are not provided in detail. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for dynamically adjusting thread pool threads, characterized in that: include: Initializing and setting thread pool parameters of the target business system through a management center based on target management components in the target business system; When a thread pool parameter adjustment request is received, the management center generates first thread pool parameters according to the thread pool parameter adjustment request, synchronously stores the first thread pool parameters in a database, and broadcasts a configuration change event including the first thread pool parameters; Receiving the configuration change event through a configuration change listener registered when the distributed service instance is started, parsing the configuration change event to obtain the first thread pool parameter; Locating the corresponding thread pool configuration field in the thread pool component of the distributed service instance according to the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized; Injecting the first thread pool parameters into the thread pool component instance of the distributed service instance through a field accessor in a preset reflection toolkit to overwrite the old thread pool configuration fields in the thread pool component instance; The setting function of the distributed service instance is called to reset the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field.

2. The method for dynamically adjusting thread pool threads according to claim 1, wherein: The step of injecting the first thread pool parameters into the thread pool component instance of the distributed service instance through a field accessor in a preset reflection toolkit to overwrite the old thread pool configuration fields in the thread pool component instance includes: Obtaining the class object corresponding to the thread pool component through the class loader of the distributed service instance, and generating a reflection instance according to the class object; According to the name of the thread pool configuration field, searching for a corresponding target field in the reflection instance, and calling an accessibility setting function of the target field to set the target field to be modifiable; Convert the first thread pool parameter to the native data type corresponding to the target field, and inject the converted first thread pool parameter into the thread pool component instance through the accessor of the target field to overwrite the old thread pool configuration field in the thread pool component instance; When the injection process is completed, the parameter verification function of the thread pool component instance is called to check whether the injected new parameters meet the preset constraints. If the check passes, the status update mark inside the thread pool in the distributed service instance is triggered; The change record of the first thread pool parameter is stored in the local cache of the distributed service instance, and a configuration change audit log is generated, which includes recording the change time, parameter values ​​before and after the change, and the service instance identifier that performs the change.

3. The method for dynamically adjusting thread pool threads according to claim 1, wherein: The step of calling the setting function of the distributed service instance and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field includes: Determining, based on the overwritten thread pool configuration field, a parameter change type corresponding to the thread pool parameter adjustment request, and generating a configuration change instruction based on the parameter change type; According to the configuration change instruction, calling the parameter setting function of the thread pool component, and synchronizing the changed parameter value to the runtime state of the thread pool component; Calling the state adjustment function of the thread pool component to perform corresponding thread operations according to the new parameter values, creating new worker threads if the number of core threads increases, terminating idle worker threads if the number of core threads decreases, and adjusting the maximum capacity of the task queue if the queue capacity changes; Calling the status query function of the thread pool component to obtain the current actual running parameters of the thread pool component instance, comparing the obtained current actual running parameters with the overwritten thread pool configuration fields, and confirming that the configuration parameter changes have successfully taken effect; A configuration change success event including the changed configuration parameters and an effective timestamp is published through the event publishing mechanism of the distributed service instance.

4. The method for dynamically adjusting thread pool threads according to claim 1, wherein: The step of generating first thread pool parameters according to the thread pool parameter adjustment request by the management center when the thread pool parameter adjustment request is received includes: Parsing the thread pool parameter adjustment request to determine whether the request type of the thread pool parameter adjustment request is a manual adjustment request or an automatic adjustment request; Calling a preset parameter calculation strategy according to the request type; If the request type is a manual adjustment request, the parameter value manually input in the thread pool parameter adjustment request is used as the first thread pool parameter; If the request type is an automatic adjustment request, the first thread pool parameters are calculated based on preset load monitoring indicator data and a preset dynamic adjustment algorithm.

5. The method for dynamically adjusting thread pool threads according to claim 4, characterized in that: After the step of calculating the first thread pool parameters according to the preset load monitoring indicator data and the preset dynamic adjustment algorithm, the method further includes: Performing compliance check on the generated first thread pool parameters; If the compliance check passes, a thread pool parameter change plan is generated synchronously, and the thread pool parameter change plan includes a parameter snapshot before the change, an expected performance impact assessment, change rollback conditions, and change rollback operation steps; According to a preset approval policy, determining whether the first thread pool parameters need to be reviewed; If an audit is required, the thread pool parameter adjustment request and the thread pool parameter change plan are pushed to the audit process; If the result of the audit process is that the audit is passed, or if no audit is required, continue to execute the steps between the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance based on the overwritten thread pool configuration field.

6. The method for dynamically adjusting thread pool threads according to claim 1, wherein: After the step of calling the setting function of the distributed service instance and resetting the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field, the method further includes: Extracting multi-dimensional load characteristics of the target business system and constructing a historical feature vector including business request type distribution, time characteristics, and resource consumption; Using the historical feature vectors and preset system performance indicators, training a load forecasting model based on a long short-term memory network; Constructing a reinforcement learning environment with the optimization goals of maximizing the throughput and minimizing the response time of the target business system, and dynamically adjusting the weights of the system throughput and the response time according to the service level agreement priority of the target business system through the analytic hierarchy process; Using a policy gradient algorithm to train the agent in the reinforcement learning environment, and generating a thread pool parameter decision model by interacting with the simulated business system behavior; Deploy the trained load prediction model and the thread pool parameter decision model to the inference engine of the distributed service instance, and receive monitoring data of preset types of the target business system in real time; Inputting the monitoring data into the load prediction model to obtain a first load prediction result of the target business system, inputting the first load prediction result into the thread pool parameter decision model to obtain a new first thread pool parameter that matches the current load of the target business system; The corresponding configuration parameters in the thread pool component of the distributed service instance are reset using the new first thread pool parameters.

7. The method for dynamically adjusting thread pool threads according to claim 6, characterized in that: After the step of resetting the corresponding configuration parameters in the thread pool component of the distributed service instance using the new first thread pool parameters, the method further includes: Regularly collect multi-dimensional operation data and operation performance indicator data of the target business system, construct a new feature vector including business request type distribution, time characteristics, and resource consumption, and use the new feature vector and the operation performance indicator data to construct an incremental training data set; Performing incremental training on the load prediction model and the thread pool parameter decision model using the incremental training data set through a transfer learning mechanism, and fine-tuning the model parameters through a batch gradient descent algorithm; The load prediction model and the thread pool parameter decision model after incremental training are incrementally updated. When a new thread pool parameter adjustment request is received, new first thread pool parameters are generated by the incrementally updated load prediction model and the thread pool parameter decision model.

8. A device for dynamically adjusting thread pool threads, characterized in that: include: A thread pool parameter initialization module is used to initialize and set the thread pool parameters of the target business system through a management center based on target management components in the target business system; A thread pool parameter adjustment request module is used to, when receiving a thread pool parameter adjustment request, generate first thread pool parameters according to the thread pool parameter adjustment request through the management center, synchronously store the first thread pool parameters in a database, and broadcast a configuration change event including the first thread pool parameters; A configuration change event listening module is configured to receive the configuration change event through a configuration change listener registered when the distributed service instance is started, and parse the configuration change event to obtain the first thread pool parameter; A thread pool configuration field module is used to locate the corresponding thread pool configuration field in the thread pool component of the distributed service instance according to the mapping relationship between the program entity factory and the parameter cache registered when the target business system is initialized; A thread pool parameter reflection injection module, configured to inject the first thread pool parameter into the thread pool component instance of the distributed service instance through a field accessor in a preset reflection toolkit, so as to overwrite the old thread pool configuration field in the thread pool component instance; The thread pool parameter resetting module is used to call the setting function of the distributed service instance and reset the corresponding configuration parameters in the thread pool component of the distributed service instance according to the overwritten thread pool configuration field.

9. An electronic device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method for dynamically adjusting thread pool threads according to any one of claims 1 to 7.

10. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are executed by an electronic device, the electronic device executes the method for dynamically adjusting thread pool threads according to any one of claims 1 to 7.

Images