Micro-thread management system and method based on Java

Abstract

The invention discloses a Java-based micro-thread management system and method, the system comprises a micro-thread class, a queue, an actuator, a scheduler and the like, the micro-thread class defines a related interface and a queue storage instance, the running state of the micro-thread class is marked by an atomic variable and has multiple states, and the micro-thread class further comprises a life cycle control module. The management method comprises the steps of micro-thread instance creation and initialization, queue insertion and thread awakening, execution state switching and task execution, dynamic state management and control, priority scheduling strategy execution and the like. Wherein the actuator comprises a thread circulation and exception handling module, the scheduler comprises a dynamic priority chaotic mapping module, and the exception handling module has a classification processing and shadow thread mechanism and the like. According to the method, resource occupation of a single microthread is reduced through cooperation of all the components, the memory utilization rate is improved through the queue structure, and then the priority and the execution strategy can be flexibly set through the scheduler and the executor.

Description

Technical Field

[0001] The present invention relates to the field of computer software applications, and in particular to a Java-based microthread management system and method. Background Art

[0002] With the continuous advancement of computer technology, modern software systems face increasingly complex task processing requirements. In a multi-tasking environment, efficient thread management is a key factor in improving system performance and resource utilization. Existing Java thread management solutions primarily rely on the JDK's native Thread class and Executor framework. Each Thread instance corresponds to an operating system kernel thread, and thread creation, destruction, and scheduling are handled collaboratively by the JVM and the operating system. A typical architecture involves a task submission module submitting Runnable tasks to a thread pool, which then maintains several kernel threads to execute tasks.

[0003] However, this approach consumes a lot of resources, requiring each kernel thread to be allocated an independent stack space. A large number of threads can easily lead to memory overflow, and the scheduling flexibility is low. It relies on the operating system's preemptive scheduling, and cannot customize the micro-thread priority and execution strategy according to business needs. At the same time, it is easy to lose state management and lack of fine-grained control over intermediate states such as micro-thread pause and resume. It is difficult to achieve process management of complex tasks and cannot meet the working requirements of computer software applications. Therefore, a Java-based micro-thread management system and method are proposed. Summary of the Invention

[0004] The present invention provides the following technical solution: a Java-based micro-thread management system, comprising: A microthread class, a microthread queue, a microthread executor, and a microthread scheduler. The microthread class is used to define the instantiation, running, pausing, and destruction interfaces of a microthread. The microthread queue is used to store all microthread instances. The running status of the microthread class uses an AtomicBoolean type variable for thread-safe control and monitoring. A microthread executor is used to start an independent thread and continuously run the microthread task. The microthread scheduler is used to perform scheduling management based on the state of the microthread. A state management module is set inside the microthread class. A state management module is used to mark the running state of the microthread through atomic variables. The running state of the microthread class includes CREATED, RUNNING, PAUSED, and TERMINATED; The lifecycle control module is integrated into the microthread class. The lifecycle control module uses the start(), pause(), resume() and destroy() methods for control. The microthread queue uses a bidirectional linked list as the underlying data structure. The microthread queue implements a thread-safe queue through the synchronized keyword. The add(), getRunnableMicroThread() and putBack() methods are used inside the microthread queue for queue regulation.

[0005] The present invention provides a Java-based micro-thread management method, based on the above Java-based micro-thread management system, comprising the following steps: S1 microthread instance creation and initialization: First, create a microthread instance, initialize the task logic and mark the microthread status as CREATED; S2 queue insertion and thread wakeup: Add the micro-thread instance created in step S1 to the end of the micro-thread queue and wake up the waiting thread through the synchronization mechanism; S3 execution state switching and task execution: The micro-thread executor obtains the micro-thread instance from the queue. If the status is CREATED, it switches to RUNNING and executes the task logic. At the same time, the micro-thread executor monitors the status of the micro-thread queue through the thread loop module, dynamically adjusts the execution priority of the micro-thread, and captures uncaught exceptions in task execution through the exception handling module and records them in the log. S4 dynamic state management and control: During the task execution process, the state is dynamically adjusted by calling the lifecycle control module. That is, the pause() method is called to switch the state to the PAUSED state, and the task progress during the pause is synchronously recorded. At the same time, the resume() method is called to restore the state to the RUNNING state and continue to execute the task. Finally, the destroy() method is called to terminate the task, release resources and clean up the thread context. S5 priority scheduling policy execution: The micro-thread scheduler makes scheduling decisions based on the micro-thread status, that is, it prioritizes micro-threads in the RUNNING state, then suspends micro-threads in the PAUSED state, rejoins them to the ready queue when they resume, and finally removes micro-threads in the TERMINATED state to reclaim memory resources. The micro-thread scheduler uses a dynamic priority chaos mapping module to dynamically adjust the execution priority of micro-threads in real time based on the historical execution status of micro-threads, the current system load, and the chaos mapping algorithm.

