Java-based microthread management system and method

Abstract

The application discloses a Java-based micro-thread management system and method, which comprises a micro-thread class, a queue, an executor and a scheduler, etc., the micro-thread class defines relevant interfaces, the queue stores instances, the running state of the queue is marked by an atomic variable and has multiple states, and there is a life cycle control module.The management method comprises the following steps: micro-thread instance creation and initialization, queue insertion and thread awakening, execution state switching and task execution, dynamic state management and control, and priority scheduling strategy execution, etc.The executor comprises a thread cycle and an exception processing module, the scheduler comprises a dynamic priority chaos mapping module, the exception processing module has classification processing and a shadow thread mechanism, etc.The application reduces the resource occupation of a single micro-thread through the cooperation of various components, the queue structure improves the memory utilization rate, and the priority and execution strategy can be flexibly set through the scheduler and the executor.

Description

Technical Field

[0001] This invention relates to the field of computer software applications, and in particular to a Java-based micro-thread management system and method. Background Technology

[0002] With the continuous development of computer technology, modern software systems face increasingly complex task processing requirements. In multi-tasking environments, efficient thread management becomes a key factor in improving system performance and resource utilization. Existing Java thread management solutions mainly 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 completed collaboratively by the JVM and the operating system. A typical architecture includes: a task submission module submits Runnable tasks to a thread pool, and the thread pool 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. Furthermore, it has low scheduling flexibility, relies on the operating system's preemptive scheduling, and cannot customize the priority and execution strategy of micro-threads according to business needs. It also easily leads to a lack of state management, lacking fine-grained control over intermediate states such as micro-thread pause and resumption, making it difficult to achieve process management for complex tasks and failing to 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] This invention provides the following technical solution: a Java-based micro-thread management system, comprising:

[0005] The micro-thread class, micro-thread queue, micro-thread executor, and micro-thread scheduler are defined. The micro-thread class is used to define the interfaces for instantiating, running, pausing, and destroying micro-threads. The micro-thread queue is used to store all micro-thread instances. The running status of the micro-thread class is controlled and monitored in a thread-safe manner using a variable of type AtomicBoolean.

[0006] The micro-thread executor is used to start an independent thread and continuously run micro-thread tasks. The micro-thread scheduler is used to schedule and manage micro-threads according to their state. The micro-thread class has a state management module inside.

[0007] The state management module is used to mark the running state of micro-threads through atomic variables. The running states of the micro-thread class include CREATED (created), RUNNING (running), PAUSED (paused), and TERMINATED (terminated).

[0008] The lifecycle control module is integrated within the micro-thread class. The lifecycle control module uses the start(), pause(), resume(), and destroy() methods for control. The micro-thread queue uses a doubly linked list as the underlying data structure. The micro-thread queue is implemented as a thread-safe queue using the synchronized keyword. The micro-thread queue internally uses the add(), getRunnableMicroThread(), and putBack() methods for queue regulation.

[0009] This invention provides a Java-based micro-thread management method, which, based on the aforementioned Java-based micro-thread management system, includes the following steps:

[0010] S1 microthread instance creation and initialization:

[0011] First, create a micro-thread instance, initialize the task logic, and mark the micro-thread state as CREATED (created).

[0012] S2 queue insertion and thread wake-up:

[0013] Add the micro-thread instance created in step S1 to the tail of the micro-thread queue, and wake up the waiting thread through the synchronization mechanism;

[0014] S3 execution state switching and task execution:

[0015] The micro-thread executor retrieves micro-thread instances from the queue. If the state is CREATED, it switches to RUNNING and executes the task logic. At the same time, the micro-thread executor monitors the state of the micro-thread queue through the thread loop module, dynamically adjusts the execution priority of the micro-threads, and catches uncaught exceptions during task execution through the exception handling module and records them in the log.

[0016] S4 Dynamic Status Management and Control:

[0017] During task execution, the state is dynamically adjusted by calling the lifecycle control module. Specifically, the pause() method is called to switch the state to the PAUSED state and record the task progress at the time of pause. At the same time, the resume() method is called to restore the state to the RUNNING state and continue the task execution. Finally, the destroy() method is called to terminate the task, release resources and clean up the thread context.

[0018] S5 priority scheduling policy execution:

