A dynamic thread pool management method and related apparatus

Abstract

Embodiments of the present application disclose a dynamic thread pool management method and related device, which can process multiple to-be-processed transactions through threads in a thread pool, and multiple threads in the thread pool can process multiple transactions simultaneously. Then, a conflict transaction in the multiple to-be-processed transactions can be determined, the conflict transaction being a to-be-processed transaction in which a corresponding transaction object changes corresponding data in a data set during processing, and the data set is used to store data corresponding to the transaction object. According to a number of conflict transactions in the to-be-processed transaction set, a transaction conflict rate corresponding to the to-be-processed transaction set can be determined, and the number of threads in the thread pool is dynamically adjusted based on the transaction conflict rate, so that the problem that the transaction conflict rate is too high due to too many threads in the thread pool or the problem that the transaction processing efficiency is not high due to too few threads can be avoided to a certain extent, the transaction processing efficiency and the transaction conflict rate are balanced, and the processing capacity for transactions is improved comprehensively.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a dynamic thread pool management method and related apparatus. Background Technology

[0002] Blockchain is one of the most popular data processing tools today, offering advantages such as immutability, traceability, and collaborative maintenance. After a transaction is sent to the blockchain, it can be processed by threads within the blockchain's thread pool.

[0003] In related technologies, most blockchain transaction processing execution schemes are serial, meaning there is only one thread for processing transactions, and only one transaction can be processed at a time. This approach limits the multi-core parallel transaction processing capabilities of computers, using a single core and single thread to execute all transactions, resulting in very low execution efficiency. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a dynamic thread pool management method that can effectively control the transaction conflict rate while processing transactions in parallel, thereby greatly improving transaction processing efficiency.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] In a first aspect, embodiments of this application disclose a dynamic thread pool management method, the method comprising:

[0007] Obtain a set of pending transactions, which includes multiple pending transactions and each pending transaction has a corresponding transaction object;

[0008] The multiple pending transactions are processed using threads in a thread pool;

[0009] Identify conflicting transactions among the plurality of pending transactions. A conflicting transaction is a pending transaction in which the data corresponding to the transaction object in the data set changes during the processing. The data set is used to store the data corresponding to the transaction object.

[0010] The transaction conflict rate corresponding to the transaction set to be processed is determined based on the number of conflicting transactions in the transaction set to be processed.

[0011] Adjust the number of threads in the thread pool based on the transaction conflict rate.

[0012] Secondly, embodiments of this application disclose a dynamic thread pool management device, the device comprising an acquisition unit, a processing unit, a first determination unit, a second determination unit, and an adjustment unit:

[0013] The acquisition unit is used to acquire a set of transactions to be processed, which includes multiple transactions to be processed and each transaction to be processed has a corresponding transaction object.

[0014] The processing unit is used to process the multiple pending transactions through threads in the thread pool.

[0015] The first determining unit is used to determine conflicting transactions among the plurality of pending transactions. The conflicting transaction is a pending transaction in which the data corresponding to the transaction object in the data set changes during the processing. The data set is used to store the data corresponding to the transaction object.

[0016] The second determining unit is used to determine the transaction conflict rate corresponding to the transaction set to be processed based on the number of conflicting transactions in the transaction set to be processed;

[0017] The adjustment unit is used to adjust the number of threads in the thread pool according to the transaction conflict rate.

[0018] In one possible implementation, the adjustment unit is specifically used for:

[0019] In response to the transaction conflict rate exceeding a conflict rate threshold, the number of threads in the thread pool is reduced.

[0020] In response to the transaction conflict rate being less than the conflict rate threshold, the number of threads in the thread pool is increased.

[0021] In one possible implementation, the plurality of pending transactions includes a first pending transaction, and the processing unit is specifically used for:

[0022] Determine the target transaction object corresponding to the first transaction to be processed;

[0023] Obtain the first target data corresponding to the target transaction object in the data set;

[0024] The threads in the thread pool process the first pending transaction based on the first target data, and generate the data to be updated corresponding to the first pending transaction.

[0025] The first determining unit is specifically used for:

[0026] Obtain the second target data corresponding to the target transaction object in the data set;

[0027] In response to the difference between the first target data and the second target data, the first transaction to be processed is determined to be a conflicting transaction.

[0028] In one possible implementation, the device further includes an update unit:

[0029] The update unit is configured to update the data corresponding to the target transaction object in the data set to the data to be updated in response to the first target data being the same as the second target data.

[0030] In one possible implementation, the transaction to be processed has a corresponding sending object, which is the object that sends the transaction to be processed. The device further includes a third determining unit and a setting unit.

[0031] The third determining unit is used to determine the number of sending objects corresponding to the plurality of pending transactions;

[0032] The setting unit is used to set the number of sending objects to the initial number of threads corresponding to the thread pool;

[0033] The processing unit is specifically used for:

[0034] The multiple pending transactions are processed by threads of the initial number of threads in the thread pool, and the sending object corresponds one-to-one with the thread in the thread pool.

[0035] In one possible implementation, the plurality of sending objects corresponding to the plurality of pending transactions include a first sending object, and the device further includes a closing unit:

[0036] The shutdown unit is used to shut down the thread corresponding to the first sending object in response to the completion of all pending transactions of the plurality of pending transactions corresponding to the first sending object.

[0037] In one possible implementation, the processing unit is specifically used for:

[0038] For each sending object, a corresponding transaction queue is set up. The transaction queue corresponds one-to-one with the threads in the thread pool. The multiple sending objects corresponding to the multiple pending transactions include a second sending object. The multiple pending transactions include a second pending transaction. The thread pool includes a target thread corresponding to the second sending object. The target thread is used to process the pending transactions sent by the second sending object.

[0039] In response to the fact that the second pending transaction was sent by the second sending object, the second pending transaction is placed in the target transaction queue corresponding to the second sending object;

[0040] In response to the completion of pending transactions in the target thread, pending transactions are retrieved from the target transaction queue for processing.

[0041] In one possible implementation, the set of transactions to be processed includes M transactions to be processed, among which a third transaction is included. The device further includes a fourth determining unit, a fifth determining unit, and an identifier management unit.

[0042] The fourth determining unit is used to determine the identifier record window corresponding to the thread pool, and the identifier record window includes M identifier bits;

