A method, device and terminal for managing memory pool

Abstract

The present invention discloses a method, device and terminal for managing a memory pool. The present invention sets a return queue and an idle queue corresponding to a thread, manages memory blocks released by different threads through the return queue, thereby managing shared memory blocks between different threads, and manages all memory blocks of the thread through the return queue and the idle queue, thereby realizing that the thread and the memory resource are not completely locked, thereby effectively solving the problem that the existing thread needs to lock the memory resource, thereby affecting the concurrent performance of multiple threads.

Description

Technical Field

[0001] The present invention relates to the field of communications, and in particular to a method, device and terminal for managing a memory pool. Background Art

[0002] In the field of mobile communications, the network architecture of 5G will be a cloud-based software structure, requiring that the software organization is no longer a single software. The software must be divided into various services according to different dimensions, and the services can be further divided into various microservices, which is the so-called microservice architecture. The rise of container technology has further promoted the development of microservice architecture.

[0003] The Internet of Everything in the 5G era requires containers to have high concurrent processing capabilities. The deployment of containers is very flexible. Multiple containers may be deployed on a node. Containers use memory resources efficiently and adapt to high-concurrency scenarios, which is conducive to improving the overall performance of the system.

[0004] There are already many frameworks for managing memory in the industry, and some development languages ​​themselves support memory pool technology, but most of them were born in the Internet field and have good versatility. However, when applied to multi-threaded and high-concurrency scenarios, there will be competition for lock resources, which will affect the concurrent processing performance of memory. Summary of the invention

[0005] The present invention provides a method, device and terminal for managing a memory pool, which are used to solve the problem in the prior art that multi-thread concurrent performance is affected due to threads locking memory resources.

[0006] To solve the above technical problems, in a first aspect, the present invention provides a method for managing a memory pool, the method comprising: presetting a memory pool corresponding to each thread and a return queue and a free queue corresponding to each thread, the memory pool comprising a plurality of memory blocks; for any thread, the return queue is used to store the index of the memory block released after being provided by the thread to other threads for use, and the free queue is used to store the index of the free memory block of the thread; based on the return queue and the free queue, the memory pool of each thread is managed.

[0007] Preferably, each of the memory pools is provided with a memory identifier, and the memory identifier is used to identify the memory pool corresponding to the memory block in the memory pool.

[0008] Preferably, the memory block application of each thread is managed based on the return queue and the idle queue, including: when any thread applies for a memory block, the memory block in the return queue corresponding to the thread is iteratively recovered to the idle queue corresponding to the thread, and a memory block is allocated to the thread from the idle queue.

[0009] Preferably, the index of the memory block of the return queue is stored according to different preset fixed length classifications of the memory blocks under different different threads; the different threads include other threads different from the current thread.

[0010] Preferably, when any thread applies for a memory block, the memory block in the return queue corresponding to the thread is iteratively recovered to the idle queue corresponding to the thread, and a memory block is allocated to the thread from the idle queue, including:

[0011] Assume that any thread that applies for a memory block is a memory application thread, and iteratively recover various memory blocks of different preset fixed length categories released by the first different thread in the return queue corresponding to the memory application thread from the first memory block to the second to last memory block to the idle queue corresponding to the memory application thread; when the memory block released by the first different thread is iteratively recovered, if the idle queue corresponding to the memory application thread does not contain the memory block applied by the memory application thread after the memory block released by the first different thread is iteratively recovered, then apply for a memory block from a preset memory slice in the memory pool, if the applied memory block is not found in the preset memory slice, then iteratively recover various memory blocks of different preset fixed length categories released by the second different thread in the return queue to the idle queue, and determine whether there is the applied memory block in the idle queue corresponding to the memory application thread, if not, then continue to iteratively recover the memory blocks released by other different threads, if the applied memory block is not found after traversing all return queues, then apply for a new preset memory slice from the system, and allocate memory blocks to the thread from the preset memory slice; wherein the preset memory slice contains a set number of memory blocks.

[0012] Preferably, the managing the memory pool of each thread based on the return queue and the idle queue further includes:

[0013] Before iteratively recovering the memory blocks in the return queue corresponding to the thread to the idle queue corresponding to the thread, determine whether the size of the memory block applied for by the memory application thread exceeds a preset maximum memory block threshold; if so, apply for a memory block from the preset memory slice, and the size of the applied memory block is equal to the size of the memory block applied for by the memory application thread.

[0014] Preferably, the indexes of the memory blocks in the idle queue are stored according to different preset fixed length classifications of the memory blocks.

[0015] Preferably, allocating a memory block to the thread from the idle queue includes: according to the size of the memory block applied for by the thread, selecting a memory block closest to the size of the applied memory block from the idle queue corresponding to the thread and allocating it to the thread.

[0016] Preferably, the management of the memory pool of each thread based on the return queue and the idle queue also includes: before iteratively recovering the memory blocks in the return queue corresponding to the thread to the idle queue corresponding to the thread, judging whether the memory block applied for by the thread is a long-life memory block; if so, further judging whether the preset memory slice is a long-life memory based on the life cycle identifier of the preset memory slice to which the applied memory block belongs; if the preset memory slice is a long-life memory, increasing the number of long-life memories of the preset memory slice by one; otherwise, modifying the life cycle identifier of the preset memory slice, and increasing the number of long-life memories of the preset memory slice by one; wherein, the long-life memory block is a memory block for entity modeling, and the preset memory slice contains a set number of memory blocks.

[0017] Preferably, based on the return queue and the idle queue, the memory pool of each thread is managed, including: when a memory block is released, determining whether the released memory block is released by the same thread; if it is released by the same thread, directly checking whether the released memory block meets the preset reuse conditions; if it is released by a different thread, storing the memory block in the return queue of the thread to which the memory block belongs, and when applying to reuse the memory block, checking whether the memory block meets the preset reuse conditions.

[0018] Preferably, the preset reuse conditions include: when the released memory block is a long-life memory block, the number of long-life memory blocks in the preset memory slice to which the released memory block belongs is reduced by one; when the number of long-life memory blocks is greater than 0, all memory blocks in the preset memory slice to which the memory block belongs can be reused; when the number of long-life memory blocks is 0, after all memory blocks on the preset memory slice are released, the preset memory slice is returned to the system.