[0019] The microthread scheduler makes scheduling decisions based on the microthread's state. It prioritizes scheduling microthreads in the RUNNING state, then suspends microthreads in the PAUSED state and adds them back to the ready queue when they resume. Finally, it removes microthreads in the TERMINATED state and reclaims their memory resources. Furthermore, the microthread scheduler uses a dynamic priority chaos mapping module to dynamically adjust the execution priority of microthreads in real time based on their historical execution, current system load, and chaos mapping algorithm.

[0020] 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 the task execution in the RUNNING state; the resume() method of the lifecycle control module is used to resume the task execution in the PAUSED state; and the destroy() method of the lifecycle control module is used to terminate the task and release resources.

[0021] 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 retrieve a runnable microthread from the queue; if the queue is empty, it enters a waiting state; and 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.

[0022] 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 during task execution and record them in a log.

[0023] Preferably, the exception handling module is internally equipped 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.

[0024] Preferably, the microthread scheduler integrates a dynamic priority chaos mapping module, which is used to dynamically adjust the execution priority of the microthread based on the historical execution status of the microthread, the current system load, and the chaos mapping algorithm.

[0025] Preferably, the synchronization mechanism in step S2 adopts a dual-detection locking mode. The dual-detection locking mode is used to first perform non-blocking fast detection when a micro-thread is enqueued. If the queue is not full, it is inserted directly. If contention is detected, it enters the synchronization code block and performs secondary verification and insertion operations while holding the queue lock.

[0026] Preferably, the exception handling module in step S3 is equipped with an exception classification and processing mechanism. The exception classification and processing mechanism classifies the captured exceptions into fatal exceptions, recoverable exceptions, and warning exceptions according to their severity. When a fatal exception is successfully determined, the micro-thread is immediately terminated and a resource reclamation process is triggered. When a recoverable exception is successfully determined, a preset retry strategy is automatically executed and the exception context is recorded. When a warning exception is successfully determined, only a log is recorded and the micro-thread continues to run.

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

[0028] 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:

[0029] 1. This invention utilizes the collaborative work of components such as micro-thread classes and micro-thread queues. Because micro-threads are relatively lightweight, they do not require the allocation of a large amount of independent stack space for each micro-thread, unlike traditional kernel threads. This effectively reduces the resource consumption of a single micro-thread, thus avoiding memory overflow problems caused by a large number of threads when processing a large number of micro-threads. Furthermore, 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 to the memory fragmentation and large amount of redundant memory allocation in traditional thread management methods, the doubly linked list structure can store micro-thread-related information more compactly, improving memory utilization and further reducing overall resource consumption.

[0030] 2. This invention uses a micro-thread scheduler to manage and schedule micro-threads based on their state, allowing developers to flexibly set micro-thread priorities according to specific business needs. This improves the system's flexibility in handling different task priorities. Furthermore, by starting independent threads and continuously running micro-thread tasks through a micro-thread executor, the system can customize micro-thread execution strategies based on actual business scenarios and task requirements. This allows for flexible adjustment of the execution order and method of micro-threads based on factors such as task urgency and data availability.

[0031] 3. This invention utilizes a state management module within the micro-thread class and atomic variables to mark the running state of the micro-thread. The running states include CREATED (created), RUNNING (running), PAUSED (paused), and TERMINATED (terminated), making the micro-thread's state clearly visible and facilitating system management and monitoring. Furthermore, the lifecycle control module integrated within the micro-thread class uses start(), pause(), resume(), and destroy() methods for control, enabling the system to fine-tune the intermediate states of micro-threads, such as pause and resumption, thereby meeting the needs of complex business processes such as scheduled tasks and flow control. Attached Figure Description

[0032] Figure 1 This is a system block diagram of the present invention.

[0033] Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] Please see Figure 1 This invention provides a technical solution: a Java-based micro-thread management system, comprising:

[0036] The micro-thread class, micro-thread queue, micro-thread executor, and micro-thread scheduler are defined. The micro-thread class is used to define the interfaces for instantiating, running, pausing, and destroying micro-threads. The micro-thread queue is used to store all micro-thread instances. The running status of the micro-thread class is controlled and monitored in a thread-safe manner using a variable of type AtomicBoolean.

[0037] The micro-thread executor is used to start an independent thread and continuously run micro-thread tasks. The micro-thread scheduler is used to schedule and manage micro-threads according to their state. The micro-thread class has a state management module inside.