[0043] The fifth determining unit is used to determine the transaction identifier corresponding to the third pending transaction, and the transaction identifier is used to identify whether the third pending transaction is a conflicting transaction.

[0044] The identifier management unit is used to remove the transaction identifier located at the Mth position in the identifier record window, increment the number of bits corresponding to the other transaction identifiers by 1, and store the transaction identifier corresponding to the third pending transaction into the first position of the identifier record window. The order of transaction identifiers recorded in the identifier record window is determined based on the order in which the transaction identifiers are stored in the identifier record window.

[0045] The second determining unit is specifically used for:

[0046] In response to the M pending transactions being stored in the identifier record window, the transaction conflict rate corresponding to the pending transaction set is determined based on the ratio of the number of transaction identifiers indicating transaction conflicts in the identifier record window to M.

[0047] Thirdly, embodiments of this application disclose a computer device, the device including a processor and a memory:

[0048] The memory is used to store program code and transmit the program code to the processor;

[0049] The processor is used to execute the dynamic thread pool management method described in any one of the first aspects according to the instructions in the program code.

[0050] Fourthly, embodiments of this application disclose a computer-readable storage medium for storing a computer program for executing the dynamic thread pool management method described in any one of the first aspects.

[0051] Fifthly, embodiments of this application disclose a computer program product including instructions that, when run on a computer, cause the computer to execute the dynamic thread pool management method described in any one of the first aspects.

[0052] As can be seen from the above technical solution, after obtaining the set of transactions to be processed, multiple transactions can be processed by threads in a thread pool. These threads can process multiple transactions simultaneously. To further improve transaction processing efficiency, conflicting transactions can be identified among the multiple transactions to be processed. A conflicting transaction is one where the data corresponding to the transaction object in the data set changes during processing; this data set is used to store the data corresponding to the transaction object. Based on the number of conflicting transactions in the set of transactions to be processed, the transaction conflict rate can be determined. The number of threads in the thread pool can then be dynamically adjusted based on this conflict rate. This helps to avoid the problems of too many threads leading to an excessively high conflict rate or too few threads leading to low transaction processing efficiency, thus balancing transaction processing efficiency and the transaction conflict rate and comprehensively improving the transaction processing capability. Attached Figure Description

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

[0054] Figure 1 A schematic diagram illustrating a dynamic thread pool management method in a practical application scenario, as provided in this application embodiment;

[0055] Figure 2 A flowchart illustrating a dynamic thread pool management method provided in this application embodiment;

[0056] Figure 3 A schematic diagram of an identification record window provided in an embodiment of this application;

[0057] Figure 4 This application provides a schematic diagram illustrating transaction processing using a thread pool as an embodiment of the present application.

[0058] Figure 5 A schematic diagram illustrating dynamic thread pool adjustment based on transaction conflict rate, provided as an embodiment of this application;

[0059] Figure 6 This is a schematic diagram illustrating thread pool management based on a sending object, as provided in an embodiment of this application.

[0060] Figure 7 This is a schematic diagram illustrating thread pool management that combines transaction conflict rate and sending object, as provided in an embodiment of this application.

[0061] Figure 8A structural block diagram of a dynamic thread pool management device provided in an embodiment of this application;

[0062] Figure 9 A structural diagram of a terminal provided in an embodiment of this application;

[0063] Figure 10 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0064] The embodiments of this application will now be described with reference to the accompanying drawings.

[0065] While parallel transaction processing solutions exist in related technologies, where multiple threads in a thread pool can process multiple transactions simultaneously, the number of threads in the thread pool is fixed. When the transaction conflict rate is high, it indicates that many of the concurrently processed transactions modify the same data. This leads to a large number of transactions needing to be resent to the thread for processing due to conflicts. With a fixed number of threads, this results in excessive number of repeated transactions and slow transaction processing efficiency. Conversely, when the transaction conflict rate is low, the inability to add more threads prevents further improvement in transaction processing efficiency.

[0066] To address the aforementioned technical problems, this application provides a dynamic thread pool management method. The processing device can dynamically adjust the number of threads in the thread pool based on the conflict status of the transactions to be processed by the thread pool, thereby achieving a balance between the transaction conflict rate and transaction processing efficiency, and comprehensively improving the transaction processing capability of the thread pool.

[0067] Understandably, this method can be applied to processing devices capable of thread pool management, such as terminal devices or servers with thread pool management functionality. This method can be executed independently by a terminal device or server, or it can be applied in network scenarios where a terminal device and a server communicate, executing in cooperation. The terminal device can be a computer, mobile phone, or similar device. The server can be an application server or a web server; in actual deployment, this server can be a standalone server or a cluster of servers.

[0068] This application can be applied to blockchain technology scenarios. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer.

[0069] The underlying blockchain platform can include modules for user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user identities and blockchain addresses (access management). Under authorization, it also monitors and audits transactions of certain real identities and provides risk control rule configuration (risk control audit). The basic services module is deployed on all blockchain node devices to verify the validity of business requests. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic services first perform interface adaptation parsing and authentication (interface adaptation), and then encrypt the business information using a consensus algorithm (consensus management). After encryption, the data is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored. The smart contract module is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). According to the contract terms, the key or other events are invoked to trigger execution and complete the contract logic. It also provides functions for contract upgrades and cancellations. The operation and monitoring module is mainly responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time status visualization output during product release, such as alarms, network status monitoring, and node device health status monitoring.

[0070] The platform's product service layer provides the basic capabilities and implementation frameworks for typical applications. Developers can leverage these basic capabilities, along with the specific characteristics of their business needs, to implement blockchain-based business logic. The application service layer provides blockchain-based application services to business stakeholders.

[0071] To facilitate understanding of the technical solutions provided in the embodiments of this application, the following will introduce a dynamic thread pool management method provided in the embodiments of this application in conjunction with a practical application scenario.

[0072] See Figure 1 , Figure 1This is a schematic diagram of a dynamic thread pool management method in a practical application scenario provided by an embodiment of this application. In this practical application scenario, the processing device is a server 101 with thread pool management capabilities.