[0019] Preferably, based on the return queue and the idle queue, the memory block released by the thread is managed, and it also includes: judging whether the released memory block is previously released by the same thread, judging whether the size of the released memory block exceeds a preset maximum memory block threshold, and if so, directly returning the released memory block to the system.

[0020] In a second aspect, the present invention provides a device for managing a memory pool, the device comprising: a setting unit, used to preset a memory pool corresponding to each thread and a return queue and a free queue corresponding to each thread, the memory pool containing a plurality of memory blocks; for any thread, the return queue is used to store the index of the memory block released after being provided by the thread to other threads for use, and the free queue is used to store the index of the free memory block of the thread; a processing unit, used to manage the memory pool of each thread based on the return queue and the free queue.

[0021] In a third aspect, the present invention further provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the method for managing a memory pool as described in any one of the above are implemented.

[0022] In a fourth aspect, the present invention provides a terminal, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of any of the methods for managing a memory pool as described above.

[0023] The present invention can at least bring the following beneficial effects:

[0024] The present invention sets a return queue and an idle queue corresponding to a thread, manages a memory block (User Block, UB) released by a different thread through the return queue, thereby managing shared memory blocks between different threads, and manages all memory blocks of the thread through the return queue and the idle queue, thereby realizing that the thread and the memory resource are not completely locked, thereby effectively solving the problem that the existing thread needs to lock the memory resource, thereby affecting the multi-threaded concurrent performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 is a flow chart of a method for managing a memory pool in a first embodiment of the present invention;

[0026] Figure 2 It is a schematic diagram of a process of reclaiming a memory block released by a different thread in the first embodiment of the present invention;

[0027] Figure 3 is a schematic diagram of the structure of a preset memory chip in the first embodiment of the present invention;

[0028] Figure 4 is a schematic diagram of the structure of a memory block in the first embodiment of the present invention;

[0029] Figure 5 It is a schematic diagram of the structure of the device for managing the memory pool in the second embodiment of the present invention. DETAILED DESCRIPTION

[0030] In order to solve the problem in the prior art that threads need to lock memory resources and affect the concurrent performance of multi-threads, the present invention provides a method for managing a memory pool, by setting a return queue and an idle queue corresponding to the thread, and managing the memory blocks released by different threads through the return queue, so as to achieve the management of shared memory blocks between different threads, and manage all memory blocks of the thread through the return queue and the idle queue, so as to achieve that the thread and the memory resources are not completely locked, thereby effectively solving the problem that the existing threads need to lock memory resources and affect the concurrent performance of multi-threads. The present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and do not limit the present invention.

[0031] First embodiment

[0032] The embodiment of the present invention provides a method for managing a memory pool. The process of the method is as follows: Figure 1 As shown, steps S101 to S102 are included:

[0033] S101, presetting a memory pool corresponding to each thread and a return queue and an idle queue corresponding to each thread, wherein the memory pool includes a plurality of memory blocks;

[0034] The embodiment of the present invention is for any thread, the return queue is used to store the index of the memory block released after the thread provides it to other threads for use, and the idle queue is used to store the index of the idle memory block of the thread;

[0035] like Figure 2 As shown, the idle queue of the embodiment of the present invention includes all free memory blocks in the first thread (i.e., thread 1, corresponding to the first memory pool object pool 1), and the return queue includes all memory blocks released by different threads in the second thread (i.e., thread 2, corresponding to the first memory pool object pool 2) and the third thread (i.e., thread 3, corresponding to the first memory pool object pool 3), and according to Figure 2 It can be seen that the memory blocks in the free queue and the return queue are stored according to a series of preset fixed lengths of different sizes, for example, a column of memory blocks with a length of 128 bytes, a column of memory blocks with a length of 256 bytes, and so on.

[0036] In specific implementation, the memory pools described in the embodiments of the present invention are all provided with memory identifiers, and the memory identifiers are used to identify the memory pools corresponding to the memory blocks in the memory pools. That is, the embodiments of the present invention establish the association relationship between the memory blocks in the memory pool corresponding to the threads and the return queues and free queues of the threads through the memory identifiers, that is, the embodiments of the present invention associate the memory blocks with the threads through the memory identifiers, and manage the memory blocks through the free queues and return queues.

[0037] S102: managing the memory pool of each thread based on the return queue and the idle queue.

[0038] Specifically, the embodiment of the present invention mainly manages the application of memory blocks and the release of memory blocks by each thread based on the return queue and the idle queue.

[0039] During specific implementation, the embodiment of the present invention sets an independent memory pool object for each thread, and manages the application and release of memory blocks through the memory pool object. Specifically, the memory pool object of the embodiment of the present invention manages the application and release of memory blocks through the idle queue and return queue under the thread.

[0040] In addition, in the specific implementation, the embodiment of the present invention further sets a corresponding storage object, through which all memory pool objects are managed, and a memory identification ID is allocated to the memory pool object, that is, a memory identification on the memory pool. In the specific implementation, the embodiment of the present invention allocates the memory identification to the memory pool object through the storage object, and establishes the association relationship between the memory pool object, memory pool, memory block, return queue, and free queue under the same thread through the memory identification, that is, the association relationship between the memory pool object, memory pool, memory block, return queue, and free queue under the same thread is identified through the memory identification allocated by the storage object. Of course, those skilled in the art may also allocate memory identification in other ways during the specific implementation, and the embodiment of the present invention does not specifically limit this.

[0041] It should be noted that the memory pool described in the embodiment of the present invention is the memory allocated to the thread from the terminal system, that is, the embodiment of the present invention will also allocate the corresponding memory to the thread, but the memory of the present invention can be shared with different threads, and will not completely lock the thread and memory like the prior art. The system described in the embodiment of the present invention is an operating system on a terminal such as a server.

[0042] In specific implementation, the embodiment of the present invention allocates one or more preset memory slices (also referred to as large memory slices LargeMem) to each thread, and the preset memory slices further include a series of multiple memory blocks of various sizes for use by different application situations of the threads. For the division of specific memory blocks, those skilled in the art can divide them in advance according to the actual thread situation.

[0043] It should be noted that, in order to avoid occupying too many memory resources, in specific implementation, the embodiment of the present invention allocates a preset memory slice to each thread, and the preset memory slice is a memory of a predetermined size, such as 1M memory, or 4M memory, etc.

[0044] It can be understood that the memory pool of the embodiment of the present invention includes one or more preset memory slices, and the memory blocks applied for and released by the threads are all performed in the preset memory slices, and the application and release of memory blocks, as well as the idle queue and return queue are uniformly managed through the memory pool object.