[0038] The state management module is used to mark the running state of micro-threads through atomic variables. The running states of the micro-thread class include CREATED (created), RUNNING (running), PAUSED (paused), and TERMINATED (terminated).

[0039] The lifecycle control module is integrated within the micro-thread class. This module uses the `start()`, `pause()`, `resume()`, and `destroy()` methods for control. The micro-thread queue uses a doubly linked list as its underlying data structure and is thread-safe through the `synchronized` keyword. Internally, the micro-thread queue uses the `add()`, `getRunnableMicroThread()`, and `putBack()` methods for queue management. The `add()` method adds a micro-thread to the tail of the queue and wakes up waiting threads. The `getRunnableMicroThread()` method retrieves a runnable micro-thread from the queue; if the queue is empty, it enters a waiting state. The `putBack()` method puts the micro-thread back to the tail of the queue and wakes up waiting threads.

[0040] 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 the execution of the task in the RUNNING state. The resume() method of the lifecycle control module is used to resume the execution of the task in the PAUSED state. The destroy() method of the lifecycle control module is used to terminate the task and release resources.

[0041] 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 during task execution and record them in the log.

[0042] The exception handling module has an internal exception recovery shadow thread mechanism. This 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:

[0043] Uncaught Exception Detection: During the execution of tasks by the micro-thread, the exception handling module continuously monitors the task execution status. Its purpose is to promptly detect any uncaught exceptions that occur during task execution. Once an exception is detected during task execution and 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.

[0044] Shadow Thread Creation: When it is determined that uncaught exceptions need to be handled, the exception recovery shadow thread mechanism begins preparations to create a shadow thread. This process involves acquiring relevant resources and information, such as determining the system resources required to create the shadow thread, including memory space, and acquiring the relevant identification information of the micro-thread 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, functionally and structurally related to the original micro-thread, and is specifically used to handle exception recovery-related operations.

[0045] Transactional state rollback operation: After creating the shadow thread, it's necessary to determine the micro-thread's most recent checkpoint. This checkpoint is a state point previously marked by some mechanism (such as a task progress recording mechanism). At this point, the micro-thread's state is known and relatively stable, serving as the starting point for recovery. The shadow thread then begins executing a transactional state rollback operation. Based on specific transaction rules and state management logic, it restores the micro-thread's context to the state of the most recent checkpoint. This may involve recovery operations on various aspects related to the micro-thread, such as data structures, variable values, and execution progress. For example, if the micro-thread was processing a data block at the checkpoint, the rollback operation will restore the data block's processing state to its previous state, including the data read position and the processed data content. After restoring the micro-thread's context to the most recent checkpoint, some additional adjustments may be required. For instance, checking the interaction state with other related resources or micro-threads to ensure normal task execution in the restored state. If there is interaction with external resources (such as database connections), it's necessary to re-verify the connection state or reacquire necessary resource access permissions so that the micro-thread can smoothly continue task execution from the restored state.

[0046] The microthread scheduler integrates a dynamic priority chaos mapping module, which is used to dynamically adjust the execution priority of microthreads based on their historical execution status, current system load, and chaos mapping algorithm.

[0047] Please see Figure 2 The present invention provides a Java-based micro-thread management method, which, based on the aforementioned Java-based micro-thread management system, includes the following steps;

[0048] S1 microthread instance creation and initialization:

[0049] First, create a micro-thread instance, initialize the task logic, and mark the micro-thread state as CREATED (created).

[0050] S2 queue insertion and thread wake-up:

[0051] The micro-thread instance created in step S1 is added to the tail of the micro-thread queue, and the waiting thread is woken up through the synchronization mechanism. The synchronization mechanism adopts a double detection locking mode. The double detection locking mode is used to first perform non-blocking fast detection when the micro-thread is enqueued. If the queue is not full, it is inserted directly. If contention is detected, it enters the synchronization code block and performs secondary verification and insertion operation while holding the queue lock.

[0052] S3 execution state switching and task execution:

[0053] The micro-thread executor retrieves micro-thread instances from the queue. If the state is CREATED, it switches to RUNNING and executes the task logic. At the same time, the micro-thread executor monitors the state of the micro-thread queue through the thread loop module, dynamically adjusts the execution priority of the micro-threads, and catches uncaught exceptions during task execution through the exception handling module and logs them. The specific process of the above method is as follows:

