CN114518962A - 内存的管理方法及装置 - Google Patents

Abstract

本公开提供了一种内存的管理方法及装置，该方法包括：响应于应用程序发送的第一内存需求，为所述应用程序分配第一内存段，其中，所述第一内存段位于操作***的用户空间的堆内存段中；响应于所述应用程序的第二内存需求，查找所述第一内存段中的空闲内存空间；当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间。本公开通过先申请一块具有较大内存空间的第一内存段，当第一内存段中的可用内存空间满足应用程序的当前内存需求时，可以直接从第一内存段中分配其所需要的内存空间，而不必向操作***发出内存申请，从而降低了与操作***的交互频率，提高了应用程序的运行效率。

Description

内存的管理方法及装置

技术领域

本公开涉及内存管理技术领域，并且更为具体地，涉及一种内存的管理方法及装置。

背景技术

现有技术在应用程序运行的过程中，需要不断向操作***发送内存的申请和释放请求，与操作***交互过多，导致程序运行效率较低。

发明内容

本公开提供一种内存的管理方法及装置，以解决与操作***交互过多所导致的程序运行效率较低的问题。同时，通过设计三级内存管理方法，实现应用程序多租户间、租户内模块间的内存隔离，便于精细化的控制和调优。

第一方面，提供一种内存的管理方法，所述方法包括：响应于应用程序发送的第一内存需求，为所述应用程序分配第一内存段，其中，所述第一内存段位于操作***的用户空间的堆内存段中；响应于所述应用程序的第二内存需求，查找所述第一内存段中的空闲内存空间；当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间。

作为一种可能的实现方式，所述方法还包括：当所述第一内存段无可用内存空间或所述第一内存段中的空闲内存空间不满足所述第二内存需求时，响应于向所述操作***发送的所述第二内存需求，为所述应用程序分配第二内存段，其中，所述第二内存段位于用户空间的堆内存段中。

作为一种可能的实现方式，所述为所述应用程序分配第二内存段，包括：若所述第一内存段和所述第二内存段的总内存空间满足预设条件，则对所述第一内存段的全部或部分内存进行释放；若所述第一内存段和所述第二内存段的总内存空间不满足预设条件，则为所述应用程序分配第二内存段。

作为一种可能的实现方式，所述预设条件为所述第一内存段和所述第二内存段的总内存空间超过所述应用程序可申请的内存上限。

作为一种可能的实现方式，所述方法还包括：响应于应用程序发送的内存释放请求，对所述第一内存段进行内存释放。

作为一种可能的实现方式，所述响应于应用程序发送的内存释放请求，对所述第一内存段进行内存释放，包括：获取所述应用程序可申请的剩余内存空间，所述剩余内存空间为可申请的内存上限与所述第一内存段的差值；响应于应用程序发送的内存释放请求，若所述剩余内存空间未超过所述第一内存段的内存空间，则对所述第一内存段进行内存释放。

作为一种可能的实现方式，所述方法还包括：响应于应用程序发送的内存释放请求，若所述剩余内存空间超过所述第一内存段的内存空间，则终止对所述第一内存段的内存释放，并缓存所述第一内存段。

作为一种可能的实现方式，所述当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间，包括：当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则按照每个租户的内存需求从所述第一内存段中为所述每个租户分配租户级的内存空间。

第二方面，提供一种内存的管理装置，所述装置包括：第一分配模块，被配置为响应于应用程序发送的第一内存需求，为所述应用程序分配第一内存段，其中，所述第一内存段位于操作***的用户空间的堆内存段中；查找模块，被配置为响应于所述应用程序的第二内存需求，查找所述第一内存段中的空闲内存空间；第二分配模块，被配置为当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间。

作为一种可能的实现方式，所述第二分配模块还用于：当所述第一内存段无可用内存空间或所述第一内存段中的空闲内存空间不满足所述第二内存需求时，为所述应用程序分配第二内存段，其中，所述第二内存段位于用户空间的堆内存段中。

作为一种可能的实现方式，所述第二分配模块还用于：若所述第一内存段和所述第二内存段的总内存空间满足预设条件，则对所述第一内存段的全部或部分内存进行释放；若所述第一内存段和所述第二内存段的总内存空间不满足预设条件，则为所述应用程序分配第二内存段。

作为一种可能的实现方式，所述预设条件为所述第一内存段和所述第二内存段的总内存空间超过所述应用程序可申请的内存上限。

作为一种可能的实现方式，所述装置还包括：释放模块，被配置为响应于应用程序发送的内存释放请求，对所述第一内存段进行内存释放。

作为一种可能的实现方式，所述释放模块用于：获取所述应用程序可申请的剩余内存空间，所述剩余内存空间为可申请的内存上限与所述第一内存段的差值；响应于应用程序发送的内存释放请求，若所述剩余内存空间未超过所述第一内存段的内存空间，则对所述第一内存段进行内存释放。

作为一种可能的实现方式，所述装置还包括：缓存模块，被配置为响应于应用程序发送的内存释放请求，若所述剩余内存空间超过所述第一内存段的内存空间，则终止对所述第一内存段的内存释放，并缓存所述第一内存段。