[0045] In general, the core idea of ​​the embodiments of the present invention is to set a return queue and an idle queue corresponding to the thread, manage the memory blocks of the current thread and the memory blocks released by other threads through the return queue and the idle queue, and finally realize the sharing of memory blocks between different threads, thereby improving the multi-thread concurrent processing performance.

[0046] Compared with the prior art in which threads need to lock memory resources, the memory resources and threads in the embodiments of the present invention are not locked, so the method described in the embodiments of the present invention can handle the problem of multi-thread concurrency well, thereby achieving better memory usage effect.

[0047] That is to say, the embodiment of the present invention supports sharing UB between threads. The UB applied for by a thread memory pool object can be sent to another thread for processing. After the other thread releases the UB, the UB released by the different thread will be put into the return queue. When the thread applies for a memory block, the memory block will be iteratively recovered from the return queue to the free queue, and the memory block will be allocated through the free queue.

[0048] In an embodiment of the present invention, based on the return queue and the idle queue, the memory block application of each thread is managed, including: when any thread applies for a memory block, the memory block in the return queue corresponding to the thread is iteratively recovered to the idle queue corresponding to the thread, and the memory block is allocated to the thread from the idle queue.

[0049] That is to say, the embodiment of the present invention adopts a two-stage method for recycling and reusing UBs released by different threads, that is, in the first stage, when a different thread releases UB, it first puts the UB into the return queue of the current thread. In the second stage, when the memory pool to which the UB belongs applies for UB, it triggers the iterative concatenation of UBs from the return queue back to the idle queue, thereby completing the process of recycling and reusing UBs. No locks are required in the entire process of recycling and allocating UBs, making the algorithm complexity of concatenating UBs O(1).

[0050] It should be noted that the index of the memory block of the return queue in the embodiment of the present invention is stored according to different preset fixed length classifications of the memory blocks under different threads; the different threads are threads other than the current thread. The index of the memory block in the idle queue is stored according to different preset fixed length classifications of the memory blocks.

[0051] That is to say, in order to facilitate the management of memory blocks, the memory blocks of the idle queue and the return queue in the embodiment of the present invention are arranged in columns according to different lengths, and the length of the memory blocks in each column is the same. The difference is that the return queue needs to perform the first step of grouping according to each different thread, and then further store the memory blocks according to different preset fixed length series under each different thread. During specific implementation, the length of the memory blocks in each column and the specific number of columns can be set according to actual needs, and the present invention does not make specific restrictions on this. For example, the first column is set to 100 128-byte memory blocks, the second column is set to 100 256-byte memory blocks, and so on. More columns of memory blocks can also be set.

[0052] In the embodiment of the present invention, when any thread applies for a memory block, the memory block in the return queue corresponding to the thread is iteratively recovered to the idle queue corresponding to the thread, and a memory block is allocated to the thread from the idle queue, including:

[0053] Assuming any thread that applies for a memory block as a memory application thread, iteratively recover memory blocks of different preset fixed-length categories released by the first different thread in a return queue corresponding to the memory application thread from the first memory block to the second to last memory block to an idle queue corresponding to the memory application thread;

[0054] When, after iteratively recovering the memory block released by the first different thread, the idle queue corresponding to the memory application thread does not contain the memory block applied for by the memory application thread, apply for the memory block from the preset memory slice in the memory pool; if the applied memory block is not found in the preset memory slice, iteratively recover the memory blocks of different preset fixed-length categories released by the second different thread in the return queue to the idle queue, and determine whether the applied memory block is in the idle queue corresponding to the memory application thread; if not, continue to iteratively recover the memory blocks released by other different threads; if the applied memory block is not found after traversing all return queues, apply for a new preset memory slice from the system, and allocate memory blocks to the thread from the preset memory slice;

[0055] The preset memory slice includes a set number of memory blocks.

[0056] Specifically, when the embodiment of the present invention recycles the UB released by the reused different thread, it first iteratively recycles the return queue corresponding to the first different thread according to the preset different thread order. If the idle queue is still empty after the recycling, memory is applied from the large memory. If there is no space in the large memory, it attempts to recycle the memory from all return queues to the idle queue. If the idle queue is still empty, a new large memory is applied.

[0057] In specific implementation, in the embodiment of the present invention, the memory blocks in each column are arranged in the order of their release time. When iteratively recovering the memory blocks, the memory blocks released first are recovered first according to the arrangement order of the memory blocks, and the memory blocks released last in each column are retained so that other released memory blocks can be saved in the corresponding queue later.

[0058] For ease of understanding, the following will combine Figure 2The process of releasing UB by a different thread in the embodiment of the present invention is described in detail: when the first thread applies for a memory block, the memory block in the return queue of the different thread is triggered to be recycled to the free queue (free Que), in the recycling process, firstly, each series of memory blocks of preset fixed length released by the first different thread is recycled, specifically, the first memory block to the second to last memory block of each series of memory blocks of preset fixed length are put into the memory block queue of corresponding length in the free queue; if after recycling, the free queue has not found the memory block to be applied for, then apply for the memory block from the preset memory slice; if the applied memory block is not found in the preset memory slice (it may be that the preset memory slice does not have enough space to allocate), it triggers the recycling of each series of memory blocks of preset fixed length released by the second different thread, specifically, the first memory block to the second to last memory block of each series of memory blocks of preset fixed length are recycled into the free queue; and so on, according to the iteration of each thread, the memory blocks released by the different threads are recycled into the return queue; if the applied memory block is not found after traversing all the return queues, a new preset memory slice is applied from the system, and the memory block is allocated to the thread from the preset memory slice.

[0059] In addition, it should be noted that, for the convenience of management, the embodiments of the present invention put the recovered memory blocks into a corresponding queue of a preset fixed length in the idle queue according to the size of the recovered memory blocks.