[0054] The microthread executor monitors the microthread queue status and dynamically adjusts execution priorities through the thread loop module: Once the microthread executor starts an independent thread to run a microthread task, the thread loop module begins its work. It continuously monitors the state of the microthread queue to obtain relevant information about the microthreads. The thread loop module first retrieves the current state information from the microthread queue. This includes the number of microthreads in the queue, the type of microthreads (if categorized), and the approximate execution status of each microthread. Because the microthread queue uses a doubly linked list as its underlying data structure and is thread-safe, this information can be accurately obtained. Based on the retrieved queue state information, the thread loop module performs analysis. For example, if a microthread is found to be waiting in the queue for too long, or if certain types of microthreads have a more critical impact on the completion of the overall task, or if the current system load changes (e.g., when system resources are scarce, the priority of some microthreads needs to be lowered to avoid excessive resource consumption), these will all be considered factors that require adjusting the execution priority of microthreads. In addition to considering the microthreads themselves in the queue and the system load, the thread loop module also combines the historical execution data of microthreads with the chaotic mapping algorithm (provided by the dynamic priority chaotic mapping module in the microthread scheduler) to dynamically adjust the execution priority of microthreads. For example, if a microthread has consistently completed tasks quickly and played a significant role in advancing subsequent tasks, its priority may be increased; conversely, if a microthread frequently stalls or consumes excessive resources without contributing much to the overall task progress, its priority will be decreased.

[0055] The micro-thread executor catches uncaught exceptions during task execution and logs them through the exception handling module:

[0056] Anomaly detection initiated: During the execution of micro-thread tasks by the micro-thread executor, the anomaly handling module is always in standby mode, ready to detect whether any uncaught anomalies occur during task execution.

[0057] Exception handling: If an uncaught exception occurs during task execution, the exception handling module will immediately initiate a capture mechanism. It can identify the occurrence of the exception, regardless of whether the exception is caused by a code logic error, insufficient resources, or other reasons;

[0058] Exception Classification and Handling: The exception handling module's internal exception classification mechanism categorizes captured exceptions. They are classified according to severity into fatal exceptions, recoverable exceptions, and warning exceptions. For fatal exceptions, upon successful determination, the exception handling module immediately terminates the micro-thread and triggers a resource reclamation process to ensure system resources are not unnecessarily occupied. For recoverable exceptions, upon successful determination, a preset retry strategy is automatically executed and the exception context is recorded for reference during retry. For warning exceptions, upon successful determination, only logging is performed and the micro-thread continues to run, allowing it to continue working without affecting the overall task.

[0059] Log Recording: During exception handling, regardless of the exception type, the exception handling module will record detailed information about the exception. The logs include the time the exception occurred, the exception type, possible causes (if inferred), and basic information about the related micro-threads, such as their current state and currently executing tasks. This allows for quick problem identification and appropriate action during subsequent system maintenance, troubleshooting, or performance optimization by reviewing the logs.

[0060] The exception handling module has an internal exception classification and processing mechanism. The exception classification and processing mechanism classifies captured exceptions into fatal exceptions, recoverable exceptions, and warning exceptions according to their severity. When a fatal exception is successfully identified, the micro-thread is immediately terminated and a resource reclamation process is triggered. When a recoverable exception is successfully identified, a preset retry strategy is automatically executed and the exception context is recorded. When a warning exception is successfully identified, only logging is performed and the micro-thread continues to run. The specific process of the above method is as follows:

[0061] Exception Handling: During the execution of task logic by the microthread, the exception handling module continuously monitors the task execution status, ready to catch any uncaught exceptions. When an exception occurs during task execution, the exception handling module can immediately detect the occurrence of the exception event. Once the exception is caught, the exception handling module will first determine the information related to the exception. This includes the location of the exception (e.g., in which specific task step or code segment of the microthread is being executed), the type of exception (if it can be preliminarily determined, such as a resource access exception, a logic error, etc.), and the current state of the microthread when the exception occurs (e.g., whether it is in a critical stage of task execution, etc.).

[0062] Exception Classification: The exception handling module analyzes captured exceptions according to pre-defined classification criteria. These criteria comprehensively consider factors such as the impact of the exception on the execution of micro-thread tasks, whether it can be recovered through certain means, and whether it poses a serious threat to the stability of the entire system. If an exception is determined to severely affect the normal operation of the micro-thread and cannot be resolved through simple retries or adjustments (e.g., severe memory shortage with no additional memory available, or permanent damage to critical resources), then the exception will be classified as a fatal exception. When an exception is determined to affect the normal execution of the micro-thread task but can be recovered through pre-defined strategies (e.g., a temporary network connection interruption that can be retried, or partial data corruption during file reading that can be reread), this exception will be classified as a recoverable exception. If the exception has a minor impact on the execution of the micro-thread task and will not cause task interruption or data errors (e.g., errors in logging non-critical data or a slightly longer execution time for an unimportant operation), then the exception will be classified as a warning-level exception.