作为一种可能的实现方式，所述第二分配模块用于：当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则按照每个租户的内存需求从所述第一内存段中为所述每个租户分配租户级的内存空间。

第三方面，提供一种内存的管理装置，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面或第一方面中任一实现方式所述的方法。

第四方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一实现方式所述的方法。

第五方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一实现方式所述的方法。

本公开实施例提供了一种内存的管理方法，通过先申请一块具有较大内存空间的第一内存段，并对当前的内存申请进行管理，当第一内存段中的可用内存空间满足应用程序的当前内存需求时，可以直接从第一内存段中分配其所需要的内存空间，而不必向操作***发出内存申请，从而降低了与操作***的交互频率，提高了应用程序的运行效率。

附图说明

图1是本公开一实施例提供的虚拟地址空间的布局结构示意图。

图2是本公开一实施例提供的内存的管理方法的流程示意图。

图3是本公开一实施例提供的内存管理架构的结构示意图。

图4是本公开另一实施例提供的内存管理架构的结构示意图。

图5是本公开一实施例提供的内存申请方法的流程示意图。

图6是本公开一实施例提供的内存释放方法的流程示意图。

图7是本公开一实施例提供的内存的管理装置的结构示意图。

图8是本公开另一实施例提供的内存的管理装置的结构示意图。

具体实施方式

下面将结合本公开实施例的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。

内存是计算机最重要的部件之一，内存也可以称主存，它是CPU与磁盘/磁带等外存设备之间的桥梁。在程序运行时，操作***首先需要将待运行的数据与程序加载到内存中，再从内存调入到CPU中，若CPU所需访问的数据不在内存中，会自动触发缺页中断，由操作***和特殊的硬件设备响应此中断，将数据加载到内存中。

为简化应用程序的管理工作，相关术中，操作***一般使用虚拟内存技术管理内存，为应用程序提供一致的内存地址视图。该技术可以将一部分磁盘来充当内存使用，以释放应用程序对内存的占用。操作***可以是管理硬件资源及软件资源的计算机程序，例如可以是Windows操作***，也可以是Linux操作***，还可以是iOS操作***等，本公开实施例对此不做具体限制。物理内存可以是通过物理内存条而获得的内存空间，该内存空间的大小例如可以是真实的插在主板内存槽上的内存条的容量的大小。内存条例如可以是随机存取存储器（random access memory，RAM），随机存取存储器可以是静态随机存储器（static random-access memory，SRAM），例如还可以是同步动态随机存储器（synchronousdynamic random access memory，SDRAM），例如还可以是双倍速率同步动态随机存储器（double data rate SDRAM，DDR SDRAM）。

操作***可以为程序分配虚拟地址（virtual address，VA），处理器在读取数据时，可以通过内存管理单元将虚拟内存中的虚拟地址转化为物理内存中的物理地址（physical address，PA），在物理地址空间中进行数据的实际读写，该内存管理单元例如可以是内存管理单元（memory management unit，MMU），例如还可以是***内存管理单元(system memory management unit，SMMU)。

当创建一个进程时，操作***会为该进程分配一个固定大小的虚拟地址空间（即虚拟内存），下面结合图1，以Linux操作***为例，对该虚拟地址空间进行详细说明。如图1所示，虚拟地址空间100可以包括用户空间和内核空间，其中，应用程序运行在用户空间，操作***运行在内核空间。例如，可以为每个进程分配4G大小的虚拟地址空间，其中0~3G为该进程的用户空间，3~4G为内核空间。进一步地，内核空间例如可以包括内核镜像（KernelImage）、物理页框表（Mem_map）、动态内存映射区（如Vmalloc区，Ioremap区）、内存永久映射区（Persistent Kernel Mapping）、内存固定映射区（Temporary Kernel Mapping）等等。用户空间可以按段进行划分，例如可以包括保留区（Reserved）、程序段（Text Segment）、初始化数据段（Data Segment）、未初始化数据段（BSS Segment）、堆（Heap）地址段（也可以称为堆内存段）、栈（Stack）地址段，以及命令行参数（Command-line arguments）和全局环境变量（Environment Variables）等。需要说明的是，堆地址段是应用程序自行管理和使用一段地址段。应用程序例如可以通过malloc/alloc/mmap等API接口来申请堆内存，也可以通过free/munmap等API接口来释放堆内存。

堆地址段是由应用程序自行管理和使用的，为了提高堆内存段的利用率，在应用程序运行的过程中，通常采用按需分配的策略，即按其内存需求不断向操作***进行内存的申请或释放。这样一来，就导致与操作***交互过多，从而使得程序运行效率较低。

为了解决上述问题，本公开实施例提供了一种内存的管理方法，通过先申请一块具有较大内存空间的第一内存段，并对当前的内存申请进行管理，当第一内存段中的可用内存空间满足应用程序的当前内存需求时，可以直接从第一内存段中分配其所需要的内存空间，而不必向操作***发出内存申请，从而降低了与操作***的交互频率，提高了应用程序的运行效率。