[0060] In specific implementation, if the thread has not created its corresponding return queue in advance, the processing method of the embodiment of the present invention includes: releasing UB in a thread different from the thread that applies for UB, searching for the return queue in the memory pool of the current thread according to the ID of the memory pool to which the UB belongs, and if it does not exist, creating a return queue array at one time, associating the return queue array with the thread ID to which the UB belongs in the memory pool of the current thread, and placing the return queue array pointer in the release queue of the different thread to which the UB belongs (the queue for storing the return queue). Put the released UB into the return queue of the corresponding size; the second stage is when applying for UB, querying the different thread release queue once, recovering the UB of the corresponding size from a different thread return queue, and putting it into the idle queue. Here, scanning all the different thread return queues is avoided, but the UB is recovered from the different thread return queue one by one in a discrete manner as the process of applying for UB. When recovering the UB of a certain return queue, there is always one UB left in the return queue that is not recovered, so there is no need for locking control, and the recovery process is to connect the first UB of the return queue to the second to last UB in series at one time and put it into the idle queue, so the algorithm complexity of the present invention is O(1).

[0061] That is to say, the application, recycling and reuse of UB in the embodiment of the present invention are all performed in the memory pool object of the current thread. UB can be shared among different threads, and the release of UB by different threads adopts a two-stage recycling and reuse algorithm of UB, so that the application and release process of UB is lock-free, thereby improving the efficiency of memory use and further improving the user experience. Moreover, the memory pool in the embodiment of the present invention has the characteristics of high efficiency and high concurrency, supports event communication between entities in entity modeling, and can deliver complex object pointers, thereby avoiding the need for serialization and deserialization of internal entity communication and reducing a large number of memory copy operations.

[0062] In a specific implementation, in an embodiment of the present invention, before iteratively recovering the memory block in the return queue index corresponding to the thread to the idle queue corresponding to the thread, it also includes: determining whether the size of the memory block applied for by the thread exceeds a preset maximum memory block threshold; if so, applying for a memory block from the system, and the size of the memory block applied for is equal to the size of the memory block applied for by the thread.

[0063] That is, when receiving a memory block requested by a thread, it is first necessary to determine whether the size of the requested memory block exceeds the preset maximum memory block threshold (that is, the maximum value in the above series of preset fixed-length memory blocks). If so, the memory block is directly requested from the system.

[0064] It can be understood that when the memory block to be applied for exceeds the maximum value of a series of preset fixed lengths of the preset memory blocks, the corresponding memory block is directly applied for in the preset memory slice.

[0065] It should be noted that when the preset memory slice is insufficient for allocation, a new preset memory slice is requested from the system. The preset memory slice may be a memory of a uniformly specified size or the size of the requested memory block.

[0066] That is to say, when the preset memory slice is not enough for allocation, a preset memory slice can be re-applied from the system, and memory blocks can be allocated from the preset memory slice. The newly applied preset memory slice can be the size of the memory block applied for above that exceeds the preset maximum memory block threshold. When the memory block is released, the preset memory slice is directly returned to the system. Of course, a preset memory slice of a predetermined size can also be applied for according to the preset, and memory blocks can be allocated from the preset memory slice, and the rest of the preset memory slice can also be allocated to other applications of the thread for use.

[0067] That is, in specific implementation, the embodiment of the present invention can preset the sizes of all preset memory slices to be uniform, or can also specifically set the sizes of the preset memory slices according to actual conditions. Those skilled in the art can set it according to actual needs, and the present invention does not make specific limitations on this.

[0068] Since the memory blocks in the embodiment of the present invention are a series of memory blocks with preset fixed lengths, in the embodiment of the present invention, specifically according to the size of the memory block UB applied for by the thread, a memory block closest to the size of the applied memory block is selected from the idle queue corresponding to the thread and allocated to the thread.

[0069] Specifically, the UBs in the return queue and the idle queue in the embodiment of the present invention are all a series of fixed-length UBs. If the UBs requested by the service are different from the sizes of these fixed-length UBs, they are normalized to these fixed-size UBs (the closest UB is taken). These UBs are all requested from large-scale memory, which is a large block of memory requested from the operating system, generally exceeding 1M.

[0070] For example, if you apply for a 200-byte UB, and the closest size supported by the memory pool is 256 bytes, then the UB is recovered from the return queue corresponding to 256 bytes, and the UB is reused from the corresponding idle queue.

[0071] In the embodiment of the present invention, the management of memory blocks applied for by each thread based on the return queue and the idle queue further includes:

[0072] Before iteratively recycling the memory blocks in the return queue corresponding to the thread to the idle queue corresponding to the thread, determining whether the memory block applied for by the thread is a long-life memory block, and if so, further determining whether the preset memory slice to which the applied memory block belongs is a long-life memory according to the life cycle identifier of the preset memory slice;

[0073] If the preset memory slice is a long life cycle memory, the number of long life cycle memories of the preset memory slice is increased by one;

[0074] Otherwise, modify the life cycle identifier of the preset memory slice, and increase the number of long life cycle memories of the preset memory slice by one;

[0075] Among them, the long-life memory block is a memory block for entity modeling. Relatively speaking, the short-life UB in the embodiment of the present invention is a UB for event communication. In addition, the preset memory slice in the embodiment of the present invention is a memory of a preset size obtained from the memory pool, and the preset memory slice contains a set number of memory blocks.

[0076] Specifically, in order to avoid the problem that some microservices in the microservice architecture occupy too much memory due to conflicts and do not return it to the system, which puts pressure on the operating memory of the entire system, in an embodiment of the present invention, a life cycle identifier is set for the preset memory slice, and the life cycle of the preset memory slice is identified by the identifier. The preset memory slice with a long life cycle will continue to be reused, and the preset memory slice with a short life cycle will be returned to the system after all memory blocks are released, thereby effectively ensuring the efficient operation of the entire system.

[0077] That is, the method described in the embodiment of the present invention supports UBs with long and short life cycles, so that entity modeling and event communication can use the same memory pool mechanism, which is convenient for unified management of memory. When a large piece of memory (i.e., the preset memory slice mentioned above) is consumed, a new large piece of memory is opened up. If the old large piece of memory has a UB with a long life cycle, all UBs on it can be reused to avoid invalid occupation of too much memory due to UB fragmentation; otherwise, it cannot be reused. After the UB is released, the old large piece of memory is returned to the system, thereby avoiding excessive memory occupation due to business bursts and not being returned to the system.

[0078] Figure 3 Schematic diagram of the structure of a large memory according to an embodiment of the present invention. Figure 3 As shown, the flag in the large memory structure is a flag for reclaiming the large memory. The flag includes two types, wherein MEM_INVALID indicates that after the to-be-owned UB is released, the large memory is released and its UB is no longer reused; MEM_FIX indicates that there is a UB with a long life cycle, and all the to-be-owned UBs can be reused, memubNum indicates the number of UBs belonging to the large memory, longLifeubNum indicates the number of UBs with a long life cycle belonging to the large memory, and ub_pool indicates that the space behind the large memory header (LargeMemHeader) is the space for the UB to be allocated.