[0006] Preferably, the start() method of the lifecycle control module is used to switch the state from CREATED to RUNNING and execute the task, the pause() method of the lifecycle control module is used to pause task execution in the RUNNING state, the resume() method of the lifecycle control module is used to resume task execution in the PAUSED state, and the destroy() method of the lifecycle control module is used to terminate the task and release resources.

[0007] Preferably, the add() method of the microthread queue is used to add a microthread to the tail of the queue and wake up the waiting thread. The getRunnableMicroThread() method of the microthread queue is used to obtain a runnable microthread from the queue. If the queue is empty, it enters a waiting state. The putBack() method of the microthread queue is used to put the microthread back to the tail of the queue and wake up the waiting thread.

[0008] Preferably, the micro-thread executor includes a thread loop module and an exception handling module, the thread loop module is used to monitor the queue status and dynamically adjust the execution priority, and the exception handling module is used to capture uncaught exceptions in task execution and record logs.

[0009] Preferably, an exception recovery shadow thread mechanism is provided inside the exception handling module, and the exception recovery shadow thread mechanism is used to automatically create a shadow thread when an uncaught exception is detected, and restore the micro-thread context to the most recent checkpoint through a transactional state rollback.

[0010] Preferably, a dynamic priority chaotic mapping module is integrated inside the micro-thread scheduler, and the dynamic priority chaotic mapping module is used to dynamically adjust the execution priority of the micro-thread according to the historical execution status of the micro-thread, the current system load and the chaotic mapping algorithm.

[0011] Preferably, the synchronization mechanism in step S2 adopts a dual detection locking mode, which is used to first perform a non-blocking fast detection when the microthread enters the queue, and directly insert it if the queue is not full. If competition is detected, it enters the synchronization code block and performs secondary verification and insertion operations while holding the queue lock.

[0012] Preferably, an exception classification processing mechanism is provided inside the exception handling module in step S3, and the exception classification processing mechanism divides the captured exceptions into fatal exceptions, recoverable exceptions and warning-level exceptions according to the severity. The fatal exception immediately terminates the micro-thread and triggers the resource recovery process when the judgment is successful. The recoverable exception automatically executes the preset retry strategy and records the exception context when the judgment is successful. The warning-level exception is only logged and the micro-thread is maintained to continue running when the judgment is successful.

[0013] Preferably, the task progress record in step S4 adopts incremental snapshot technology, which only saves the task status data that has changed since the last checkpoint each time the pause() method is called, and reduces memory usage through a compression algorithm. When the resume() method is called, the complete execution context is restored in a chain based on the incremental snapshot.