下文结合图2对本公开实施例提出的一种内存的管理方法。图2所示，内存管理方法200包括步骤S220~S260。

在步骤S220，响应于应用程序发送的第一内存需求，为所述应用程序分配第一内存段。

应用程序可以是指为了完成某项或某几项特定任务而被开发运行于用户空间中的计算机程序。应理解，一个应用程序可以包括一个或多个进程，每个进程都需要一定的内存空间，一般是进程向操作***发送内存申请请求，由操作***进行内存分配。

操作***可以是上文中提及的操作***，该操作***例如可以是Windows操作***，也可以是Linux操作***，还可以是iOS操作***等。

第一内存需求可以是应用程序（或应用程序中的进程）向操作***发送的内存申请请求。作为一个示例，当应用程序首次运行（比如创建一个进程）时，应用程序会向操作***发送内存申请请求，响应于该申请请求，操作***会为该应用程序分配一段内存；作为另一个示例，现有***（如MySQL数据库***）针对每个登录用户，应用程序也会向操作***发送内存申请请求，由操作***进行内存分配，比如可以使用new运算符分配一个单独的线程结构THD。可以理解的是，在后续的用户SQL处理过程中，根据情况也会分配新的内存结构。

该第一内存段为已分配的内存，第一内存段可以是指操作***为应用程序分配的一段内存地址空间，第一内存段位于操作***的用户空间的堆内存段中。

需要说明的是，堆地址段位于用户空间，是应用程序自行管理和使用一段地址段。

在步骤S240，响应于应用程序的第二内存需求，查找所述第一内存段中的空闲内存空间。

在分配第一内存段之后，当应用程序再次有内存需求时，可以先查找第一内存段中的空闲内存空间，而不是直接向操作***发出内存申请，这样可以减少与操作***的交互。

第二内存需求是指在操作***为应用程序分配第一内存段之后的应用程序内存需求。

本公开实施例中查找第一内存段空闲内存空间的方式不做具体限制，例如可以通过SQL命令来查找。

在步骤S260，当第一内存段中的空闲内存空间满足第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间。

在一些实施例中，响应于第二内存需求，可以先查询第一内存段中的空闲内存空间，当第一内存段中无可用内存空间或第一内存段中的空闲内存空间不满足该第二内存需求时，此时，可以向操作***发送第二内存需求的内存申请请求，响应于该内存申请请求，操作***可以为该应用程序分配第二内存段。否则，响应于第二内存需求，可以从第一内存段中直接分配应用程序需要的内存空间，而不必向操作***发送内存申请，从而降低了与操作***的交互频率，提高了应用程序的运行效率。需要说明的是，第二内存段位于用户空间的堆内存段中。

在一些实施例中，为了将应用程序分散的内存申请集中化管理，可以对操作***的内存分配进行封装，对外提供唯一的动态内存申请接口，用于申请固定大小的内存块。例如可以通过ChunkMgr类实现对操作***内存分配API（mmap）的封装，对外提供唯一的动态内存申请接口alloc_chunk。也就说，本公开可以实现提供唯一的内存申请或内存释放的方法。响应于每次的内存申请请求，操作***可以为应用程序分配固定大小的内存地址空间（例如10MB大小的内存空间）。作为一个示例，响应于第一内存需求，为应用程序分配第一内存段，该第一内存段的内存空间为10MB。作为另一个示例，响应于向操作***发送的第二内存需求，操作***为应用程序分配第二内存段，第二内存段的内存空间也为10MB。也就是说，操作***每次都分配相同大小的一段内存地址空间。

在一些实施例中，在集中管理的基础上，为了对应用程序的可分配空间进行管理，例如可以设置可分配的内存上限（即可申请的内存上限），也可以设置留给紧急情况下使用的内存上限，还可以设置最大缓存的内存上限。为了更精细化的管理，可以将具有较大内存空间的已分配的内存段进行拆分，即拆分为多个普通内存块。例如可以按照租户的可分配内存来拆分。作为一个示例，可以将10MB的第一内存段拆分成5个2MB的普通内存块。然后对多个普通内存块进行链式管理，当普通内存块使用完毕之后，可以加入缓存链中进行缓存，而不必向操作***发出释放请求，以降低了与操作***的交互频率，提高应用程序的运行效率。

在一些实施例中，可以通过控制内存的申请和释放，来控制与操作***的交互频次。例如当应用程序向操作***发送第二内存需求的内存申请请求时，可以先计算，并统计已申请的全部内存量，然后判断该已申请的全部内存量是否满足预设条件，若满足预设条件，则需要对已分配的内存（即，此时的第一内存段）进行部分或全部的内存释放。若不满足预设条件，操作***响应于第二内存需求，可以为应用程序分配第二内存段。

已申请的第一内存段和第二内存段的总内存空间（即，已申请的全部内存量）