[0079] It should be noted that when applying for memory, if there is no free UB in the idle queue of the corresponding size and there is not enough space in the large memory, a new large memory will be requested from the system. The old large memory sets the flag in the large memory header according to whether it has a long life cycle UB:

[0080] If there is no long-life UB, it is set to MEM_INVALID, and the UB belonging to the old large memory will not be reused. After the application releases them, the old large memory is returned to the system. It can also be directly set to return the large memory to the system. Of course, a certain return mechanism can also be set to return the large memory to the system.

[0081] If there is a long-life UB, MEM_FIX is set, and the UB belonging to the old large memory will continue to be reused. After all long-life UBs are released, their flag is set to MEM_INVALID, and the UB of the old large memory will not be reused. After these UBs are released, the old large memory will be returned to the system.

[0082] The release of large memory is to obtain the UB in the free queue when applying for UB. First, check the flag of the large memory header to which the UB belongs. If it is MEM_INVALID, the UB will not be reused, the memUBNum of the large memory header will be reduced by one, and continue to look for the next free UB. When the memUBNum of the large memory header is 0, the large memory will be returned to the system; if the flag of the large memory is not MEM_INVALID, the UB belonging to it can be reused.

[0083] That is to say, the UB in the embodiment of the present invention can distinguish between long and short life cycles. For example, an entity and the data structure it maintains may have a long life cycle, while event communication between entities may have a short life cycle.

[0084] After the thread calls the application interface to apply for UB, it calls the long life cycle setting interface to set the long life cycle according to the thread's semantics. The longLifeUbNum of the LargeMem header to which the UB belongs is increased by 1. If the flag is MEM_INVALID, it is set to MEM_FIX.

[0085] When UB is released, the UB is checked immediately when it is released by the same thread, and when it is released by a different thread, it is checked when the memory pool to which it belongs reuses the UB. If the UB has a long life cycle, the longLifeUbNum of the LargeMem header to which it belongs is reduced by one. When longLifeUbNum is not 0, the UB is returned for reuse. When it is 0, if the flag of LargeMem is MEM_FIX, it is modified to MEM_INVALID, and the UB is not reused. Then the memUbNum of the LargeMem header is reduced by one and reduced to 0 (which means that all UBs are released), and the LargeMem is returned to the system. If the flag of LargeMem is not MEM_INVALID, the UB to which it belongs can be reused.

[0086] Figure 4 is a schematic diagram of the structure of UB in an embodiment of the present invention. Figure 4As shown, the UB header structure of the embodiment of the present invention includes: lockSize identifies the size of UB; occupied identifies the UB occupation flag, which is used to prevent repeated release (doublefree); isLongLife identifies whether it is a long life cycle; poolObj identifies the pointer of the memory pool to which UB belongs; largeMem identifies the LargeMem pointer to which UB belongs; the following fields are used to track memory leaks. After UB is applied, it is put into a bidirectional linked list to record the applied file name and code line; it is taken out from the linked list when UB is released. The debugging interface collects the occupied UB in the memory pool, counts the number of occupancy according to the file name and code line, and displays them from high to low according to the number of times, so as to provide clues for troubleshooting memory leaks. After the UB header is the memory space of the application.

[0087] The following is a specific example to illustrate the process of UB application in the embodiment of the present invention:

[0088] 1. Convert the input parameter of the interface, that is, the size of the UB requested by the application, into one of a series of preset fixed lengths;

[0089] 2. Check the UB size. If it exceeds the maximum value of a series of fixed lengths, call the system interface to apply for a preset memory slice and return;

[0090] 3. If the UB size is within a fixed length range, find the queue index of the corresponding size by searching the static array table;

[0091] 4. Iteratively select a return queue of a different thread from the different thread release queue, recycle the UB of the corresponding size from it, and put it into the idle queue;

[0092] 5. If the idle queue of the corresponding size is not empty, pop up a UB and check whether the conditions for reusing the UB are met;

[0093] 6. If there is no free UB that can be reused, and the large memory does not have enough space to allocate UB, first try to traverse all the return queues of different threads in the different thread release queue, recycle UB from the return queue of the corresponding size, and go through the process of checking the reused UB. If there is still no free UB that can be reused, create a new large memory;

[0094] 7. Allocate UB of the size calculated in the first step from the large memory, set the UB header, increase the memUBNum of the large memory header by one, and return the UB pointer to the application after offsetting the UB header.

[0095] In an embodiment of the present invention, the memory block released by the thread is managed based on the return queue and the idle queue, including: when a memory block is released, determining whether the released memory block is released by the same thread; if it is released by the same thread, directly checking whether the released memory block meets the preset reuse condition; if it is released by a different thread, storing the memory block in the return queue of the thread to which the memory block belongs, and when applying for reuse of the memory block, checking whether the memory block meets the preset reuse condition.

[0096] The preset reuse conditions described in the embodiment of the present invention include: when the released memory block is a long-life memory block, the number of long-life memory blocks in the preset memory slice to which the released memory block belongs is reduced by one; when the number of long-life memory blocks is greater than 0, all memory blocks in the preset memory slice to which the memory block belongs can be reused; when the number of long-life memory blocks is 0, after all memory blocks on the preset memory slice are released, the preset memory slice is returned to the system.

[0097] In the embodiment of the present invention, based on the return queue and the idle queue, managing the memory block released by the thread also includes:

[0098] Determine whether the released memory block is released by the same thread before, and determine whether the size of the released memory block exceeds the preset maximum memory block threshold. If so, directly return the released memory block to the system to effectively avoid invalid occupation of the preset memory slice, thereby improving memory usage efficiency.

[0099] The UB release process of the embodiment of the present invention will be described in detail below through a specific example:

[0100] 1. Get the pointer of the UB header after offsetting the UB header by the UB pointer released by the application (i.e. the above-mentioned thread);

[0101] 2. Check the UB size information recorded in the UB header. If it is larger than the maximum value of a series of fixed lengths, directly call the system's release interface to return the UB to the system and then return;

[0102] 3. If it is released by this thread, call to check whether the conditions for UB reuse are met; if the UB can be reused, put it at the head of the idle queue of the corresponding size and return;