[0073] First, server 101 can obtain a set of pending transactions, which includes N pending transactions. Server 101 can send this set of pending transactions to a thread pool for processing. The thread pool includes three threads, meaning it can process a maximum of three pending transactions simultaneously. Server 101 can determine conflicting transactions among the N pending transactions by observing the processing status of the pending transactions in the thread pool. A conflicting transaction is one where the corresponding data of the transaction object in the data set changes during processing. Therefore, server 101 can determine the transaction conflict rate corresponding to the set of pending transactions based on the number of conflicting transactions among the N pending transactions, and can adjust the number of threads in the thread pool based on this transaction conflict rate.

[0074] For example, when the transaction conflict rate is high, server 101 can appropriately reduce the number of threads in the thread pool, thereby reducing the number of transactions processed simultaneously, which in turn reduces the occurrence of multiple transactions modifying the same data at the same time and lowers the probability of conflicting transactions. When the transaction conflict rate is low, server 101 can appropriately increase the number of threads in the thread pool, thereby increasing the number of transactions that can be processed simultaneously, improving transaction processing efficiency, balancing transaction processing efficiency and transaction conflict rate, and comprehensively improving the thread pool's ability to process transactions.

[0075] Next, with reference to the accompanying drawings, a flowchart of a dynamic thread pool management method provided in an embodiment of this application will be presented. The method includes:

[0076] S201: Get the set of transactions to be processed.

[0077] The set of transactions to be processed includes multiple transactions, each with a corresponding transaction object. This means that when a transaction modifies data in the set, it modifies the data corresponding to that transaction object. A transaction refers to the execution process of a smart contract in a blockchain, equivalent to a method that completes a specific function, such as a transfer or digital notarization. During transaction processing, the processing device can first acquire multiple transactions in batches for processing by a thread pool containing multiple threads.

[0078] S202: Process multiple pending transactions using threads in a thread pool.

[0079] A thread pool is a thread usage pattern. A thread pool typically contains multiple threads, meaning it can handle multiple transactions simultaneously. Too many threads can incur scheduling overhead, impacting cache locality and overall performance. A thread pool maintains multiple threads, waiting for a supervisor to assign concurrently executable tasks, avoiding the cost of creating and destroying threads when handling short-lived tasks. Thread pools not only ensure full utilization of the kernel but also prevent over-scheduling.

[0080] When a thread processes a transaction, it retrieves data from the corresponding data set on the blockchain based on the transaction object to be processed, and obtains the data corresponding to the transaction based on the transaction and the data. Finally, it synchronizes the data to the data set, which is used to store the data corresponding to the transaction object.

[0081] S203: Identify conflicting transactions among multiple pending transactions.

[0082] Understandably, to ensure data validity, the blockchain typically records transaction data only through this single dataset. This means that processing each transaction requires retrieving corresponding data from this dataset, which can lead to transaction conflicts. A conflicting transaction occurs when the data corresponding to the transaction object in the dataset changes during processing. Since processing transactions requires updating the dataset with the data obtained from the transaction processing, changes to the underlying data used to generate the updated data will cause anomalies in the updated dataset.

[0083] For example, both transaction A and transaction B are processing the same data in a dataset. Transaction A is processed first, obtaining data of 100 from the dataset. After processing, it obtains data of 90, which needs to be updated in the dataset. Transaction B is processed next. At the start of processing, since transaction A has not yet updated the dataset with 90, it still obtains data of 100. During processing, transaction B needs to deduct 40, resulting in data of 60. Because transaction A updated the dataset with 90 during processing, if it still updates the dataset with 60, transaction B will actually only deduct 30, resulting in a transaction conflict. Therefore, to ensure the accuracy of transaction processing, when the processing device determines that the corresponding data in the dataset has changed while processing a transaction, it will identify the transaction as a conflicting transaction and return it to the pending transaction set for reprocessing.

[0084] S204: Determine the transaction conflict rate corresponding to the transaction set to be processed based on the number of conflicting transactions in the transaction set to be processed.

[0085] As explained above regarding conflicting transactions, an excessive number of conflicting transactions during processing forces the processing device to perform repeated processing multiple times, thus reducing transaction processing efficiency. Conversely, a low number of conflicting transactions indicates that the thread pool has the capacity to process more transactions simultaneously, meaning the number of threads in the thread pool can be expanded to some extent.

[0086] Based on this, the processing device can first determine the transaction conflict rate corresponding to the transaction set to be processed based on the number of conflicting transactions in the transaction set to be processed. The transaction conflict rate refers to the ratio of the number of conflicting transactions in the transaction set to be processed to the total number of transactions to be processed, which can reflect the transaction conflict situation corresponding to the transaction set to be processed.

[0087] S205: Adjust the number of threads in the thread pool based on the transaction conflict rate.

[0088] To balance transaction conflict rate and transaction processing efficiency, the processing device can adjust the number of threads in the thread pool based on the transaction conflict rate. This allows the number of threads processing transactions simultaneously to be increased as much as possible while controlling an appropriate transaction conflict rate, thereby improving the transaction processing capacity of the thread pool.

[0089] As can be seen from the above technical solution, after obtaining the set of transactions to be processed, multiple transactions can be processed by threads in a thread pool. These threads can process multiple transactions simultaneously. To further improve transaction processing efficiency, conflicting transactions can be identified among the multiple transactions to be processed. A conflicting transaction is one where the data corresponding to the transaction object in the data set changes during processing; this data set is used to store the data corresponding to the transaction object. Based on the number of conflicting transactions in the set of transactions to be processed, the transaction conflict rate can be determined. The number of threads in the thread pool can then be dynamically adjusted based on this conflict rate. This helps to avoid the problems of too many threads leading to an excessively high conflict rate or too few threads leading to low transaction processing efficiency, thus balancing transaction processing efficiency and the transaction conflict rate and comprehensively improving the transaction processing capability.

[0090] For example, in one possible implementation, the processing device can preset a conflict rate threshold. If the transaction conflict rate is greater than the threshold, it indicates that the current transaction conflict rate is high. The processing device can reduce the number of threads in the thread pool to reduce the number of pending transactions processed simultaneously, thereby reducing the transaction conflict rate and avoiding low transaction processing efficiency due to repeated processing of the same pending transaction. If the transaction conflict rate is less than the threshold, it indicates that the probability of a transaction conflict is low. The processing device can appropriately increase the number of threads in the thread pool to increase the number of pending transactions that the thread pool can process simultaneously, thereby further improving transaction processing efficiency.