需要说明的是，该预设条件可以是已申请的全部内存量已经超过可分配的内存上限。其中，已申请的全部内存是指当前申请的内存量与已分配的内存量之和。作为一个示例，当应用程序向操作***发送第二内存需求的内存申请请求时，已分配的内存量为第一内存段，当前申请的内存量为第二内存段，此时，已申请的全部内存量为第一内存段和第二内存段之和。

需要说明的是，每次向操作***发出内存申请请求时，都需要判断已申请的全部内存量是否满足预设条件。应理解，响应于已申请的全部内存量满足预设条件，在对已分配的内存进行部分或全部的内存释放之后，仍需要再次判断已申请的全部内存量是否满足预设条件，而此时的已分配的内存量是指经释放之后剩余的已分配的内存量。

在一些实施例中，响应于应用程序对第一内存段的内存释放请求，可以对第一内存段进行内存释放。例如，当已申请的全部内存量满足预设条件，可以向操作***发送内存释放请求，并对第一内存段部分或全部的内存释放。

在一些实施例中，响应于应用程序对已申请内存段的内存释放请求，可以先计算获取应用程序可申请的剩余内存空间，若剩余内存空间未超过已分配的内存空间（例如在分配第二内存段之前，该已分配的内存空间为第一内存段），则可以对已分配的内存空间进行内存释放。若剩余内存空间已超过已分配的内存空间，则可以终止对已分配的内存空间的内存释放，并缓存第一内存段，以便后续集中释放，减少与操作***的交互频率。以第一内存段为当前已分配的内存空间为例，若剩余内存空间未超过第一内存段的内存空间，响应于对第一内存段的内存释放请求，则对第一内存段进行内存释放。若剩余内存空间超过第一内存段的内存空间，响应于对第一内存段的内存释放请求，则终止对第一内存段的内存释放，并缓存第一内存段。

需要说明的是，可申请的剩余内存空间可以是指应用程序的内存申请上限（即可分配的内存上限）与已分配的内存空间（例如第一内存段）的内存差值。可分配的内存上限可以根于用户需求自定义设置，本公开实施例对比不做具体限制。

需要说明的是，当已分配的内存中有空闲内存空间，且满足应用程序的内存需求时，可以由区块资源管理器，或软件程序来实现从空闲空间中分配其需求内存，而不必向操作***发送申请请求。例如，可以通过ChunkMgr提供区块资源管理，以实现对区块内空闲内存空间的分配。

根据上述内容可知，本公开实施例中提出了一种内存的管理方法，主要是对应用程序的可申请的内存空间进行管理。例如可以先申请一块具有较大内存空间的第一内存段，当应用程序再次发出内存需求时，可以先查找第一内存段中的可用内存空间，若该可用内存空间满足应用程序的内存需求，则可以直接从第一内存段中分配其所需要的内存空间，而不必向操作***进行内存申请。当已分配的内存空间需要进行内存释放时，可以先计算获取应用程序可申请的剩余内存空间，若该剩余内存空间超过已分配的内存空间，则可以先缓存当前待释放的内存空间，以等待后续的集中释放，而不必向操作***发送内存释放请求。也就是说，本公开中的方案通过控制内存的申请/释放，来减少与操作***的交互频次，从而提高了应用程序的运行效率。

一个数据库***可以有多个租户，多个租户之间可以是完全隔离的。在数据安全方面，可以通过不允许跨租户的数据访问的方式，确保用户的数据资产没有泄露的风险。租户可以是数据库***中资源的容器，资源例如可以是CPU、硬盘、内存等硬件资源，这些资源可以供多个用户使用。也就是说，租户可以是具有若干软硬资源的数据库功能的集合，用户可以通过租户使用数据库。一个租户中可以有一至多个用户，一个用户也可以属于不同的租户。

在一些实施例中，当第一内存段中的空闲内存空间满足第二内存需求时，可以根据每个租户的实际内存需求，可以从第一内存段中分配每个租户所需要的租户级内存空间。也就是说，在应用程序向操作***申请一大块内存（例如第一内存段）之后，可以按照应用程序中不同租户，从已申请的大块内存中获取每个租户所需要的内存。进一步地，还可以根据每个租户的可申请内存上限，向第一内存段进行租户级的内存申请或释放。将内存管理粒度到租户级别，每个租户之间相互独立，也更有利于实现租户间的内存资源隔离。以便根据具体的业务场景对应用程序运行过程中的不同的租户内存作精细化调优。

在一些实施例中，每个租户例如可以包括执行计划模块、memtable模块、sql模块、事务模块等模块。在单个租户内部可以根据不同的模块做模块级的内存申请或释放。也就是说，在每个租户获取租户级的内存之后，可以按照租户中不用的模块，从该租户中获取每个模块所需要的内存。进一步地，还可以根据每个模块的可申请内存上限，向租户进行模块级的内存申请或释放。比如可以按照执行计划模块、memtable模块、sql模块、事务模块等模块进行内存申请或释放。将内存管理粒度到模块级，每个模块之间相互独立，也更有利于实现模块间的内存资源隔离，以便根据具体的业务场景对租户运行过程中的不同内存模块作精细化调优。