[0103] 4. If it is released by a different thread, after returning the UB to the return queue of the memory pool of this thread, further call to check whether the conditions for UB reuse are met.

[0104] The embodiments of the present invention enable efficient, lock-free, and highly concurrent application and release of memory for complex aggregate objects, so that complex object communication can obtain the benefit of reduced copying, while the high performance of releasing UB by different threads reduces overhead, thereby greatly improving user experience.

[0105] Second embodiment

[0106] The embodiment of the present invention provides a device for managing a memory pool. Figure 5 , the device comprises a setting unit and a processing unit coupled to each other:

[0107] A setting unit is used to preset a memory pool corresponding to each thread and a return queue and an idle queue corresponding to each thread, wherein the memory pool includes a plurality of memory blocks. For any thread, the return queue is used to store the index of the memory block released after the thread provides it to other threads for use, and the idle queue is used to store the index of the idle memory block of the thread;

[0108] The processing unit is used to manage the application of memory blocks and the release of memory blocks by each thread based on the return queue and the idle queue.

[0109] like Figure 2 As shown, the idle queue of the embodiment of the present invention includes all free memory blocks in the first thread (i.e., thread 1, corresponding to the first memory pool object pool 1), and the return queue includes all memory blocks released by different threads in the second thread (i.e., thread 2, corresponding to the first memory pool object pool 2) and the third thread (i.e., thread 3, corresponding to the first memory pool object pool 3), and according to Figure 2 It can be seen that the memory blocks in the free queue and the return queue are stored according to a series of preset fixed lengths of different sizes, for example, a column of memory blocks with a length of 128 bytes, a column of memory blocks with a length of 256 bytes, and so on.

[0110] In specific implementation, the memory pools described in the embodiments of the present invention are all provided with a memory identification ID, and the memory identification is used to identify the memory pool corresponding to the memory block in the memory pool. That is, the embodiments of the present invention establish the association relationship between the memory block in the memory pool corresponding to the thread and the return queue and the idle queue of the thread through the memory identification, that is, the embodiments of the present invention associate the memory block with the thread through the memory identification, and manage the memory block through the idle queue and the return queue.

[0111] It should be noted that the memory pool described in the embodiment of the present invention is the memory allocated to the thread from the terminal system, that is, the embodiment of the present invention will also allocate the corresponding memory to the thread, but the memory of the present invention can be shared with different threads, and will not completely lock the thread and memory like the prior art. The system described in the embodiment of the present invention is an operating system on a terminal such as a server.

[0112] In specific implementation, the embodiment of the present invention allocates one or more preset memory slices (also referred to as large memory slices LargeMem) to each thread, and the preset memory slices further include a series of multiple memory blocks of various sizes for use by different application situations of the threads. For the division of specific memory blocks, those skilled in the art can divide them in advance according to the actual thread situation.

[0113] It should be noted that, in order to avoid occupying too many memory resources, in specific implementation, the embodiment of the present invention allocates a preset memory slice to each thread, and the preset memory slice is a memory of a predetermined size, such as 1M memory, or 4M memory, etc.

[0114] It can be understood that the memory pool of the embodiment of the present invention includes one or more preset memory slices, and the memory blocks applied for and released by the threads are all performed in the preset memory slices, and the application and release of memory blocks, as well as the idle queue and return queue are uniformly managed through the memory pool object.

[0115] In general, the core idea of ​​the embodiments of the present invention is to set a return queue and an idle queue corresponding to the thread, manage the memory blocks of the current thread and the memory blocks released by other threads through the return queue and the idle queue, and finally realize the sharing of memory blocks between different threads, thereby improving the multi-thread concurrent processing performance.

[0116] Furthermore, the processing unit in the embodiment of the present invention is also used to iteratively recycle the memory blocks in the return queue corresponding to the thread to the idle queue corresponding to the thread when any thread applies for a memory block, and allocate memory blocks to the thread from the idle queue.

[0117] It should be noted that the indexes of the memory blocks released by the different threads in the return queue of the embodiment of the present invention are stored according to different different threads and different preset fixed length series of the memory blocks under different different threads.

[0118] In a specific implementation, the processing unit of the embodiment of the present invention is that the processing unit is also used to, assume that any thread that applies for a memory block is a memory application thread, iteratively recover the memory blocks of different preset fixed-length categories released by the first different thread in the return queue corresponding to the memory application thread from the first memory block to the second to last memory block to the idle queue corresponding to the memory application thread; after iteratively recovering the memory blocks released by the first different thread, if the idle queue corresponding to the memory application thread does not contain the memory blocks applied for by the memory application thread, then apply for memory from the preset memory slices in the memory pool. If the requested memory block is not found in the preset memory slice, iteratively recovers the memory blocks of different preset fixed length categories released by the second different thread in the return queue to the free queue, and determines whether the requested memory block is in the free queue corresponding to the memory application thread. If not, it continues to iteratively recover the memory blocks released by other different threads. If the requested memory block is not found in all return queues, a new preset memory slice is applied from the system, and a memory block is allocated to the thread from the preset memory slice; wherein the preset memory slice contains a set number of memory blocks. .

[0119] That is to say, the embodiment of the present invention adopts a two-stage method of recycling and reusing UB for UB released by different threads, that is, in the first stage, when the different thread releases UB, the UB is first placed in the return queue of the current thread. In the second stage, when applying for UB, the UB is iteratively concatenated from the return queue to the idle queue, thereby completing the process of recycling and reusing UB. No locks are required in the entire process of recycling and allocating UB, making the algorithm complexity of concatenating UB O(1).

[0120] For ease of understanding, the following will combine Figure 2The process of releasing UB by a different thread in the embodiment of the present invention is described in detail: when the first thread applies for a memory block, the memory block in the return queue of the different thread is triggered to be recycled to the free queue (free Que), in the recycling process, firstly, each series of memory blocks of preset fixed length released by the first different thread is recycled, specifically, the first memory block to the second to last memory block of each series of memory blocks of preset fixed length are put into the memory block queue of corresponding length in the free queue; if after recycling, the free queue has not found the memory block to be applied for, then apply for the memory block from the preset memory slice; if the applied memory block is not found in the preset memory slice (it may be that the preset memory slice does not have enough space to allocate), it triggers the recycling of each series of memory blocks of preset fixed length released by the second different thread, specifically, the first memory block to the second to last memory block of each series of memory blocks of preset fixed length are recycled into the free queue; and so on, according to the iteration of each thread, the memory blocks released by the different threads are recycled into the return queue; if the applied memory block is not found after traversing all the return queues, a new preset memory slice is applied from the system, and the memory block is allocated to the thread from the preset memory slice.