[0014] In summary, compared with the prior art, the present invention provides a Java-based micro-thread management system and method, which has the following beneficial effects: 1. The present invention utilizes the collaborative work of components such as the microthread class and the microthread queue. Since microthreads are relatively lightweight, there is no need to allocate a large amount of independent stack space for each microthread, as is required for traditional kernel threads. This effectively reduces the resource usage of a single microthread, thereby avoiding the memory overflow problem caused by a large number of threads when processing a large number of microthreads. In addition, since the microthread queue uses a doubly linked list as the underlying data structure, it can efficiently store and manage microthread instances. Compared with the memory fragmentation and large amount of redundant memory allocation in traditional thread management methods, the doubly linked list structure can more compactly store microthread-related information, improve memory utilization, and further reduce overall resource usage. 2. The present invention uses a micro-thread scheduler to perform scheduling management based on the status of micro-threads, allowing developers to flexibly set the priority of micro-threads according to specific business needs, thereby improving the system's flexibility in handling different task priorities. In addition, the micro-thread executor starts independent threads and continuously runs micro-thread tasks, allowing the system to customize the execution strategy of micro-threads according to actual business scenarios and task requirements. This allows the system to flexibly adjust the execution order and method of micro-threads based on factors such as the urgency of the task and the availability of data. 3. The present invention uses a state management module set inside the microthread class and uses atomic variables to mark the running state of the microthread. The running state includes CREATED, RUNNING, PAUSED and TERMINATED, so that the state of the microthread is clear and traceable, which is convenient for the system to manage and monitor. At the same time, the life cycle control module integrated in the microthread class adopts start(), pause(), resume() and destroy() methods for control, so that the system can finely control the intermediate states such as pause and resume of the microthread, thereby meeting the needs of complex businesses such as scheduled tasks and process control. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a system block diagram of the present invention.

[0016] Figure 2 It is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0017] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0018] See also Figure 1 The present invention provides a technical solution, a Java-based micro-thread management system, comprising: A microthread class, a microthread queue, a microthread executor, and a microthread scheduler. The microthread class is used to define the instantiation, running, pausing, and destruction interfaces of a microthread. The microthread queue is used to store all microthread instances. The running status of the microthread class uses an AtomicBoolean type variable for thread-safe control and monitoring. A microthread executor is used to start an independent thread and continuously run the microthread task. The microthread scheduler is used to perform scheduling management based on the state of the microthread. A state management module is set inside the microthread class. A state management module is used to mark the running state of the microthread through atomic variables. The running state of the microthread class includes CREATED, RUNNING, PAUSED, and TERMINATED; The life cycle control module is integrated into the microthread class. The life cycle control module uses the start(), pause(), resume() and destroy() methods for control. The microthread queue uses a doubly linked list as the underlying data structure. The microthread queue implements a thread-safe queue through the synchronized keyword. The add(), getRunnableMicroThread() and putBack() methods are used to regulate the queue. The add() method of the microthread queue is used to add a microthread to the end of the queue and wake up the waiting thread. The getRunnableMicroThread() method of the microthread queue is used to obtain a runnable microthread from the queue. If the queue is empty, it enters a waiting state. The putBack() method of the microthread queue is used to put the microthread back to the end of the queue and wake up the waiting thread. The start() method of the lifecycle control module is used to switch the state from CREATED to RUNNING and execute the task, the pause() method of the lifecycle control module is used to pause task execution in the RUNNING state, the resume() method of the lifecycle control module is used to resume task execution in the PAUSED state, and the destroy() method of the lifecycle control module is used to terminate the task and release resources.