本公开中的方案，通过模块级、租户级、区块级，三层级的管理，可以聚合微小而繁多的小内存（比如模块级的内存或租户级的内存）的申请或释放，最终由区块级的内存向操作***进行内存申请或释放，形成自定义的大块内存的管理方法，有效的避免了内存碎片问题，同时也降低了与操作***的交互。另外，通过设计三级内存管理方法，可以实现应用程序多租户间、租户内模块间的内存隔离，便于精细化的控制和调优。

为了进一步阐述本公开实施例中内存的管理方法，下面结合图3和图4对本公开中的内存管理架构进行详细描述。应理解，可以利用本公开中的内存管理架构对堆内存段的申请和释放进行管理。

如图3所示，该内存管理架构300可以包括区块管理层310、租户管理层320和模块管理层330。

区块管理层310可以包括区块资源管理器，用于实现对操作***的内存分配的封装，对外提供唯一的动态内存申请接口。通过该动态接口可以申请封装的固定大小的内存块。作为一个示例，例如可以通过ChunkMgr类实现对操作***内存分配API（比如mmap）的封装，对外提供唯一的动态内存申请接口alloc_chunk，用于大块内存的申请。例如第一内存段操作***分配的具有较大内存地址空间的内存块。在一些实施例中，例如可以通过ChunkMgr类实现对操作***内存分配API（mmap）的封装，对外提供唯一的动态内存申请接口alloc_chunk。也就说，本公开可以实现提供唯一的内存申请或内存释放的方法。响应于每次的内存申请请求，操作***可以为应用程序分配固定大小的内存地址空间（例如10MB大小的内存空间）。作为一个示例，响应于第一内存需求，为应用程序分配第一内存段，该第一内存段的内存空间为10MB。作为另一个示例，响应于向操作***发送的第二内存需求，操作***为应用程序分配第二内存段，第二内存段的内存空间也为10MB。也就是说，操作***每次都分配相同大小的一段内存地址空间。

在一些实施例中，为了方便内存空间的细致管理，可以将具有较大内存空间的第一内存块进行拆分，即拆分为多个普通内存块（例如可以根据租户的可分配内存进行拆分），然后进行链式管理。作为一个示例，可以将10MB的第一内存段拆分成5个2MB的普通内存块。这样一来，在未达到应用程序的可分配内存上限时，可以将前期已经使用完毕的普通内存块进行缓存，该缓存的普通内存块还可以用于后续的内存分配。这样一来，就可以达到只申请，不释放的目的。从而减少了与操作***的交互，提高了程序运行效率。

通过设计与操作***的唯一交互入口，对外呈现单一的分配与释放接口，以控制分散的内存申请和释放。同时，通过链式结构可以缓存前期已使用完毕的内存块，该缓存内存块也可以用于后续分配，可以减少***与操作***的交互，从而最大限度的提高***运行效率。

租户管理层320可以包括租户级资源管理器，用于对已分配的内存段进行租户级的管理。以第一内存段为当前已分配的内存为例，响应于每个租户的内存需求，可以从第一内存段中获取每个租户所需要的租户级内存空间。在租户管理层320中可以对每个租户进行管理，根据每个租户的可分配内存上限，可以控制租户的内存申请和释放。即，在未达到租户的可分配内存上限时，可以先缓存租户内的已经使用完毕的内存块，该租户内的缓存块还可以用于后续的内存分配。这样一来，就可以达到租户级的只申请，不释放的目的。以对内存组件作精细化调优。在一些实施例中，在租户管理层320还可以实现对租户层的封装，对外提供单一的接口，用于模块管理层330获取某个租户的内存资源。

模块管理层330可以包括模块内存分配器，用于对每个租户内不同模块的内存使用进行精细化控制。例如每个租户可以包括SQL模块、事务模块等。响应于租户中的模块的内存需求，可以从该租户中获取每个模块所需要的模块级内存空间。在模块管理层320中可以对每个租户的每个模块进行管理，根据租户中的模块的可分配内存上限，可以控制租户中的模块的内存申请和释放。即，在未达到模块的可分配内存上限时，可以先缓存模块内的已经使用完毕的内存块，该模块内的缓存块还可以用于后续的内存分配。这样一来，就可以达到模块级的只申请，不释放的目的。

如图4所示，应用程序可以使用模块管理层430中的模块内存分配器进行内存申请。模块管理层430可以将不同模块的内存申请请求发送至租户管理层420对应的租户，响应于模块管理层430中的内存申请请求，租户管理层420中的该租户可以根据可申请的内存上限和已分配的空闲内存空间，对模块进行内存分配或向区块管理层410发送租户内存申请请求，根据该应用程序可分配的内存上限和当前已分配的内存块中的空闲内存空间，区块管理层410可以对该租户进行内存分配或向操作***发送区块内存申请请求。同理，应用程序可以使用模块管理层430中的模块内存分配器进行内存释放。模块管理层430可以将模块的内存释放请求发送至租户管理层420对应的租户，响应于模块管理层430中的内存释放请求，租户管理层420中的该租户可以根据可申请的内存上限和租户内的空闲内存空间，对待释放的模块内存进行缓存或向区块管理层410发送租户内存释放请求，根据该应用程序的可分配的内存上限或区块内的空闲空间，区块管理层410可以对待释放的租户内存进行缓存或向操作***发送区块内存释放请求。通过模块级、租户级、区块级，三层级的管理，可以聚合微小而繁多的小内存（比如模块级的内存或租户级的内存）的申请或释放，最终由区块级的内存向操作***进行内存申请或释放，形成自定义的大块内存的管理方法，有效的避免了内存碎片问题，同时也降低了与操作***的交互。