[0063] Handling Different Types of Exceptions: When an exception is determined to be fatal, the exception handling module will take immediate action. It will first terminate the currently executing micro-thread, preventing it from continuing operations that could lead to more serious problems. Then, it will trigger a resource reclamation process, which reclaims various resources used by the micro-thread during execution, such as memory and file handles, ensuring that system resources are not ineffectively occupied and adjusting the system state to a relatively stable state to avoid a chain reaction on other micro-threads or the entire system. For exceptions determined to be recoverable, the exception handling module will automatically execute a preset retry strategy. This retry strategy may include re-executing an operation, reacquiring resources, or adjusting execution parameters to attempt to allow the micro-thread's task to continue normally. Simultaneously, during the execution of the retry strategy, the exception handling module will record the exception context, which includes various relevant information at the time of the exception, such as the sequence of operations before the exception occurred and the values ​​of relevant variables, for reference in subsequent retries to improve the probability of successful retry. When an exception is determined to be a warning-level exception, the exception handling module will only log it. It records detailed information about the exception, such as the time of occurrence, the type of exception, and basic information about the microthreads associated with the exception. Then, it keeps the microthreads running, allowing their tasks to continue executing without significant interference, because this type of exception has a small impact on the overall execution of the task and does not require more complex handling measures.

[0064] S4 Dynamic Status Management and Control:

[0065] During task execution, the lifecycle control module is called to dynamically adjust the state. Specifically, the pause() method is called to switch the state to the PAUSED state and record the task progress at the time of pause. At the same time, the resume() method is called to restore the state to the RUNNING state and continue the task execution. Finally, the destroy() method is called to terminate the task, release resources and clean up the thread context. The task progress recording adopts incremental snapshot technology. The incremental snapshot technology only saves the task state data that has changed since the last checkpoint when the pause() method is called, and reduces memory usage through compression algorithm. When the resume() method is called, the complete execution context is restored in a chain according to the incremental snapshot.

[0066] S5 priority scheduling policy execution:

[0067] The micro-thread scheduler makes scheduling decisions based on the micro-thread state. It prioritizes scheduling micro-threads in the RUNNING state, then suspends micro-threads in the PAUSED state and adds them back to the ready queue when they resume. Finally, it removes micro-threads in the TERMINATED state and reclaims memory resources. The micro-thread scheduler also uses a dynamic priority chaos mapping module to dynamically adjust the execution priority of micro-threads in real time based on their historical execution, current system load, and chaos mapping algorithm. The specific process of the above method is as follows:

[0068] Obtaining Relevant Information: The microthread scheduler first collects historical execution information for each microthread from the system. This includes the past execution time of each microthread, such as the time spent by a microthread on each previous task execution, whether the task was completed quickly or frequently resulted in long runs. It also includes the task execution success rate, i.e., the proportion of times a microthread has successfully completed a task in the past; if a microthread frequently fails, this will be an important basis for adjusting its priority. In addition, it monitors the resource usage of microthreads in historical execution, such as memory usage and CPU utilization, to understand their resource consumption patterns. The microthread scheduler also obtains current system load information. This includes the current system CPU utilization to understand whether the system CPU is in a busy state; if the CPU utilization is already high, it may be necessary to adjust the priority of some microthreads to avoid system overload. It also obtains memory usage information, such as the amount of memory used and the amount of available memory, because insufficient memory can affect the execution efficiency of microthreads. Furthermore, the status of other resources in the system, such as disk I / O and network bandwidth, is also considered, as the scarcity of these resources also affects the execution of microthreads.