[0091] Specifically, in one possible implementation, the processing device can determine conflicting transactions in the following way. The plurality of pending transactions may include a first pending transaction, which can be any one of the plurality of pending transactions. Taking the first pending transaction as an example, the processing device can determine the target transaction object corresponding to the first pending transaction, and then obtain the first target data corresponding to the target transaction object in the data set. This first target data is the data that needs to be updated through the first pending transaction.

[0092] The processing device can use threads in the thread pool to process the first pending transaction based on the first target data, generating update data corresponding to the first pending transaction. This update data is the data that needs to be updated in the data set corresponding to the target transaction object. While processing the first pending transaction, the processing device can obtain the second target data corresponding to the target transaction object in the data set. It is understood that if the data corresponding to the target transaction object does not change during transaction processing, the first target data should be the same as the second target data. Based on this, in response to a difference between the first target data and the second target data, the processing device can determine that the first pending transaction is a conflicting transaction.

[0093] Similarly, in one possible implementation, in response to the first target data being the same as the second target data, the processing device can determine that the first transaction to be processed is a non-conflicting transaction. At this time, the processing device can update the data corresponding to the target transaction object in the data set with the data to be updated.

[0094] In order to efficiently and accurately determine the transaction conflict rate corresponding to the set of transactions to be processed, in one possible implementation, the processing device can use a sliding window to record the conflict status of multiple transactions to be processed in the set of transactions to be processed.

[0095] The set of pending transactions may include M pending transactions, among which a third pending transaction may be any one of the M pending transactions. The processing device can determine the identifier record window corresponding to the thread pool. This identifier record window is used to record the conflict status of transactions in the set of pending transactions. The identifier record window includes M identifier bits, each of which can store a transaction identifier. The processing device can determine the transaction identifier corresponding to the third pending transaction. This transaction identifier is used to indicate whether the third pending transaction is a conflicting transaction. For example, when the third pending transaction is a conflicting transaction, the transaction identifier can be "1", and when it is a non-conflicting transaction, the transaction identifier can be "0".

[0096] The processing device can remove the transaction identifier located at the Mth position in the identifier record window, increment the number of bits corresponding to the other transaction identifiers by 1, and store the transaction identifier corresponding to the third pending transaction into the first position of the identifier record window. The order of the transaction identifiers recorded in the identifier record window is determined based on the order in which the transaction identifiers are stored in the identifier record window; that is, the earlier the transaction is stored in the identifier record window, the larger the number of bits corresponding to the transaction identifier. Therefore, after all the transaction identifiers of the M pending transactions are stored in the identifier record window, the first to the Mth positions of the identifier record window represent the transaction identifiers of the M pending transactions.

[0097] In response to the M pending transactions being stored in the identifier record window, the processing device can determine the transaction conflict rate corresponding to the set of pending transactions based on the ratio of the number of transaction identifiers indicating transaction conflicts in the identifier record window to M.

[0098] For example, such as Figure 3 As shown, Figure 3 This is a schematic diagram of an identification record window provided in an embodiment of this application. The system maintains a sliding window bitmap c, which is the identification record window. The number of bits indicates the maximum length supported by the window, and the actual window size supports any length within the maximum length.

[0099] Each time a new conflicting transaction *n* is added, the conflicting transaction is marked as 1, and the normal transaction is marked as 0. If it is a conflicting transaction, the conflict count is incremented by 1; otherwise, it remains unchanged. A bitmap *f* is used to calculate whether a transaction about to leave the window is a conflicting transaction. The highest bit of *f* is 1, which corresponds to the window size. Calculating *c* & *f* directly yields whether the corresponding bit in *c* is 1, indicating a conflicting transaction. If the result is 1, the conflict count is decremented by 1; otherwise, it remains unchanged. This allows for accurate removal of conflict detection results from the previous batch of transactions to be processed recorded in the window. After calculation, the new conflict count and conflict ratio are obtained. The sliding window is then updated by shifting it one position to the left, performing a bitwise OR operation with *n*, and adding the last bit.

[0100] The operation process of the sliding window bitmap c is as follows: Figure 3 As shown, the gray area in the sliding window bitmap c is the effective window area (window size is 20), containing 8 conflicting transactions (i.e., 8 marked as 1), with a conflict rate of 40%. When a new conflicting transaction is added, since the last digit is 1, the conflict count increases by 1, becoming 9. Then, it is determined whether the transaction about to exit the window is a conflicting transaction; c&f = 0, indicating it is not a conflicting transaction, so the conflict count remains unchanged. Finally, the new conflict count is 9, the conflict rate is 45%, and the sliding window bitmap is updated: c_new = c << 1|n. The implementation based on the window bitmap is more efficient, with a time complexity of O(1) for the entire adjustment process.

[0101] See Figure 4 , Figure 4 This is a schematic diagram of transaction processing using a thread pool, which is provided as an embodiment of this application. To use a thread pool in a blockchain, the blockchain must first support the thread pool function, and the blockchain nodes must have a certain degree of concurrency. A blockchain node is the smallest unit that participates in the maintenance of the blockchain and is the unit for the deployment and operation of the blockchain node program.

[0102] First, the processing device can initialize the thread pool. The system first defines a reasonable initial thread pool capacity *c*, i.e., the initial number of threads, based on the processor information. Then, *c* is used as a parameter to initialize the thread pool, where *c* represents the number of threads (workers) working concurrently in the thread pool.

[0103] Subsequently, the processing device can initialize the block transaction pool, which contains all transactions required for this block production. The block transaction pool checks its capacity when the number of transactions changes; if empty, the entire process ends, meaning all transactions have been executed. Otherwise, a new transaction is retrieved for computation. Upon receiving a new transaction, the system first checks if there are available workers (idle threads) in the thread pool. If so, the transaction is retrieved and processed directly. Otherwise, it checks if the number of workers in the thread pool has reached its maximum capacity. If the maximum capacity has been reached, the transaction is returned to the pool without further processing. Otherwise, it indicates that the number of workers in the thread pool can be increased, so a new worker is added and its task is executed, managed by the thread pool. The thread pool obtains the computation results from each worker and compares them with the read / write set (i.e., the data to be updated corresponding to the transaction) to see if there is a conflict between the data in the read / write set and the latest data in the data set. If a conflict exists, the transaction is returned to the block transaction pool and recalculated; otherwise, the block transaction pool is notified to delete the transaction, and the transaction is completed. The transaction execution process for a block ends once all transactions in the block transaction pool have been executed. That is, the processing device can initially adjust its capacity dynamically based on the maximum number of threads the thread pool can hold.