可以理解的是，当建立一个进程时，操作***会为该进程分配一段内存地址空间。为了方便内存空间的细致管理，可以将已分配的具有较大内存空间的区块进行拆分，即拆分为多个普通内存块（例如可以根据租户的可分配内存进行拆分），然后进行链式管理。作为一个示例，可以将10MB的第一内存段拆分成5个2MB的普通内存块。假若当前已分配的内存空间为第一内存段，在此基础上，本公开实施例提出了一种内存申请和内存释放的管理方法。

如图5所示，为内存申请的管理方法，该方法包括如下步骤。

步骤1：响应于应用程序的内存申请请求，判断当前的内存申请是否为普通内存块的申请，若是普通块，则跳到步骤2，否则跳到步骤4。

步骤2：检查当前缓存链中的是否具有可用的缓存块，若有可用的缓存块，则跳到步骤3，否则跳到步骤10。

应理解，可用的缓存块可以是指前期已经使用完毕，加入缓存连进行缓存，而没有释放的普通内存块。

步骤3：分配可用的缓存块，即响应于内存申请请求，从缓存链中选择可用的缓存块，并分配该可用的缓存快，并跳到步骤13。

步骤4：判断已申请的全部内存量是否已经超过可分配的内存上限，若未超过上限，则向操作***发送该内存申请请求，并跳到步骤5。否则跳到步骤6。

需要说明的是，已申请的全部内存可以是指当前申请的内存量与已分配的内存量之和。

步骤5：操作***为应用程序分配内存段，并跳到步骤13。

步骤6：检查并判断当前缓存链中是否存在缓存，若存在缓存，则跳到步骤7，否则跳到步骤9。

步骤7：控制释放缓存链中的部分或全部的缓存，并向操作***发出内存申请请求。

步骤8：操作***为应用程序分配内存段，并跳到步骤13。

步骤9：已申请的全部内存量已超限，向用户发送内存超限提醒。

步骤10：判断已申请的全部内存量是否已经超过可分配的内存上限，若没有超过内存上限，则向操作***发送该内存申请请求，并跳到步骤11。否则跳到步骤12。

步骤11：操作***为应用程序分配内存段，并跳到步骤13。

步骤12：已申请的全部内存量已超限，向用户发送内存超限提醒。

步骤13：当前内存申请流程结束。

从上述方法可以看出，当缓存链中具有可用的缓存块时，可以从缓存链直接分配所需内存，从而减少了与操作***的交互。

如图6所示，为内存释放的管理方法，该方法包括如下步骤。

步骤1：响应于应用程序的内存释放请求，判断当前的内存释放是否为普通内存块的释放，若是普通块，则跳到步骤2，否则跳到步骤4。

步骤2：检查当前缓存链中的缓存量是否已经超过最大缓存量，若没有超过，则停止当前的普通内存块释放请求，并跳到步骤3，否则跳到步骤7。

应理解，最大缓存量可以是指最大可缓存的内存块的数量或最大的可缓存的内存空间。

步骤3：将待释放的普通内存块加入缓存链进行缓存，并跳到步骤8。

步骤4：判断应用程序可申请的剩余内存空间是否可以申请大内存块（比如第一内存段），若剩余空间可以申请大内存块，则跳到步骤5，否则跳到步骤6。

需要说明的是，可申请的剩余内存空间可以是指应用程序的可分配的内存上限与已分配的内存空间的内存空间差值。

步骤5：终止非普通内存块的释放，将该非普通内存块拆分成普通内存块，并跳到步骤2。

步骤6：将当前非普通内存块直接释放。

步骤7：将当前普通内存块直接释放。

步骤8：当前内存释放流程结束。

根据上述方法可以看出，当满足上述的缓存条件时，可以将内存块归还至缓存链进行缓存，以供下次分配使用，从而减少了与操作***的交互，提高了内存分配成功率。

通过本公开的内存管理方法，将应用程序分散的内存申请、释放工作集中化，可以降低与操作***的交互频率，从而提高了应用程序的运行效率。另外，也可以降低堆内存的遗漏释放的可能性，提高程序运行的可靠性。

在一些实施例中，以Linux***为例，本公开给出了区块管理层的主要设计方法和成员。主要设计方法包括公有方法（也可以称为对外方法）和私有方法。区块管理层的成员例如可以包括内部成员和其他成员等。

（1）区块管理层的设计方法

1）公有方法