[0019] The micro-thread executor includes a thread loop module and an exception handling module. The thread loop module is used to monitor the queue status and dynamically adjust the execution priority. The exception handling module is used to capture uncaught exceptions in task execution and record them in logs. The exception handling module is internally provided with an exception recovery shadow thread mechanism. The exception recovery shadow thread mechanism is used to automatically create a shadow thread when an uncaught exception is detected, and restore the micro-thread context to the most recent checkpoint through transactional state rollback. The specific process of the above method is as follows; Detection of uncaught exceptions: During the execution of tasks by the microthread, the exception handling module continuously monitors the task execution status. Its purpose is to promptly detect uncaught exceptions that occur during task execution. Once an exception is detected during task execution and the exception is not caught by the normal exception handling mechanism, the exception handling module will determine that the exception recovery shadow thread mechanism needs to be activated to handle the exception. Creation of shadow threads: When it is determined that an uncaught exception needs to be handled, the exception recovery shadow thread mechanism begins to prepare to create a shadow thread. This process involves obtaining relevant resources and information, such as determining the system resources required to create a shadow thread, including memory space, etc., and obtaining the relevant identification information of the micro-thread in order to associate it with the original micro-thread. Based on the preparation work, the exception recovery shadow thread mechanism automatically creates a shadow thread. This shadow thread is an independent execution unit, which has a certain functional and structural relationship with the original micro-thread, and is specifically used to handle operations related to exception recovery; Transactional state rollback: After creating a shadow thread, the most recent checkpoint of the microthread must be determined. This checkpoint is a state point previously marked by some mechanism (such as a task progress recorder). At this point, the microthread's state is known and relatively stable, serving as the starting point for recovery. The shadow thread then begins executing a transactional state rollback. Based on specific transaction rules and state management logic, the shadow thread restores the microthread's context to the state at the most recent checkpoint. This may involve restoring various aspects of the microthread, including data structures, variable values, and execution progress. For example, if the microthread was processing a data block at the time of the checkpoint, the rollback operation will restore the processing state of the data block to the state at that time, including the data read location and the data content already processed. After restoring the microthread context to the most recent checkpoint, additional adjustments may be required. For example, checking the state of interactions with other related resources or microthreads to ensure that the task can continue normally in the restored state. If there is interaction with external resources (such as database connections), the connection state must be revalidated or necessary resource permissions must be reacquired to ensure that the microthread can successfully resume its task from the restored state.

[0020] The micro-thread scheduler is internally integrated with a dynamic priority chaotic mapping module, which is used to dynamically adjust the execution priority of the micro-thread according to the historical execution status of the micro-thread, the current system load and the chaotic mapping algorithm.