[0104] See Figure 5 , Figure 5 This embodiment of the application provides a schematic diagram of dynamic thread pool adjustment based on transaction conflict rate. First, the block transaction pool and dynamic thread pool are initialized, and an initial capacity for the dynamic thread pool is given. The processing device can set relevant parameters: maximum thread pool capacity (MaxPoolCapacity, the maximum thread capacity the thread pool can achieve); minimum thread pool capacity (MinPoolCapacity, the minimum thread capacity the thread pool can achieve); conflict rate baseline for capacity increase (BaseConflictRate, i.e., the conflict rate threshold; when the conflict rate is less than this value, the thread pool capacity begins to increase); conflict rate baseline for capacity decrease (TopConflictRate, when the conflict rate is greater than this value, the thread pool capacity begins to decrease); upward adjustment coefficient (AscendCoefficient, the coefficient for increasing thread pool capacity); downward adjustment coefficient (DescendCoefficient, the coefficient for decreasing thread pool capacity).

[0105] Then, the processing device can create a sliding window bitmap, which is used throughout the dynamic thread pool tuning process. Figure 1Keep updating continuously. The processing device can continuously retrieve new transactions from the block transaction pool. If the block transaction pool is empty, the execution ends; otherwise, the transactions are executed. After each transaction is executed, the sliding window bitmap is updated to let the sliding window maintain the conflict rate value during this period.

[0106] After the update, the processing device can determine whether all bits in the sliding window have been updated, that is, the number of transactions in a window has been newly added since the last calculation of the latest conflict rate. If all bits have not been updated, then continue to execute the next transaction; otherwise, calculate the latest conflict rate. If the conflict rate < BaseConflictRate, then increase the current thread pool capacity. The increased thread pool capacity (i.e., the number of threads) PoolCapacity = PoolCapacity * AscendCoefficient; otherwise, continue to judge. If the conflict rate > BaseConflictRate, then decrease the current thread pool capacity. The decreased thread pool capacity PoolCapacity = PoolCapacity * DescendCoefficient; otherwise, do not change the thread pool capacity.

[0107] It can be understood that the thread pool usually has adjustable upper and lower limits of the number of threads, that is, the thread pool has a maximum number of threads that can be accommodated and a minimum number of threads that can be accommodated. Therefore, before changing the thread pool capacity, the processing device can correct the upper and lower bounds to limit the new PoolCapacity between MinPoolCapacity and MaxPoolCapacity. Finally, update the thread pool capacity size, and the thread pool will allocate resources according to the latest capacity.

[0108] In addition to dynamic adjustment based on the transaction conflict rate, the processing device can also analyze from the dimension of the sender object of the sent transaction to determine the number of threads suitable for transaction processing. It can be understood that, usually, when processing a transaction, there is a high probability that it is necessary to modify the data corresponding to the sender object of the sent transaction in the data set, such as deducting the fee of the sender object of the sent transaction for the sent transaction, etc.

[0109] Based on this, in one possible implementation, the pending transaction has a corresponding sending object, which is the object that sends the pending transaction. The processing device can also determine the number of sending objects corresponding to multiple pending transactions, and then set the number of sending objects to the initial number of threads corresponding to the thread pool. The processing device can process multiple pending transactions using the initial number of threads in the thread pool. The sending object corresponds one-to-one with the threads in the thread pool, that is, each thread is dedicated to processing the pending transaction sent by its corresponding sending object. This can, to some extent, avoid the problem of multiple threads in the thread pool simultaneously processing pending transactions sent by the same sending object, which would cause transaction conflicts because all threads need to process the data of the sending object in the dataset.

[0110] Furthermore, in one possible implementation, once all pending transactions for a given sending object have been sent, the processing device can shut down the thread used to process that sending object to conserve processing resources. For example, among the multiple sending objects corresponding to multiple pending transactions, a first sending object may be included. This first sending object can be any one of the multiple sending objects. In response to the completion of all pending transactions corresponding to the first sending object, the processing device can shut down the thread corresponding to the first sending object. Thus, on the one hand, the processing device can dynamically adjust the number of threads based on the transaction conflict rate; on the other hand, it can determine the number of threads from the source based on the sending object, further improving the effectiveness of thread pool management.

[0111] Specifically, in one possible implementation, for the multiple pending transactions using threads of an initial number in a thread pool, the processing device can set up a corresponding transaction queue for each sending object. This transaction queue corresponds one-to-one with a thread in the thread pool, and is used to extract pending transactions from the set of pending transactions and send them to the thread for processing. The multiple sending objects corresponding to the multiple pending transactions include a second sending object, which can be any one of the multiple sending objects. Taking the second sending object as an example, the multiple pending transactions may include a second pending transaction, which can be any one of the multiple pending transactions. The thread pool includes a target thread corresponding to the second sending object, and the target thread is used to process the pending transactions sent by the second sending object.

[0112] In response to the fact that the second pending transaction was sent by the second sending object, the processing device can place the second pending transaction into the target transaction queue corresponding to the second sending object. When processing pending transactions, the target thread will only retrieve pending transactions from the target transaction queue for processing. That is, in response to the completion of the pending transactions in the target thread, it will retrieve pending transactions from the target transaction queue for processing. This can, to a certain extent, avoid the situation where multiple threads process pending transactions sent by the same sending object, reduce the transaction conflict rate, and improve transaction processing efficiency.

[0113] For example, such as Figure 6 As shown, Figure 6 This illustration shows a thread pool management method based on sending objects, as provided in this application embodiment. In cases where the balance (gas) of a transaction sending object needs to be deducted, transactions sent by the same sending object will inevitably conflict. First, the processing device initializes the block transaction pool and groups the block transaction pool according to transaction conflicts. For example, if the pending transactions in the entire block transaction pool correspond to 10 transaction sending objects, and each sending object needs to deduct gas, the processing device can divide all transactions into 10 groups and place them into 10 transaction queues.