[0121] Furthermore, the device described in the embodiment of the present invention also includes: a first judgment unit, used to judge whether the size of the memory block applied for by the memory application thread exceeds a preset maximum memory block threshold; if so, apply for a memory block from the preset memory slice, and the size of the applied memory block is equal to the size of the memory block applied for by the memory application thread; otherwise, trigger the processing unit.

[0122] That is, when receiving a memory block requested by a thread, it is first necessary to determine whether the size of the requested memory block exceeds the preset maximum memory block threshold (that is, the maximum value in the above series of preset fixed-length memory blocks). If so, the memory block is directly requested from the system.

[0123] It can be understood that when the memory block to be applied for exceeds the maximum value of a series of preset fixed lengths of the preset memory blocks, the corresponding memory block is directly applied for in the preset memory slice.

[0124] It should be noted that when the preset memory slice is insufficient for allocation, a new preset memory slice is requested from the system. The preset memory slice may be a memory of a uniformly specified size or the size of the requested memory block.

[0125] That is to say, when the preset memory slice is not enough for allocation, a preset memory slice can be re-applied from the system, and memory blocks can be allocated from the preset memory slice. The newly applied preset memory slice can be the size of the memory block applied for above that exceeds the preset maximum memory block threshold. When the memory block is released, the preset memory slice is directly returned to the system. Of course, a preset memory slice of a predetermined size can also be applied for according to the preset, and memory blocks can be allocated from the preset memory slice, and the rest of the preset memory slice can also be allocated to other applications of the thread for use.

[0126] That is, in specific implementation, the embodiment of the present invention can preset the sizes of all preset memory slices to be uniform, or can also specifically set the sizes of the preset memory slices according to actual conditions. Those skilled in the art can set it according to actual needs, and the present invention does not make specific limitations on this.

[0127] The processing unit in the embodiment of the present invention is further configured to select, according to the size of the memory block applied for by the thread, a memory block closest to the size of the memory block applied for by the thread from the idle queue corresponding to the thread and allocate the memory block to the thread.

[0128] That is to say, since the memory blocks in the embodiment of the present invention are a series of memory blocks with preset fixed lengths, in the embodiment of the present invention, according to the size of the memory block UB applied for by the thread, a memory block is selected from the free queue and allocated to the thread. Specifically, according to the size of the memory block UB applied for by the thread, a memory block closest to the size of the applied memory block is selected from the free queue corresponding to the thread and allocated to the thread.

[0129] Furthermore, the device described in the embodiment of the present invention also includes: a second judgment unit, used to judge whether the memory block applied for by the thread is a long-life memory block; if so, further judging whether the preset memory slice to which the applied memory block belongs is a long-life memory based on the life cycle identifier of the preset memory slice; if the preset memory slice is a long-life memory, the long-life memory quantity of the preset memory slice is increased by one; otherwise, the life cycle identifier of the preset memory slice is modified, and the long-life memory quantity of the preset memory slice is increased by one; wherein, the long-life memory block is a memory block for entity modeling, the preset memory slice is a memory of a preset size obtained from the memory pool, and the preset memory slice contains a set number of memory blocks.

[0130] Specifically, in order to avoid the problem that some microservices in the microservice architecture occupy too much memory due to conflicts and do not return it to the system, which puts pressure on the operating memory of the entire system, in an embodiment of the present invention, a life cycle identifier is set for the preset memory slice, and the life cycle of the preset memory slice is identified by the identifier. The preset memory slice with a long life cycle will continue to be reused, and the preset memory slice with a short life cycle will be returned to the system after all memory blocks are released, thereby effectively ensuring the efficient operation of the entire system.

[0131] Furthermore, the device described in the embodiment of the present invention also includes: a third judgment unit, which is used to determine whether the released memory block is released by the same thread when a memory block is released; if it is released by the same thread, directly check whether the released memory block meets the preset reuse conditions; if it is released by a different thread, store the memory block in the return queue of the thread to which the memory block belongs, and when applying for reuse of the memory block, check whether the memory block meets the preset reuse conditions.

[0132] Among them, the preset reuse conditions of the embodiment of the present invention are: when the released memory block is a long-life memory block, the number of long-life memory blocks in the preset memory slice to which the released memory block belongs is reduced by one; when the number of long-life memory blocks is greater than 0, all memory blocks in the preset memory slice to which the memory block belongs can be reused; when the number of long-life memory blocks is 0, after all memory blocks on the preset memory slice are released, the preset memory slice is returned to the system.

[0133] That is, the method described in the embodiment of the present invention supports UBs with long and short life cycles, so that entity modeling and event communication can use the same memory pool mechanism, which is convenient for unified management of memory. When a large piece of memory (i.e., the preset memory slice mentioned above) is consumed, a new large piece of memory is opened up. If the old large piece of memory has a UB with a long life cycle, all UBs on it can be reused to avoid invalid occupation of too much memory due to UB fragmentation; otherwise, it cannot be reused. After the UB is released, the old large piece of memory is returned to the system, thereby avoiding excessive memory occupation due to business bursts and not being returned to the system.

[0134] In specific implementation, the device described in the embodiment of the present invention also includes: a fourth judgment unit, used to judge whether the released memory block is released by the same thread before, and whether the size of the released memory block exceeds the preset maximum memory block threshold. If so, the released memory block is directly returned to the system. If not, the third judgment unit is triggered to effectively avoid invalid occupation of the preset memory slice, thereby improving memory utilization efficiency.

[0135] The relevant contents of the embodiments of the present invention can be understood by referring to the first embodiment of the present invention, and will not be discussed in detail here.

[0136] Third embodiment

[0137] An embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the method for managing a memory pool as described in any one of the first embodiments of the present invention are implemented. The specific content can be understood by referring to the first embodiment of the present invention, and will not be discussed in detail here.

[0138] Fourth embodiment

[0139] An embodiment of the present invention provides a server, the server comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the steps of the method for managing a memory pool as described in any one of the first embodiments of the present invention are implemented. The specific contents can be understood by referring to the first embodiment of the present invention, and will not be discussed in detail here.