[0021] See also Figure 2 The Java-based micro-thread management method of the present invention is based on the above Java-based micro-thread management system and includes the following steps: S1 microthread instance creation and initialization: First, create a microthread instance, initialize the task logic and mark the microthread status as CREATED; S2 queue insertion and thread wakeup: Add the microthread instance created in step S1 to the end of the microthread queue, and wake up the waiting thread through a synchronization mechanism. The synchronization mechanism adopts a double-detection locking mode. The double-detection locking mode is used to first perform a non-blocking fast check when the microthread is queued. If the queue is not full, it is directly inserted. If competition is detected, it enters the synchronization code block and performs a secondary check and insertion operation while holding the queue lock. S3 execution state switching and task execution: The micro-thread executor obtains the micro-thread instance from the queue. If the status is CREATED, it switches to RUNNING and executes the task logic. At the same time, the micro-thread executor monitors the status of the micro-thread queue through the thread loop module and dynamically adjusts the execution priority of the micro-thread. The micro-thread executor captures uncaught exceptions in task execution through the exception handling module and records them in the log. The specific process of the above method is as follows; The micro-thread executor monitors the status of the micro-thread queue through the thread loop module and dynamically adjusts the execution priority: when the micro-thread executor starts an independent thread to run the micro-thread task, the thread loop module starts working. It keeps an eye on the status of the micro-thread queue to obtain relevant information about the micro-threads. The thread loop module will first obtain its current status information from the micro-thread queue. This includes the number of micro-threads in the queue, the type of micro-thread (if classified), and the approximate execution status of each micro-thread. Since the micro-thread queue uses a doubly linked list as the underlying data structure and is thread-safe, this information can be accurately obtained. Based on the obtained queue status information, the thread loop module will perform analysis. For example, if it is found that a micro-thread has been waiting in the queue for too long, or certain types of micro-threads have a more critical impact on the completion of the overall task, or the current system load situation has changed, such as when system resources are tight, the priority of some micro-threads needs to be lowered to avoid excessive resource occupation, etc., these will be regarded as factors that require adjustment of the execution priority of the micro-thread. In addition to considering the micro-threads themselves in the queue and the system load, the thread loop module will also combine the historical execution of the micro-threads and the chaos mapping algorithm (the dynamic priority chaos mapping module in the micro-thread scheduler provides relevant information) to dynamically adjust the execution priority of the micro-thread. For example, if a micro-thread has always completed tasks quickly in the past execution and has played an important role in promoting subsequent tasks, then its priority may be increased; on the contrary, if a micro-thread often freezes or takes up too many resources and does not contribute much to the overall task progress, its priority will be lowered; The micro-thread executor captures uncaught exceptions during task execution and records them in logs through the exception handling module: Abnormal detection start: When the micro-thread executor executes the micro-thread task, the abnormal handling module is always on standby, ready to detect whether there are any uncaught abnormalities during the task execution; Exception capture: If an exception occurs during task execution that is not normally captured, the exception handling module will immediately activate the capture mechanism. It can identify the occurrence of the exception, regardless of whether the exception is caused by code logic errors, insufficient resources, or other reasons; Exception classification and processing: The exception classification and processing mechanism within the exception handling module will classify the captured exceptions. According to the severity, they are divided into fatal exceptions, recoverable exceptions, and warning-level exceptions. If it is a fatal exception, when the judgment is successful, the exception handling module will immediately terminate the micro-thread and trigger the resource recovery process to ensure that system resources are not occupied invalidly; if it is a recoverable exception, when the judgment is successful, it will automatically execute the preset retry strategy and record the exception context so that the previous situation can be referenced during the retry process; if it is a warning-level exception, when the judgment is successful, only log recording will be performed and the micro-thread will be maintained to continue running, so that the micro-thread can continue to work without affecting the overall task; Logging: During the exception handling process, regardless of the type of exception, the exception handling module will log the exception in detail. The log records include the time the exception occurred, the type of exception, the possible cause of the exception (if it can be inferred), and some basic information about the micro-thread related to the exception, such as the current state of the micro-thread and the task being executed. This allows you to quickly locate the problem and take appropriate measures by viewing the log when performing subsequent system maintenance, troubleshooting, or performance optimization. The exception handling module is internally provided with an exception classification processing mechanism, which classifies captured exceptions into fatal exceptions, recoverable exceptions, and warning-level exceptions according to their severity. The fatal exception immediately terminates the microthread and triggers the resource recovery process when it is judged to be successful. The recoverable exception automatically executes the preset retry strategy and records the exception context when it is judged to be successful. The warning-level exception is only logged when it is judged to be successful and the microthread continues to run. The specific process of the above method is as follows; Exception capture: During the execution of task logic by the microthread, the exception handling module continuously monitors the task execution status and is ready to capture any uncaught exceptions that may occur. When an exception occurs during task execution, the exception handling module can immediately detect the occurrence of the exception event. Once the exception is captured, the exception handling module will first determine the information related to the exception. This includes the location where the exception occurred (for example, in which specific task step or code segment executed by the microthread), the type of exception (if a preliminary judgment can be made, such as a resource access exception, a logical error, etc.), and the current state of the microthread when the exception occurred (such as whether it is in a critical stage of task execution, etc.); Exception classification: The exception handling module analyzes the captured exceptions according to the pre-set classification criteria. This classification criteria comprehensively considers factors such as the impact of the exception on the execution of the micro-thread task, whether it can be recovered through certain means, and whether it will pose a serious threat to the stability of the entire system. If the exception is determined to seriously affect the normal operation of the micro-thread and cannot be resolved by simple retries or adjustments, such as severe memory shortages and inability to obtain more memory, or permanent destruction of key resources, then the exception will be classified as a fatal exception. When the exception is determined to have affected the normal execution of the micro-thread task but can be recovered through pre-set strategies, such as a temporary network connection interruption but the connection can be retried, or some data is damaged when reading a file but can be reread, this exception will be classified as a recoverable exception. If the exception has little impact on the execution of the micro-thread task and will not cause task interruption or data errors, such as just some non-critical data logging errors or a slightly longer execution time for an unimportant operation, the exception will be classified as a warning-level exception. Handling Different Exception Types: When a fatal exception is detected, the exception handling module takes immediate action. It first terminates the executing microthread, preventing it from continuing operations that could lead to more serious problems. It then triggers a resource recovery process, which reclaims various resources, such as memory and file handles, used by the microthread during execution. This ensures that system resources are not wasted and adjusts the system state to a relatively stable state to avoid chain reactions on other microthreads or the entire system. For recoverable exceptions, the exception handling module automatically executes a pre-set retry strategy. This retry strategy may include re-executing an operation, reacquiring resources, or adjusting execution parameters to attempt to resume the microthread's task. Furthermore, during the retry process, the exception handling module records the exception context. This context contains relevant information about the exception, such as the sequence of operations preceding the exception and the values ​​of related variables. This context can be used for reference during subsequent retries to increase the probability of successful retries. When an exception is classified as a warning-level exception, the exception handling module only logs the exception. It will record the relevant information of the exception, such as the time when the exception occurred, the type of exception, and the basic information of the micro-thread related to the exception. Then, it will maintain the micro-thread's continued operation, allowing the micro-thread's task to continue without major interruption, because this exception has little impact on the overall execution of the task and does not require more complex handling measures; S4 dynamic state management and control: During the task execution process, the state is dynamically adjusted by calling the lifecycle control module, that is, calling the pause() method to switch the state to the PAUSED state, and synchronously record the task progress when it is paused. At the same time, calling the resume() method will restore the state to the RUNNING state and continue to execute the task. Finally, calling the destroy() method will terminate the task, release resources and clean up the thread context. The task progress record adopts the incremental snapshot technology. The incremental snapshot technology only saves the task state data that has changed since the last checkpoint each time the pause() method is called, and reduces memory usage through a compression algorithm. When the resume() method is called, the complete execution context is restored according to the incremental snapshot chain; S5 priority scheduling policy execution: The microthread scheduler makes scheduling decisions based on the microthread status, that is, it prioritizes microthreads in the RUNNING state, then suspends microthreads in the PAUSED state, rejoins them to the ready queue when they resume, and finally removes microthreads in the TERMINATED state to reclaim memory resources. The microthread scheduler uses a dynamic priority chaos mapping module to dynamically adjust the execution priority of microthreads in real time based on the historical execution status of microthreads, the current system load, and the chaos mapping algorithm. The specific process of the above method is as follows; Obtaining Relevant Information: The microthread scheduler first collects historical execution information for each microthread in the system. This includes past execution times for each microthread, such as the time it took to execute each task, whether it completed tasks quickly or frequently took a long time to execute. It also includes the task execution success rate, which is the percentage of tasks that the microthread successfully completed in the past. If a microthread frequently fails, this information can be an important basis for adjusting its priority. Furthermore, the microthread scheduler monitors resource usage during its historical execution, such as memory usage and CPU utilization, to understand its resource consumption patterns. The microthread scheduler also obtains information about the current system load. This includes the current system CPU utilization to determine whether the system's CPU is busy. If CPU utilization is high, the priorities of certain microthreads may need to be adjusted to avoid system overload. Memory usage, such as the amount of used memory and available memory, is also collected, as insufficient memory can affect microthread execution efficiency. Furthermore, the status of other system resources, such as disk I / O and network bandwidth, is also taken into account, as the availability of these resources can also affect microthread execution. Analysis based on the Chaos Mapping Algorithm: The dynamic priority Chaos Mapping module uses the collected microthread execution history and current system load information as input data. For example, the Chaos Mapping algorithm formats the historical execution time, success rate, resource usage, and current system CPU and memory usage data of the microthreads for processing. The Chaos Mapping algorithm then begins to calculate the input data. The algorithm may perform complex analysis and processing on this data based on pre-defined rules and mathematical models. For example, it may correlate the microthread's historical execution time with the current system's CPU usage to determine whether the microthread's execution efficiency is affected under the current system load. Regarding resource usage, the algorithm may comprehensively consider the ratio of the microthread's memory usage to the current system's available memory to determine whether the microthread is placing significant pressure on system resources. The algorithm also considers factors such as the microthread's task execution success rate to comprehensively evaluate the microthread's overall performance. Based on the Chaos Mapping algorithm's calculation results, it determines the direction for adjusting the microthread's execution priority. If a microthread has been highly efficient in its historical execution and has sufficient resources to support it under the current system load, its priority may be increased to allow it to execute tasks more frequently. Conversely, if a microthread has frequently encountered problems in its historical execution or consumes too many resources when resources are tight under the current system load, its priority may be lowered to reduce its use of system resources in order to ensure overall system stability and the normal execution of other microthreads. Execution priority adjustment: Once the priority adjustment direction of the micro-thread is determined, the micro-thread scheduler will update the priority information of the micro-thread. This process may involve modifying the field storing the priority in the micro-thread-related data structure, assigning the new priority value to the micro-thread, ensuring that the system can recognize the change in the micro-thread priority, and the micro-thread scheduler adjusts the scheduling order of the micro-thread according to the updated priority information. For micro-threads with increased priority, their position in the scheduling queue will be advanced so that they can be executed earlier. For micro-threads with reduced priority, their position will be adjusted backward to reduce their chances of being scheduled for execution, thereby achieving the purpose of dynamically adjusting the execution priority of micro-threads in real time based on the historical execution status of micro-threads, the current system load, and the chaos mapping algorithm.