[0069] The analysis is based on the chaotic mapping algorithm: The dynamic priority chaotic mapping module takes the collected historical execution data of micro-threads and the current system load information as input data. For example, the historical execution time, success rate, and resource usage of micro-threads, as well as the current system CPU usage and memory usage, are organized in a certain format for processing by the chaotic mapping algorithm. The chaotic mapping algorithm then begins to calculate the input data. This algorithm may perform complex analysis and processing on this data according to pre-defined rules and mathematical models. For example, it may perform correlation analysis between the historical execution time of micro-threads and the current system CPU usage to determine whether the execution efficiency of the micro-thread is affected under the current system load. Regarding resource usage, the algorithm may comprehensively consider the ratio of the micro-thread's memory usage to the current available system memory to determine whether the micro-thread is putting significant pressure on system resources. Simultaneously, the algorithm also considers factors such as the micro-thread's task execution success rate to comprehensively evaluate the overall performance of the micro-thread and determine the direction for adjusting the micro-thread's execution priority based on the calculation results of the chaotic mapping algorithm. If a microthread has been highly efficient in its past executions and has sufficient resources to support it under the current system load, its priority may be increased so that it can execute tasks more frequently. Conversely, if a microthread has frequently encountered problems in its past executions, or consumes too many resources when resources are scarce under the current system load, its priority may be decreased to reduce its consumption of system resources, thereby ensuring the overall stability of the system and the normal execution of other microthreads.

[0070] Priority Adjustment: Once the direction of micro-thread priority adjustment is determined, the micro-thread scheduler updates the micro-thread priority information. This process may involve modifying the priority fields in the micro-thread's related data structures, assigning the new priority value to the micro-thread, ensuring the system can recognize the change in micro-thread priority. The micro-thread scheduler adjusts the scheduling order of micro-threads based on the updated priority information. For micro-threads with increased priority, their position in the scheduling queue is moved forward, allowing them to be executed earlier. Conversely, for micro-threads with decreased priority, their position is moved backward, reducing their chances of being scheduled for execution. This achieves the goal of dynamically adjusting the execution priority of micro-threads in real time based on their historical execution status, current system load, and the chaotic mapping algorithm.

[0071] This solution utilizes the collaborative work of components such as micro-thread classes and micro-thread queues. Because micro-threads are relatively lightweight, they do not require the allocation of a large amount of independent stack space for each micro-thread, unlike traditional kernel threads. This effectively reduces the resource consumption of a single micro-thread, thus avoiding memory overflow issues caused by a large number of threads when processing a large number of micro-threads. Furthermore, since the micro-thread queue uses a doubly linked list as its underlying data structure, it can efficiently store and manage micro-thread instances. Compared to the memory fragmentation and redundant memory allocation present in traditional thread management methods, the doubly linked list structure can store micro-thread-related information more compactly, improving memory utilization and further reducing overall resource consumption.

[0072] This solution utilizes a micro-thread scheduler to manage and schedule micro-threads based on their state. This allows developers to flexibly set micro-thread priorities according to specific business needs, improving the system's flexibility in handling different task priorities. Furthermore, by starting independent threads and continuously running micro-thread tasks through a micro-thread executor, the system can customize micro-thread execution strategies based on actual business scenarios and task requirements. This allows for flexible adjustments to the execution order and method of micro-threads based on factors such as task urgency and data availability.

[0073] This solution utilizes a state management module within the micro-thread class and atomic variables to mark the running state of the micro-thread. The running state includes CREATED (created), RUNNING (running), PAUSED (paused), and TERMINATED (terminated), making the micro-thread's state clearly traceable and facilitating system management and monitoring. Furthermore, the lifecycle control module integrated within the micro-thread class uses start(), pause(), resume(), and destroy() methods for control, enabling the system to fine-tune the intermediate states of micro-threads, such as pause and resumption, thus meeting the needs of complex business processes such as scheduled tasks and flow control.

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