[0114] The processing device can initialize a thread pool based on the number of groups. For example, following the above scheme, it can divide the pool into 10 threads, with each group retrieving one transaction and executing them concurrently. After each transaction is completed, it checks if there are any remaining transactions in that group. If so, it retrieves a new transaction from that group for execution; otherwise, it decrements the thread pool capacity by 1, effectively removing the thread corresponding to the sending object of that group. The processing device can also determine if the block transaction pool is empty. If it is not empty, it continues executing transactions; otherwise, it indicates that all transactions have been executed, and the process terminates.

[0115] See Figure 7 , Figure 7 This illustration provides a schematic diagram of thread pool management combining transaction conflict rate and sending object in an embodiment of this application. Since the transaction object corresponding to a transaction is usually only known during transaction processing (e.g., the recipient of a money transfer transaction is only known after the transaction is executed), thread pool management based solely on the sending object still carries the possibility of conflict. Assuming multiple pending transactions correspond to multiple sending objects, and these transaction objects are identical, a high transaction conflict rate may result. Therefore, if... Figure 7 As shown, in Figure 6 Based on the thread pool management method shown, the current thread pool capacity will be dynamically adjusted according to the transaction conflict rate after the transaction is executed. The upper limit of the thread pool capacity is the number of remaining groups, that is, the number of sending objects corresponding to the remaining unprocessed pending transactions.

[0116] Based on the dynamic thread pool management method provided in the above embodiments, this application also provides a dynamic thread pool management device, see [link to relevant documentation]. Figure 8 , Figure 8 This application provides a structural block diagram of a dynamic thread pool management device 800, which includes an acquisition unit 801, a processing unit 802, a first determination unit 803, a second determination unit 804, and an adjustment unit 805.

[0117] The acquisition unit 801 is used to acquire a set of transactions to be processed, the set of transactions to be processed includes multiple transactions to be processed, and each transaction to be processed has a corresponding transaction object;

[0118] The processing unit 802 is used to process the plurality of pending transactions through threads in the thread pool;

[0119] The first determining unit 803 is used to determine conflicting transactions among the plurality of pending transactions. The conflicting transaction is a pending transaction in which the data corresponding to the transaction object in the data set changes during the processing. The data set is used to store the data corresponding to the transaction object.

[0120] The second determining unit 804 is used to determine the transaction conflict rate corresponding to the transaction set to be processed based on the number of conflicting transactions in the transaction set to be processed;

[0121] The adjustment unit 805 is used to adjust the number of threads in the thread pool according to the transaction conflict rate.

[0122] In one possible implementation, the adjustment unit 805 is specifically used for:

[0123] In response to the transaction conflict rate exceeding a conflict rate threshold, the number of threads in the thread pool is reduced.

[0124] In response to the transaction conflict rate being less than the conflict rate threshold, the number of threads in the thread pool is increased.

[0125] In one possible implementation, the plurality of pending transactions includes a first pending transaction, and the processing unit 802 is specifically used for:

[0126] Determine the target transaction object corresponding to the first transaction to be processed;

[0127] Obtain the first target data corresponding to the target transaction object in the data set;

[0128] The threads in the thread pool process the first pending transaction based on the first target data, and generate the data to be updated corresponding to the first pending transaction.

[0129] The first determining unit 803 is specifically used for:

[0130] Obtain the second target data corresponding to the target transaction object in the data set;

[0131] In response to the difference between the first target data and the second target data, the first transaction to be processed is determined to be a conflicting transaction.

[0132] In one possible implementation, the device further includes an update unit:

[0133] The update unit is configured to update the data corresponding to the target transaction object in the data set to the data to be updated in response to the first target data being the same as the second target data.

[0134] In one possible implementation, the transaction to be processed has a corresponding sending object, which is the object that sends the transaction to be processed. The device further includes a third determining unit and a setting unit.

[0135] The third determining unit is used to determine the number of sending objects corresponding to the plurality of pending transactions;

[0136] The setting unit is used to set the number of sending objects to the initial number of threads corresponding to the thread pool;

[0137] The processing unit 802 is specifically used for:

[0138] The multiple pending transactions are processed by threads of the initial number of threads in the thread pool, and the sending object corresponds one-to-one with the thread in the thread pool.

[0139] In one possible implementation, the plurality of sending objects corresponding to the plurality of pending transactions include a first sending object, and the device further includes a closing unit:

[0140] The shutdown unit is used to shut down the thread corresponding to the first sending object in response to the completion of all pending transactions of the plurality of pending transactions corresponding to the first sending object.

[0141] In one possible implementation, the processing unit 802 is specifically used for:

[0142] For each sending object, a corresponding transaction queue is set up. The transaction queue corresponds one-to-one with the threads in the thread pool. The multiple sending objects corresponding to the multiple pending transactions include a second sending object. The multiple pending transactions include a second pending transaction. The thread pool includes a target thread corresponding to the second sending object. The target thread is used to process the pending transactions sent by the second sending object.

[0143] In response to the fact that the second pending transaction was sent by the second sending object, the second pending transaction is placed in the target transaction queue corresponding to the second sending object;

[0144] In response to the completion of pending transactions in the target thread, pending transactions are retrieved from the target transaction queue for processing.

[0145] In one possible implementation, the set of transactions to be processed includes M transactions to be processed, among which a third transaction is included. The device further includes a fourth determining unit, a fifth determining unit, and an identifier management unit.

[0146] The fourth determining unit is used to determine the identifier record window corresponding to the thread pool, and the identifier record window includes M identifier bits;

[0147] The fifth determining unit is used to determine the transaction identifier corresponding to the third pending transaction, and the transaction identifier is used to identify whether the third pending transaction is a conflicting transaction.

[0148] The identifier management unit is used to remove the transaction identifier located at the Mth position in the identifier record window, increment the number of bits corresponding to the other transaction identifiers by 1, and store the transaction identifier corresponding to the third pending transaction into the first position of the identifier record window. The order of transaction identifiers recorded in the identifier record window is determined based on the order in which the transaction identifiers are stored in the identifier record window.

[0149] The second determining unit 804 is specifically used for:

[0150] In response to the M pending transactions being stored in the identifier record window, the transaction conflict rate corresponding to the pending transaction set is determined based on the ratio of the number of transaction identifiers indicating transaction conflicts in the identifier record window to M.