alloc_chunk：提供唯一的内存块申请方法。

free_chunk：提供唯一的内存块释放方法。

set_max_chunk_cache_cnt：设置最大缓存的内存块数量。

set_limit：设置可分配的内存上限。

set_urgent：设置预留给紧急情况下使用的内存上限。

get_limit：获取最大可分配的内存上限。

get_urgent：获取预留给紧急情况下使用的内存上限。

get_hold：获取已申请的全部内存量，包括缓存中的内存块。

get_freelist_hold：获取当前缓存中的内存量。

2）私有方法

direct_alloc：用于直接向操作***申请内存块。

direct_free：通知操作***释放内存。

update_hold：更新已向操作***申请的全部内存量。

（2）区块管理层的成员

1）内部成员

limit_：记录***能使用的内存上线。

urgent_：记录预留给紧急情况下使用的内存上限。

hold_：记录***已申请的全部内存，包括缓存中的内存块。

2）其他内部成员

mmaps_：记录向操作***申请内存的次数。

munmaps_：记录向操作***释放内存的次数。

在一些实施例中，以Linux***为例，本公开给出了租户管理层的主要设计方法和成员。主要设计方法包括公有方法（也可以称为对外方法）和私有方法。租户管理层的成员例如可以包括内部成员。

（1）租户管理层的设计方法

1）公有方法

alloc_chunk：租户内存块分配，其调用实例内存管理器ChunkMgr的alloc_chunk接口分配内存块，同时指定其所属模块。

free_chunk：租户内存块释放，其调用实例内存管理器ChunkMgr的free_chunk接口分配内存块，同时指定其所属模块。

set_limit：设置租户总内存限制。

set_ctx_limit：设置指定模块内存限制。

get_limit：获取租户内存总量上限。

get_sum_hold：获取租户当前已分配内存总量。

get_ctx_limit：获取租户指定模块内存上限。

get_ctx_hold：获取租户指定模块已分配内存总量。

2）私有方法

update_hold：更新租户内存占有总量。

update_ctx_hold：更新租户指定模块内存占有量。

（2）租户管理层的成员

1）内部成员

tenant_id_：本租户内存管理器所属租户ID。

limit_：本租户内存管理器内存上限。

sum_hold_：本租户内存管理器已分配的全部内存量。

Ctx_hold_bytes_[N]：数组成员，记录租户不同模块已分配内存使用量。

Ctx_limit_bytes_[N]：数组成员，记录租户不同模块内存使用上限。

在一些实施例中，以Linux***为例，本公开给出了模块管理层的主要设计方法和成员。主要设计方法包括公有方法。模块管理层的成员可以包括私有成员。

（1）公有方法

alloc：对应Linux***malloc API，用于分配微小内存对象。

free：对应Linux***free API，用于释放微小内存对象。

realloc：对应Linux***realloc API，用于微笑内存对象大小修改。

（2）私有成员

obj_mgr_：对象管理器，用于真正的内存对象分配。在外部模块使用本分配器的alloc方法分配内存时，调用obj_mgr_的API分配其所需的内存对象。

tenant_id_：所属租户ID。

ctx_id_：所属模块ID。

上文结合图1至图6，详细描述了本公开的方法实施例，下面结合图7和图8，详细描述本公开的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。

图7是本公开实施例提供的一种内存的管理装置的结构示意图。该装置700包括第一分配模块710、查找模块720和第二分配模块730。

第一分配模块710可以被配置为响应于应用程序发送的第一内存需求，为所述应用程序分配第一内存段，其中，所述第一内存段位于操作***的用户空间的堆内存段中。

查找模块720可以被配置为响应于所述应用程序的第二内存需求，查找所述第一内存段中的空闲内存空间。

第二分配模块730可以被配置为当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间。

可选地，所述第二分配模块730还用于：当所述第一内存段无可用内存空间或所述第一内存段中的空闲内存空间不满足所述第二内存需求时，为所述应用程序分配第二内存段，其中，所述第二内存段位于用户空间的堆内存段中。

可选地，所述第二分配模块730还用于：若所述第一内存段和所述第二内存段的总内存空间满足预设条件，则对所述第一内存段的全部或部分内存进行释放；若所述第一内存段和所述第二内存段的总内存空间不满足预设条件，则为所述应用程序分配第二内存段。

可选地，所述预设条件为所述第一内存段和所述第二内存段的总内存空间超过所述应用程序可申请的内存上限。

可选地，所述装置700还包括：释放模块740可以被配置为响应于应用程序发送的内存释放请求，对所述第一内存段进行内存释放。

可选地，所述释放模块740用于：获取所述应用程序可申请的剩余内存空间，所述剩余内存空间为可申请的内存上限与所述第一内存段的差值；响应于应用程序发送的内存释放请求，若所述剩余内存空间未超过所述第一内存段的内存空间，则对所述第一内存段进行内存释放。

可选地，所述装置700还包括：缓存模块750可以被配置为响应于应用程序发送的内存释放请求，若所述剩余内存空间超过所述第一内存段的内存空间，则终止对所述第一内存段的内存释放，并缓存所述第一内存段。