[0022] This solution works through the collaborative work of components such as micro-thread classes and micro-thread queues. Since micro-threads are relatively lightweight, there is no need to allocate a large amount of independent stack space for each micro-thread like traditional kernel threads, which effectively reduces the resource usage of a single micro-thread. Therefore, when processing a large number of micro-threads, the memory overflow problem caused by a large number of threads is avoided. In addition, since the micro-thread queue uses a doubly linked list as the underlying data structure, it can efficiently store and manage micro-thread instances. Compared with the memory fragmentation and large amount of redundant memory allocation under the traditional thread management method, the doubly linked list structure can store micro-thread related information more compactly, improve memory utilization, and further reduce overall resource usage.

[0023] This solution can schedule and manage micro-threads according to their status through the micro-thread scheduler, allowing developers to flexibly set the priority of micro-threads according to specific business needs, improving the system's flexibility in handling different task priorities. In addition, the micro-thread executor starts independent threads and continuously runs micro-thread tasks, allowing the system to customize the execution strategy of micro-threads according to actual business scenarios and task requirements, thereby flexibly adjusting the execution order and method of micro-threads according to factors such as the urgency of the task and the availability of data.

[0024] This solution uses a state management module set up inside the micro-thread class and uses atomic variables to mark the running state of the micro-thread. The running states include CREATED, RUNNING, PAUSED and TERMINATED, making the status of the micro-thread clear and traceable, which is convenient for system management and monitoring. At the same time, the life cycle control module integrated into the micro-thread class uses start(), pause(), resume() and destroy() methods for control, so that the system can fine-tune the intermediate states such as pause and resume of the micro-thread, thereby meeting the needs of complex businesses such as scheduled tasks and process control.