[0075] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A Java-based microthread management system, characterized by, The application relates to a micro-thread class, a micro-thread queue, a micro-thread executor and a micro-thread scheduler, wherein the micro-thread class is used for defining the instantiation, running, suspension and destruction interfaces of a micro-thread, the micro-thread queue is used for storing all micro-thread instances, the running state of the micro-thread class is thread-safely controlled and monitored by using an AtomicBoolean type variable, the micro-thread executor is used for starting an independent thread and continuously running a micro-thread task, the micro-thread scheduler is used for scheduling management according to the state of the micro-thread, and a state management module is arranged in the micro-thread class. The state management module is used for marking the running state of the micro-thread by using an atomic variable, the running state of the micro-thread class comprises a CREATED created state, a RUNNING running state, a PAUSED suspended state and a TERMINATED terminated state. A life cycle control module is integrated in the micro-thread class, the life cycle control module is controlled by using start(), pause(), resume() and destroy() methods, the micro-thread queue adopts a double-linked list as an underlying data structure, the micro-thread queue is thread-safely realized by using a synchronized keyword, and the micro-thread queue is controlled by using add(), getRunnableMicroThread() and putBack() methods. The start() method of the life cycle control module is used for switching the state from the CREATED state to the RUNNING state and executing a task, the pause() method of the life cycle control module is used for suspending task execution in the RUNNING state, the resume() method of the life cycle control module is used for resuming task execution in the PAUSED state, and the destroy() method of the life cycle control module is used for terminating a task and releasing resources. The add() method of the micro-thread queue is used for adding a micro-thread to the tail of a queue and waking up a waiting thread, the getRunnableMicroThread() method of the micro-thread queue is used for obtaining a runnable micro-thread from the queue, and if the queue is empty, a waiting state is entered, and the putBack() method of the micro-thread queue is used for putting back a micro-thread to the tail of the queue and waking up a waiting thread. The micro-thread executor comprises a thread loop module and an exception processing module, the thread loop module is used for listening to the state of a queue and dynamically adjusting an execution priority, and the exception processing module is used for capturing an uncaught exception in task execution and recording a log.

2. The Java-based micro-thread management system of claim 1, wherein: The exception processing module is internally provided with an exception recovery shadow thread mechanism, the exception recovery shadow thread mechanism is used for automatically creating a shadow thread when an uncaught exception is detected, and a micro-thread context is recovered to a latest check point by using a transaction type state rollback.

3. The Java-based micro-thread management system of claim 1, wherein: ​ 4. The Java-based micro-thread management system of claim 3, wherein: ​ 5. The Java-based micro-thread management system of claim 1, wherein: 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 of the micro-thread, the current system load and the chaotic mapping algorithm.

6. A Java-based microthread management method according to any one of claims 1 to 5, characterized by, The method comprises the following steps: S1 micro-thread instance creation and initialization: First, create a micro-thread instance, initialize the task logic and mark the micro-thread state as CREATED; S2 queue insertion and thread wake-up: Add the micro-thread instance created in step S1 to the tail 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, switches to the RUNNING state if the state is CREATED, executes the task logic, and listens to the state of the micro-thread queue through the thread loop module to dynamically adjust the execution priority of the micro-thread, and captures the uncaught exception in the task execution through the exception handling module and records the log; S4 dynamic state management and control: During task execution, the state is dynamically adjusted by calling the life cycle control module, that is, the state is switched to PAUSED by calling the pause() method, the task progress at the time of pausing is recorded synchronously, the state is restored to RUNNING by calling the resume() method and the task continues to be executed, and finally the destroy() method is called to terminate the task, release resources and clean up the thread context; S5 priority scheduling strategy execution: The micro-thread scheduler makes scheduling decisions according to the state of the micro-thread, that is, the micro-thread in the RUNNING state is scheduled first, the PAUSED micro-thread is suspended and re-joins the ready queue when it is resumed, and the micro-thread in the TERMINATED state is removed and the memory resources are recycled, and the dynamic priority chaotic mapping module is used to dynamically adjust the execution priority of the micro-thread in real time according to the historical execution of the micro-thread, the current system load and the chaotic mapping algorithm.

7. The Java-based micro-thread management method of claim 6, wherein: The synchronization mechanism in step S2 adopts a double detection locking mode, which is used to first perform non-blocking rapid detection when the micro-thread is enqueued, directly inserts if the queue is not full, and enters the synchronization code block if competition is detected, and performs secondary verification and insertion operation under the state of holding the queue lock.

8. The Java-based micro-thread management method of claim 6, wherein: The exception handling module in step S3 is internally provided with an exception classification processing mechanism, which divides the captured exception into fatal exception, recoverable exception and warning level exception according to the severity, the fatal exception terminates the micro-thread and triggers the resource recycling 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, and the warning level exception only records the log and maintains the micro-thread to continue running when the judgment is successful.

9. The Java-based micro-thread management method of claim 6, wherein: The task progress record in the step S4 adopts an incremental snapshot technology, which saves only the changed task state data since the last checkpoint each time the pause() method is called, and reduces the memory occupation through a compression algorithm, and when the resume() method is called, the complete execution context is recovered according to the incremental snapshot chain.

Images