可选地，所述第二分配模块730用于：当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则按照每个租户的内存需求从所述第一内存段中为所述每个租户分配租户级的内存空间。

图8是本公开实施例提供的另一种内存的管理装置的结构示意图。图8所述的内存管理装置800可以包括存储器810和处理器820，存储器810可以用于存储可执行代码。处理器820可以用于执行存储器810中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置800还可以包括网络接口830，处理器820与外部设备的数据交换可以通过该网络接口830实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储装置。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质（例如，数字通用光盘（digital video disc，DVD））或者半导体介质（例如，固态硬盘（solid state disk，SSD））等。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (17)

1.一种内存的管理方法，所述方法包括：

响应于应用程序发送的第一内存需求，为所述应用程序分配第一内存段，其中，所述第一内存段位于操作***的用户空间的堆内存段中；

响应于所述应用程序的第二内存需求，查找所述第一内存段中的空闲内存空间；

当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间。

2.根据权利要求1所述的方法，所述方法还包括：

当所述第一内存段无可用内存空间或所述第一内存段中的空闲内存空间不满足所述第二内存需求时，为所述应用程序分配第二内存段，其中，所述第二内存段位于用户空间的堆内存段中。

3.根据权利要求2所述的方法，所述为所述应用程序分配第二内存段，包括：

若所述第一内存段和所述第二内存段的总内存空间满足预设条件，则对所述第一内存段的全部或部分内存进行释放；

若所述第一内存段和所述第二内存段的总内存空间不满足预设条件，则为所述应用程序分配第二内存段。

4.根据权利要求3所述的方法，所述预设条件为所述第一内存段和所述第二内存段的总内存空间超过所述应用程序可申请的内存上限。

5.根据权利要求1所述的方法，所述方法还包括：

响应于应用程序发送的内存释放请求，对所述第一内存段进行内存释放。

6.根据权利要求5所述的方法，所述响应于应用程序发送的内存释放请求，对所述第一内存段进行内存释放，包括：

获取所述应用程序可申请的剩余内存空间，所述剩余内存空间为可申请的内存上限与所述第一内存段的差值；

响应于应用程序发送的内存释放请求，若所述剩余内存空间未超过所述第一内存段的内存空间，则对所述第一内存段进行内存释放。

7.根据权利要求6所述的方法，所述方法还包括：

响应于应用程序发送的内存释放请求，若所述剩余内存空间超过所述第一内存段的内存空间，则终止对所述第一内存段的内存释放，并缓存所述第一内存段。

8.根据权利要求1所述的方法，所述当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间，包括：

当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则按照每个租户的内存需求从所述第一内存段中为所述每个租户分配租户级的内存空间。

9.一种内存的管理装置，所述装置包括：

第一分配模块，被配置为响应于应用程序发送的第一内存需求，为所述应用程序分配第一内存段，其中，所述第一内存段位于操作***的用户空间的堆内存段中；

查找模块，被配置为响应于所述应用程序的第二内存需求，查找所述第一内存段中的空闲内存空间；

第二分配模块，被配置为当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则从所述第一内存段中为所述应用程序分配其所需要的内存空间。

10.根据权利要求9所述的装置，所述第二分配模块还用于：

当所述第一内存段无可用内存空间或所述第一内存段中的空闲内存空间不满足所述第二内存需求时，为所述应用程序分配第二内存段，其中，所述第二内存段位于用户空间的堆内存段中。

11.根据权利要求10所述的装置，所述第二分配模块还用于：

若所述第一内存段和所述第二内存段的总内存空间满足预设条件，则对所述第一内存段的全部或部分内存进行释放；

若所述第一内存段和所述第二内存段的总内存空间不满足预设条件，则为所述应用程序分配第二内存段。

12.根据权利要求11所述的装置，所述预设条件为所述第一内存段和所述第二内存段的总内存空间超过所述应用程序可申请的内存上限。

13.根据权利要求9所述的装置，所述装置还包括：

释放模块，被配置为响应于应用程序发送的内存释放请求，对所述第一内存段进行内存释放。

14.根据权利要求13所述的装置，所述释放模块用于：

获取所述应用程序可申请的剩余内存空间，所述剩余内存空间为可申请的内存上限与所述第一内存段的差值；

响应于应用程序发送的内存释放请求，若所述剩余内存空间未超过所述第一内存段的内存空间，则对所述第一内存段进行内存释放。

15.根据权利要求14所述的装置，所述装置还包括：

缓存模块，被配置为响应于应用程序发送的内存释放请求，若所述剩余内存空间超过所述第一内存段的内存空间，则终止对所述第一内存段的内存释放，并缓存所述第一内存段。

16.根据权利要求9所述的装置，所述第二分配模块用于：

当所述第一内存段中的空闲内存空间满足所述第二内存需求时，则按照每个租户的内存需求从所述第一内存段中为所述每个租户分配租户级的内存空间。

17.一种内存的管理装置，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现权利要求1-8中任一项所述的方法。

Images