[0025] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus.

[0026] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. Java-based micro-thread management system, characterized by: include: A microthread class, a microthread queue, a microthread executor, and a microthread scheduler. The microthread class is used to define the instantiation, running, pausing, and destruction interfaces of a microthread. The microthread queue is used to store all microthread instances. The running status of the microthread class uses an AtomicBoolean type variable for thread-safe control and monitoring. A microthread executor is used to start an independent thread and continuously run the microthread task. The microthread scheduler is used to perform scheduling management based on the state of the microthread. A state management module is set inside the microthread class. A state management module is used to mark the running state of the microthread through atomic variables. The running state of the microthread class includes CREATED, RUNNING, PAUSED, and TERMINATED; The lifecycle control module is integrated into the microthread class. The lifecycle control module uses the start(), pause(), resume() and destroy() methods for control. The microthread queue uses a bidirectional linked list as the underlying data structure. The microthread queue implements a thread-safe queue through the synchronized keyword. The add(), getRunnableMicroThread() and putBack() methods are used inside the microthread queue for queue regulation.

2. The Java-based micro-thread management system according to claim 1, characterized in that: The start() method of the lifecycle control module is used to switch the state from CREATED to RUNNING and execute the task, the pause() method of the lifecycle control module is used to pause task execution in the RUNNING state, the resume() method of the lifecycle control module is used to resume task execution in the PAUSED state, and the destroy() method of the lifecycle control module is used to terminate the task and release resources.