[0151] This application also provides a computer device, which will be described below with reference to the accompanying drawings. Please refer to... Figure 9As shown in the figure, this application provides a device, which can also be a terminal device. The terminal device can be any smart terminal, including mobile phones, tablets, personal digital assistants (PDAs), point-of-sale (POS) terminals, in-vehicle computers, etc. Taking a mobile phone as an example:

[0152] Figure 9 This diagram illustrates a partial structural representation of a mobile phone related to the terminal device provided in this embodiment. (Reference) Figure 9 The mobile phone includes components such as a radio frequency (RF) circuit 710, a memory 720, an input unit 730, a display unit 740, a sensor 750, an audio circuit 760, a wireless Fidelity (WiFi) module 770, a processor 780, and a power supply 790. Those skilled in the art will understand that... Figure 9 The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0153] The following is combined with Figure 9 A detailed introduction to each component of a mobile phone:

[0154] RF circuit 710 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink information from the base station and processes it with processor 780; additionally, it transmits uplink data to the base station. Typically, RF circuit 710 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier (LNA), and a duplexer. Furthermore, RF circuit 710 can also communicate wirelessly with networks and other devices. The aforementioned wireless communication can use any communication standard or protocol, including but not limited to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, and Short Messaging Service (SMS).

[0155] The memory 720 can be used to store software programs and modules. The processor 780 executes various mobile phone functions and data processing by running the software programs and modules stored in the memory 720. The memory 720 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 720 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

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

[0157] The display unit 740 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 740 may include a display panel 741, which may optionally be configured as a Liquid Crystal Display (LCD), Organic Light-Emitting Diode (OLED), or similar display panel. Further, a touch panel 731 may cover the display panel 741. When the touch panel 731 detects a touch operation on or near it, it transmits the information to the processor 780 to determine the type of touch event. Subsequently, the processor 780 provides corresponding visual output on the display panel 741 based on the type of touch event. Although in Figure 9 In this embodiment, the touch panel 731 and the display panel 741 are two separate components to realize the input and output functions of the mobile phone. However, in some embodiments, the touch panel 731 and the display panel 741 can be integrated to realize the input and output functions of the mobile phone.

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

[0159] Audio circuit 760, speaker 761, and microphone 762 provide an audio interface between the user and the mobile phone. Audio circuit 760 converts received audio data into electrical signals and transmits them to speaker 761, where speaker 761 converts them into sound signals for output. On the other hand, microphone 762 converts collected sound signals into electrical signals, which are received by audio circuit 760, converted into audio data, and then processed by processor 780 before being transmitted via RF circuit 710 to, for example, another mobile phone, or the audio data can be output to memory 720 for further processing.

[0160] WiFi is a short-range wireless transmission technology. Through the WiFi module 770, mobile phones can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access. Although Figure 9The WiFi module 770 is shown, but it is understood that it is not an essential component of a mobile phone and can be omitted as needed without changing the essence of the invention.

[0161] The processor 780 is the control center of the mobile phone, connecting various parts of the phone through various interfaces and lines. It executes software programs and / or modules stored in the memory 720, and calls data stored in the memory 720 to perform various functions and process data, thereby performing overall detection of the phone. Optionally, the processor 780 may include one or more processing units; preferably, the processor 780 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 780.

[0162] The mobile phone also includes a power supply 790 (such as a battery) that supplies power to various components. Preferably, the power supply can be logically connected to the processor 780 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system.

[0163] Although not shown, mobile phones may also include a camera, Bluetooth module, etc., which will not be described in detail here.

[0164] In this embodiment, the processor 780 included in the terminal device also has the following functions:

[0165] Obtain a set of pending transactions, which includes multiple pending transactions and each pending transaction has a corresponding transaction object;

[0166] The multiple pending transactions are processed using threads in a thread pool;

[0167] Identify conflicting transactions among the plurality of pending transactions. A conflicting transaction is a pending transaction in which the data corresponding to the transaction object in the data set changes during the processing. The data set is used to store the data corresponding to the transaction object.

[0168] The transaction conflict rate corresponding to the transaction set to be processed is determined based on the number of conflicting transactions in the transaction set to be processed.

[0169] Adjust the number of threads in the thread pool based on the transaction conflict rate.

[0170] This application also provides a server; please refer to [link / reference]. Figure 10 As shown, Figure 10This is a structural diagram of a server 800 provided in an embodiment of this application. The server 800 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 822 (e.g., one or more processors) and a memory 832, and one or more storage media 830 (e.g., one or more mass storage devices) for storing application programs 842 or data 844. The memory 832 and storage media 830 can be temporary or persistent storage. The program stored in the storage media 830 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 822 may be configured to communicate with the storage media 830 and execute the series of instruction operations in the storage media 830 on the server 800.

[0171] Server 800 may also include one or more power supplies 826, one or more wired or wireless network interfaces 850, one or more input / output interfaces 858, and / or one or more operating systems 841, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0172] The steps performed by the server in the above embodiments can be based on Figure 10 The server structure shown.

[0173] This application also provides a computer-readable storage medium for storing a computer program that executes any one of the implementation methods of the dynamic thread pool management method described in the foregoing embodiments.

[0174] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the dynamic thread pool management method provided in various optional implementations of the above embodiments.

[0175] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium can be at least one of the following media: read-only memory (ROM), RAM, magnetic disk, or optical disk, etc., and other media capable of storing program code.

[0176] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system 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 can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0177] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A dynamic thread pool management method, characterized in that, The method includes: Obtain a set of pending transactions, which includes multiple pending transactions and each pending transaction has a corresponding transaction object; The multiple pending transactions are processed using threads in a thread pool; Identify conflicting transactions among the plurality of pending transactions. A conflicting transaction is a pending transaction in which the data corresponding to the transaction object in the data set changes during the processing. The data set is used to store the data corresponding to the transaction object. The transaction conflict rate corresponding to the transaction set to be processed is determined based on the number of conflicting transactions in the transaction set to be processed. Adjust the number of threads in the thread pool based on the transaction conflict rate; The set of transactions to be processed includes M transactions to be processed, and the M transactions to be processed include a third transaction to be processed. The method further includes: Determine the identifier record window corresponding to the thread pool, wherein the identifier record window includes M identifier bits; Determine the transaction identifier corresponding to the third pending transaction, the transaction identifier being used to identify whether the third pending transaction is a conflicting transaction; Remove the transaction identifier located at the Mth position in the identifier record window, increment the number of bits corresponding to the other transaction identifiers by 1, and store the transaction identifier corresponding to the third transaction to be processed into the first position of the identifier record window. The order of transaction identifiers recorded in the identifier record window is determined based on the order in which the transaction identifiers are stored in the identifier record window.