[0140] Although the preferred embodiments of the present invention have been disclosed for illustrative purposes, those skilled in the art will appreciate that various modifications, additions and substitutions are possible, and thus, the scope of the present invention should not be limited to the above embodiments.

Claims

1. A method for managing a memory pool, characterized in that: The method comprises: A memory pool corresponding to each thread and a return queue and an idle queue corresponding to each thread are preset, and the memory pool includes a plurality of memory blocks; For any thread, the return queue is used to store the index of the memory block released after being provided by the thread to other threads, and the idle queue is used to store the index of the idle memory block of the thread; Based on the return queue and the idle queue, the memory pool of each thread is managed, including: when a memory block is released, determining whether the released memory block is released by the same thread; if it is released by the same thread, directly checking whether the released memory block meets the preset reuse condition; if it is released by a different thread, storing the memory block in the return queue of the thread to which the memory block belongs, and when applying for reuse of the memory block, checking whether the memory block meets the preset reuse condition; wherein the preset reuse condition includes: when the released memory block is a long-life memory block, reducing the number of long-life memory blocks of the preset memory slice to which the released memory block belongs by one, when the number of long-life memory blocks is greater than 0, all memory blocks in the preset memory slice to which the memory block belongs can be reused, and when the number of long-life memory blocks is 0, after all memory blocks on the preset memory slice are released, the preset memory slice is returned to the system.

2. The method according to claim 1, characterized in that The memory pools are all provided with memory identifiers, and the memory identifiers are used to identify the memory pools corresponding to the memory blocks in the memory pools.

3. The method according to claim 1, characterized in that The managing of the memory pool of each thread based on the return queue and the idle queue includes: When any thread applies for a memory block, the memory block in the return queue corresponding to the thread is iteratively recovered to the idle queue corresponding to the thread, and a memory block is allocated to the thread from the idle queue.

4. The method according to claim 3, characterized in that The index of the memory block of the return queue is stored according to different preset fixed length classifications of the memory blocks under different different threads; the different threads include other threads different from the current thread.

5. The method according to claim 4, characterized in that When any thread applies for a memory block, the memory block in the return queue corresponding to the thread is iteratively recovered to the idle queue corresponding to the thread, and a memory block is allocated to the thread from the idle queue, including: Assuming any thread that applies for a memory block as a memory application thread, iteratively recover memory blocks of different preset fixed-length categories released by the first different thread in a return queue corresponding to the memory application thread from the first memory block to the second to last memory block to an idle queue corresponding to the memory application thread; When, after iteratively recovering the memory block released by the first different thread, the idle queue corresponding to the memory application thread does not contain the memory block applied for by the memory application thread, apply for the memory block from the preset memory slice in the memory pool; if the applied memory block is not found in the preset memory slice, iteratively recover the memory blocks of different preset fixed-length categories released by the second different thread in the return queue to the idle queue, and determine whether the applied memory block is in the idle queue corresponding to the memory application thread; if not, continue to iteratively recover the memory blocks released by other different threads; if the applied memory block is not found after traversing all return queues, apply for a new preset memory slice from the system, and allocate memory blocks to the thread from the preset memory slice; The preset memory slice includes a set number of memory blocks.

6. The method according to claim 3, characterized in that The managing the memory pool of each thread based on the return queue and the idle queue also includes: Before iteratively recovering the memory blocks in the return queue corresponding to the thread to the idle queue corresponding to the thread, determine whether the size of the memory block applied for by the memory application thread exceeds a preset maximum memory block threshold; if so, apply for a memory block from the preset memory slice, and the size of the applied memory block is equal to the size of the memory block applied for by the memory application thread.

7. The method according to claim 3, characterized in that The indexes of the memory blocks in the idle queue are stored according to different preset fixed length categories of the memory blocks.

8. The method according to claim 7, characterized in that The allocating a memory block to the thread from the idle queue comprises: According to the size of the memory block applied for by the thread, a memory block closest to the size of the memory block applied for is selected from the idle queue corresponding to the thread and allocated to the thread.

9. The method according to claim 3, characterized in that The managing the memory pool of each thread based on the return queue and the idle queue also includes: Before iteratively recycling the memory block in the return queue corresponding to the thread to the idle queue corresponding to the thread, determining whether the memory block applied for by the thread is a long-life memory block, and if so, further determining whether the preset memory slice to which the applied memory block belongs is a long-life memory according to the life cycle identifier of the preset memory slice; If the preset memory slice is a long life cycle memory, the number of long life cycle memories of the preset memory slice is increased by one; Otherwise, modify the life cycle identifier of the preset memory slice, and increase the number of long life cycle memories of the preset memory slice by one; The long life cycle memory block is a memory block of entity modeling, and the preset memory slice includes a set number of memory blocks.

10. The method according to claim 1, characterized in that Based on the return queue and the idle queue, the memory pool of each thread is managed, further comprising: It is determined whether the released memory block is previously released by the same thread, and whether the size of the released memory block exceeds a preset maximum memory block threshold. If so, the released memory block is directly returned to the system.

11. A device for managing a memory pool, characterized in that: The device comprises: A setting unit is used to preset a memory pool corresponding to each thread and a return queue and an idle queue corresponding to each thread, wherein the memory pool includes a plurality of memory blocks; for any thread, the return queue is used to store the index of the memory block released after the thread provides it to other threads for use, and the idle queue is used to store the index of the idle memory block of the thread; A processing unit is used to manage the memory pool of each thread based on the return queue and the idle queue, including: when a memory block is released, determining whether the released memory block is released by the same thread; if it is released by the same thread, directly checking whether the released memory block meets the preset reuse condition; if it is released by a different thread, storing the memory block in the return queue of the thread to which the memory block belongs, and when applying for reuse of the memory block, checking whether the memory block meets the preset reuse condition; wherein the preset reuse condition includes: when the released memory block is a long-life memory block, reducing the number of long-life memory blocks of the preset memory slice to which the released memory block belongs by one, when the number of long-life memory blocks is greater than 0, all memory blocks in the preset memory slice to which the memory block belongs can be reused, and when the number of long-life memory blocks is 0, after all memory blocks on the preset memory slice are released, the preset memory slice is returned to the system.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A terminal, characterized in that: The terminal comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the steps of the method according to any one of claims 1 to 10 when executed by the processor.

Images