3. The Java-based micro-thread management system according to claim 1, characterized in that: The add() method of the microthread queue is used to add a microthread to the tail of the queue and wake up the waiting thread. The getRunnableMicroThread() method of the microthread queue is used to get a runnable microthread from the queue. If the queue is empty, it enters a waiting state. The putBack() method of the microthread queue is used to put the microthread back to the tail of the queue and wake up the waiting thread.

4. The Java-based micro-thread management system according to claim 1, characterized in that: The micro-thread executor includes a thread loop module and an exception handling module. The thread loop module is used to monitor the queue status and dynamically adjust the execution priority. The exception handling module is used to capture uncaught exceptions in task execution and record them in logs.

5. The Java-based micro-thread management system according to claim 4, characterized in that: The exception handling module is internally provided with an exception recovery shadow thread mechanism, which is used to automatically create a shadow thread when an uncaught exception is detected, and restore the micro-thread context to the most recent checkpoint through transactional state rollback.

6. The Java-based micro-thread management system according to claim 1, characterized in that: The micro-thread scheduler is internally integrated with a dynamic priority chaotic mapping module, which is used to dynamically adjust the execution priority of the micro-thread according to the historical execution status of the micro-thread, the current system load and the chaotic mapping algorithm.

7. A Java-based micro-thread management method, based on the Java-based micro-thread management system according to any one of claims 1 to 6, characterized in that: The following steps are involved: S1 microthread instance creation and initialization: First, create a microthread instance, initialize the task logic and mark the microthread status as CREATED; S2 queue insertion and thread wakeup: Add the micro-thread instance created in step S1 to the end of the micro-thread queue and wake up the waiting thread through the synchronization mechanism; S3 execution state switching and task execution: The micro-thread executor obtains the micro-thread instance from the queue. If the status is CREATED, it switches to RUNNING and executes the task logic. At the same time, the micro-thread executor monitors the status of the micro-thread queue through the thread loop module, dynamically adjusts the execution priority of the micro-thread, and captures uncaught exceptions in task execution through the exception handling module and records them in the log. S4 dynamic state management and control: During the task execution process, the state is dynamically adjusted by calling the lifecycle control module. That is, the pause() method is called to switch the state to the PAUSED state, and the task progress during the pause is synchronously recorded. At the same time, the resume() method is called to restore the state to the RUNNING state and continue to execute the task. Finally, the destroy() method is called to terminate the task, release resources and clean up the thread context. S5 priority scheduling policy execution: The micro-thread scheduler makes scheduling decisions based on the micro-thread status, that is, it prioritizes micro-threads in the RUNNING state, then suspends micro-threads in the PAUSED state, rejoins them to the ready queue when they resume, and finally removes micro-threads in the TERMINATED state to reclaim memory resources. The micro-thread scheduler uses a dynamic priority chaos mapping module to dynamically adjust the execution priority of micro-threads in real time based on the historical execution status of micro-threads, the current system load, and the chaos mapping algorithm.

8. The Java-based micro-thread management method according to claim 7, characterized in that: The synchronization mechanism in step S2 adopts a dual detection locking mode, which is used to first perform a non-blocking fast detection when the microthread enters the queue. If the queue is not full, it is directly inserted. If competition is detected, it enters the synchronization code block and performs secondary verification and insertion operations while holding the queue lock.

9. The Java-based micro-thread management method according to claim 7, characterized in that: The exception handling module in step S3 is internally provided with an exception classification processing mechanism, which divides the captured exceptions into fatal exceptions, recoverable exceptions and warning-level exceptions according to their severity. The fatal exception immediately terminates the micro-thread and triggers the resource recovery process when it is judged to be successful. The recoverable exception automatically executes the preset retry strategy and records the exception context when it is judged to be successful. The warning-level exception is only logged when it is judged to be successful and the micro-thread is maintained to continue running.

10. The Java-based micro-thread management method according to claim 1, characterized in that: The task progress record in step S4 adopts the incremental snapshot technology. The incremental snapshot technology only saves the task status data that has changed since the last checkpoint each time the pause() method is called, and reduces memory usage through a compression algorithm. When the resume() method is called, the complete execution context is restored according to the incremental snapshot chain.

Images