2. The method according to claim 1, characterized in that, Adjusting the number of threads in the thread pool based on the transaction conflict rate includes: In response to the transaction conflict rate exceeding a conflict rate threshold, the number of threads in the thread pool is reduced. In response to the transaction conflict rate being less than the conflict rate threshold, the number of threads in the thread pool is increased.

3. The method according to claim 1, characterized in that, The plurality of pending transactions includes a first pending transaction, and the process of processing the plurality of pending transactions using threads in a thread pool includes: Determine the target transaction object corresponding to the first transaction to be processed; Obtain the first target data corresponding to the target transaction object in the data set; The threads in the thread pool process the first pending transaction based on the first target data, and generate the data to be updated corresponding to the first pending transaction. The process of determining conflicting transactions among the plurality of pending transactions includes: Obtain the second target data corresponding to the target transaction object in the data set; In response to the difference between the first target data and the second target data, the first transaction to be processed is determined to be a conflicting transaction.

4. The method according to claim 3, characterized in that, The method further includes: In response to the first target data being the same as the second target data, the data corresponding to the target transaction object in the data set is updated to the data to be updated.

5. The method according to claim 1, characterized in that, The pending transaction has a corresponding sending object, which is the object that sends the pending transaction. The method further includes: Determine the number of sending objects corresponding to the plurality of pending transactions; Set the number of objects to be sent to the initial number of threads corresponding to the thread pool; The process of handling the multiple pending transactions using threads from a thread pool includes: The multiple pending transactions are processed by threads of the initial number of threads in the thread pool, and the sending object corresponds one-to-one with the thread in the thread pool.

6. The method according to claim 5, characterized in that, The method further includes: (The first sending object is included among the multiple sending objects corresponding to the multiple pending transactions.) In response to the completion of all pending transactions corresponding to the first sending object among the plurality of pending transactions, the thread corresponding to the first sending object is closed.

7. The method according to claim 5, characterized in that, The process of handling the multiple pending transactions using threads of the initial number of threads in the thread pool includes: For each sending object, a corresponding transaction queue is set up. The transaction queue corresponds one-to-one with the threads in the thread pool. The multiple sending objects corresponding to the multiple pending transactions include a second sending object. The multiple pending transactions include a second pending transaction. The thread pool includes a target thread corresponding to the second sending object. The target thread is used to process the pending transactions sent by the second sending object. In response to the fact that the second pending transaction was sent by the second sending object, the second pending transaction is placed in the target transaction queue corresponding to the second sending object; In response to the completion of pending transactions in the target thread, pending transactions are retrieved from the target transaction queue for processing.

8. The method according to claim 1, characterized in that, The step of determining the transaction conflict rate corresponding to the transaction set to be processed based on the number of conflicting transactions in the transaction set to be processed includes: In response to the M pending transactions being stored in the identifier record window, the transaction conflict rate corresponding to the pending transaction set is determined based on the ratio of the number of transaction identifiers indicating transaction conflicts in the identifier record window to M.

9. A dynamic thread pool management device, characterized in that, The device includes an acquisition unit, a processing unit, a first determination unit, a second determination unit, and an adjustment unit. The acquisition unit is used to acquire a set of transactions to be processed, which includes multiple transactions to be processed and each transaction to be processed has a corresponding transaction object. The processing unit is used to process the multiple pending transactions through threads in the thread pool. The first determining unit is used to determine conflicting transactions among the plurality of pending transactions. The conflicting transaction is a pending transaction in which the data corresponding to the transaction object in the data set changes during the processing. The data set is used to store the data corresponding to the transaction object. The second determining unit is used to determine the transaction conflict rate corresponding to the transaction set to be processed based on the number of conflicting transactions in the transaction set to be processed; The adjustment unit is used to adjust the number of threads in the thread pool according to the transaction conflict rate. The set of transactions to be processed includes M transactions to be processed, and the M transactions to be processed include a third transaction to be processed. The device also includes a fourth determining unit, a fifth determining unit, and an identifier management unit. The fourth determining unit is used to determine the identifier record window corresponding to the thread pool, and the identifier record window includes M identifier bits; The fifth determining unit is used to determine the transaction identifier corresponding to the third pending transaction, and the transaction identifier is used to identify whether the third pending transaction is a conflicting transaction. The identifier management unit is used to remove the transaction identifier located at the Mth position in the identifier record window, increment the number of bits corresponding to the other transaction identifiers by 1, and store the transaction identifier corresponding to the third pending transaction into the first position of the identifier record window. The order of transaction identifiers recorded in the identifier record window is determined based on the order in which the transaction identifiers are stored in the identifier record window.

10. The apparatus according to claim 9, characterized in that, The adjustment unit is specifically used for: In response to the transaction conflict rate exceeding a conflict rate threshold, the number of threads in the thread pool is reduced. In response to the transaction conflict rate being less than the conflict rate threshold, the number of threads in the thread pool is increased.

11. The apparatus according to claim 9, characterized in that, The plurality of pending transactions includes a first pending transaction, and the processing unit is specifically used for: Determine the target transaction object corresponding to the first transaction to be processed; Obtain the first target data corresponding to the target transaction object in the data set; The threads in the thread pool process the first pending transaction based on the first target data, and generate the data to be updated corresponding to the first pending transaction. The first determining unit is specifically used for: Obtain the second target data corresponding to the target transaction object in the data set; In response to the difference between the first target data and the second target data, the first transaction to be processed is determined to be a conflicting transaction.

12. The apparatus according to claim 11, characterized in that, The device also includes an update unit: The update unit is configured to update the data corresponding to the target transaction object in the data set to the data to be updated in response to the first target data being the same as the second target data.

13. A computer device, characterized in that, The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the dynamic thread pool management method according to any one of claims 1-8 according to the instructions in the program code.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for executing the dynamic thread pool management method according to any one of claims 1-8.

15. A computer program product including instructions that, when run on a computer, cause the computer to perform the dynamic thread pool management method according to any one of claims 1-8.

Images