本申请涉及计算机技术领域，尤其涉及一种基于Linux系统的设备的内存分配方法及装置。
背景技术：
在基于Linux系统的设备中，随着软件功能的增加，对系统内存的消耗也会增加，但由于成本等因素的限制，设备的硬件可能无法及时更新换代，无法增加系统的总内存。同时，设备运行时，需要为操作系统的运行分配基础运行内存，对于同一型号的设备，系统的基础运行内存是基本固定的，但这种“固定”是动态的，即操作系统在运行时，各个基础进程并非始终使用最初分配到的某块内存，也会释放和申请内存，只是从整个操作系统的角度，对内存的需求量是基本固定的。因此，为了维持操作系统的正常运行，需要保证操作系统对内存的需求能够得到满足，在操作系统运行过程中申请内存时，能够被分配到需要的内存。
除了操作系统，设备中的软件也会向系统申请内存，现有技术中，对内存的管理方式是，操作系统和软件发出内存申请即为其进程分配内存、并在出现内存不足时杀掉占用内存较高的进程来释放内存，但由于为进程分配内存和杀掉进程，系统均无法区分该进程是属于操作系统或软件的，因此，在分配内存时，操作系统运行时临时释放的内存，可能会被分配给软件，导致操作系统申请基础运行内存时，无法分配到足够的内存，使得操作系统无法正常运行，而杀进程时可能会恰好杀掉操作系统的基础进程，导致操作系统瘫痪。
技术实现要素：
有鉴于此，本申请提供一种基于Linux系统的设备的内存分配方法及装置，技术方案如下：
一种基于Linux系统的设备的内存分配方法，其特征在于，设备的操作系统与软件使用不同的接口函数申请内存，该方法包括：
确定操作系统正常运行所需的基础运行内存；
根据总内存与基础运行内存的差值，得到软件可用内存上限；
在接收到内存申请的情况下，根据该内存申请所使用的接口函数，判断该内存申请的类型；
在判定为软件的内存申请的情况下，获得预先记录的软件已用内存；
在软件已用内存小于软件可用内存上限的情况下，根据该内存申请为对应软件分配内存、并更新所记录的软件已用内存。
一种基于Linux系统的设备的内存分配装置，其特征在于，设备的操作系统与软件使用不同的接口函数申请内存，该装置包括：
基础运行内存确定模块，用于确定操作系统正常运行所需的基础运行内存；
软件可用内存上限计算模块，用于根据总内存与基础运行内存的差值，得到软件可用内存上限；
内存申请类型判断模块，用于在接收到内存申请的情况下，根据该内存申请所使用的接口函数，判断该内存申请的类型；
软件已用内存获得模块，用于在判定为软件的内存申请的情况下，获得预先记录的软件已用内存；
软件内存分配模块，用于在软件已用内存小于软件可用内存上限的情况下，根据该内存申请为对应软件分配内存、并更新所记录的软件已用内存。
本申请所提供的技术方案，首先根据总内存及操作系统正常运行所需的基础运行内存，确定设备中的软件可以申请的内存的上限，在软件申请内存时，比较当前已申请的内存，是否达到了可申请内存的上限，只在未达到上限的情况下，为软件分配内存，并根据分配的内存对当前已申请内存更新，保证为操作系统正常运行预留出足够的基础运行内存。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。此外，本申请中的任一实施例并不需要达到上述的全部效果。
附图说明
为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是本申请实施例基于Linux系统的设备的内存分配方法的流程示意图；
图2是本申请实施例软件释放内存时更新软件已用内存的流程示意图；
图3是本申请实施例基于Linux系统的设备的内存分配装置的一种结构示意图；
图4是本申请实施例基于Linux系统的设备的内存分配装置的另一种结构示意图；
图5是本申请实施例软件内存分配模块与软件内存释放模块的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
为了保证操作系统正常运行所需的内存能够得到满足，避免操作系统运行过程中申请内存时，因无法分配到足够内存导致设备卡死瘫痪，本申请提供了一种基于Linux系统的设备的内存分配方法，参见图1所示，可以包括以下步骤：
S101，确定操作系统正常运行所需的基础运行内存；
基于Linux系统的设备中，维持操作系统正常运行的内存，可以称为基础运行内存，并可以包括为基础的系统进程、系统文件等分配的内存，操作系统在运行过程中，各个基础进程并非始终使用最初分配到的某块内存，也会释放和申请内存，只是从整个操作系统的角度，对内存的需求量是基本固定的，即基础运行内存的大小自操作系统启动完毕后将保持基本固定，并且同一型号的设备的基础运行内存也基本相同。本申请的内存分配方法中，为了保证操作系统申请内存时，能够被分配到足够的内存，首先需要确定所应用的设备的基础运行内存，并在设备运行时始终为操作系统预留出这部分的内存量。为此，本申请方案中，设备的操作系统与软件使用不同的接口函数申请内存，例如，在Linux系统中，操作系统和软件通常是使用malloc接口函数申请内存，在本申请的一种具体实施方式中，可以将malloc接口函数与另一个变量net_used一同封装为新的接口函数net_malloc，设备中的软件使用新的接口函数net_malloc申请内存，而操作系统仍使用接口函数malloc申请内存，从而将操作系统与软件的内存申请区分为不同类型，同时，变量net_used还可以用于记录软件已用内存的大小，并且net_used可以为原子变量，以避免多个线程同步操作时产生资源竞争问题。
由于同一型号的设备的基础运行内存基本相同，因此确定本方法所应用的设备的基础运行内存的方式可以有多种，例如，如果厂商在出产设备时在产品说明书中对此进行了说明，则可以通过用户的输入确定；也可以在某一型号的设备第一次启动时进行计算，或在每台设备第一次启动时甚至每次启动时进行计算；等等，本申请的基本方案理论上不需要对此进行限定，在实际应用中，本领域技术人员可以根据实际情况选择合适的方式。在本申请的一种具体实施方式中，可以在设备的操作系统启动后、软件启动前，确定设备当前的总已用内存、及软件已用内存，并根据总已用内存及软件已用内存的差值，得到操作系统正常运行所需的基础运行内存。以基于Linux系统的网络设备为例，由于网络设备中各软件占用的内存，基本均与网络会话、网络安全等网络业务有关，为了在网络设备的操作系统启动完毕后、软件启动之前进行计算，可以在内核模块均加载完毕后、网络接口启动前进行计算。计算时首先可以获取当前操作系统与软件的总已用内存，一般情况下，各个软件在启动前并不会占用内存，即此时的软件已用内存的大小为0，此时的总已用内存即基础运行内存，也可以认为是总已用内存减去大小为0的软件已用内存。但是，此时也可能会存在少量为保障软件的业务性能而预分配的内存，这部分内存应属于软件占用的内存，并且是由软件所使用的内存申请接口函数申请的，例如是使用上述的net_malloc接口函数申请的，这部分少量的软件已用内存还可以通过net_malloc函数中的net_used变量进行记录，这种情况下基础运行内存的值为，总已用内存减去大小不为0的软件已用内存。
S102，根据总内存与基础运行内存的差值，得到软件可用内存上限；
确定操作系统正常运行所需的基础运行内存后，即可确定软件可用内存的上限，即总内存减去基础运行内存后的余量。设备运行时，各个软件所占用的内存总量不超过软件可用内存上限，便不会造成操作系统的内存申请无法被满足的情况，因此不在物理上对设备的内存进行分割，也可以为操作系统预留出基础运行内存。
S103，在接收到内存申请的情况下，根据该内存申请所使用的接口函数，判断该内存申请的类型；
S104，在判定为软件的内存申请的情况下，获得预先记录的软件已用内存；
S105，判断软件已用内存是否小于软件可用内存上限；
S106，在软件已用内存小于软件可用内存上限的情况下，根据该内存申请为对应软件分配内存；
S107，更新所记录的软件已用内存。
为了便于描述，将S103至S107结合进行说明。
由于操作系统和软件使用不同的接口函数申请内存，在接收到内存申请时，可以通过所使用的接口函数，判断是操作系统还是软件的内存申请，如果判定为软件的内存申请，则在为对应软件分配内存之前，首先获得并判断当前的软件已用内存，是否小于之前计算的软件可用内存上限。如果确定当前的软件已用内存小于软件可用内存上限，则根据内存申请为对应的软件分配内存，并更新当前的软件已用内存，如果当前的软件已用内存大于或者等于软件可用内存上限，则不为对应的软件分配内存。
获得与更新当前的软件已用内存的方式可以有多种，例如，如果软件申请内存使用的接口函数为上述的封装有net_used变量的net_malloc函数，并且如上所述net_used变量可以用于记录软件已用内存，则每当软件使用net_malloc函数申请内存时，即可由net_used变量的值，获得到本次内存申请之前的软件已用内存，也就是当前的软件已用内存，并且在本次为对应软件分配内存之后，更新net_used变量的值，以便下次软件申请内存时调用；此外，也可以通过使用接口函数外的其他变量单独记录、并在需要时调用及更新等方式，获得与更新当前的软件已用内存，本申请的方案理论上不需要对此进行限定，在实际应用中，本领域技术人员可以根据实际情况选择合适的方式。
在S103中，如果判定该内存申请为操作系统的内存申请，则可直接为其分配内存，本申请方案中通过上述设置软件可用内存上限、并记录软件已用内存的过程，可以为操作系统预留出基础运行内存，保证操作系统的能够被分配到正常运行所需的内存。
此外，除了在软件申请内存后更新软件已用内存的大小，在软件释放内存后，也可以对软件已用内存进行更新。在本申请的一种具体实施方式中，设备的操作系统与软件使用不同的接口函数释放内存，例如，在Linux系统中，操作系统和软件通常是使用接口函数free释放内存，则可以将接口函数free与变量net_used一同封装为新的接口函数net_free，设备中的软件使用新的接口函数net_free释放内存，而操作系统仍使用接口函数free释放内存。如图2所示，在监测到内存被释放的情况下，还可以首先根据释放内存时所使用的接口函数，判断该内存是由操作系统释放的、还是由软件释放的，如果判定是由软件释放的，则可以相应地更新软件已用内存。例如，如果是如上所述使用封装有变量net_used的接口函数net_free释放内存，则可以更新变量net_used的值，以便之后软件申请内存时可以获得更准确的软件已用内存。
Linux系统中，可以通过链表、位图等多种算法进行内存的分配和释放，但是这些方法在接口函数底层实际分配或释放的内存，均可能大于在接口函数中写入的申请或释放的内存，例如，通过链表分配或释放内存时，每块内存均对应一个指向它的指针，这些指针也实际上需要占用内存；又如，位图是将内存划分为多个大小相同的块，通过位图分配或释放的内存，必须是位图中每一块的整数倍，当申请的内存不为位图中划分的块的整数倍时，实际分配的内存很可能比申请的内存大；等等，因此，为了使所记录的软件已用内存更准确，在本申请的一种具体实施方式中，分配或者释放内存后，获得所使用的接口函数底层函数中实际分配或者释放的内存的大小，并以此来更新所记录的软件已用内存。
相应于上述方法实施例，本申请还提供一种基于Linux系统的设备的内存分配装置，其特征在于，设备的操作系统与软件使用不同的接口函数申请内存，参见图3所示，该装置可以包括：
基础运行内存确定模块110，用于确定操作系统正常运行所需的基础运行内存；
软件可用内存上限计算模块120，用于根据总内存与基础运行内存的差值，得到软件可用内存上限；
内存申请类型判断模块130，用于在接收到内存申请的情况下，根据该内存申请所使用的接口函数，判断该内存申请的类型；
软件已用内存获得模块140，用于在判定为软件的内存申请的情况下，获得预先记录的软件已用内存；
软件内存分配模块150，用于在软件已用内存小于软件可用内存上限的情况下，根据该内存申请为对应软件分配内存、并更新所记录的软件已用内存。
在本申请的一种具体实施方式中，设备的操作系统与软件使用不同的接口函数释放内存，参见图4所示，该装置还可以包括软件内存释放模块160，用于：
在监测到内存被释放的情况下，根据释放该内存所使用的接口函数，判断该内存由操作系统、或软件释放；
在判定该内存由软件释放的情况下，根据所释放内存的大小，更新所记录的软件已用内存。
在本申请的一种具体实施方式中，参见图5所示，所述软件内存分配模块150，可以包括：
软件内存分配单元151，用于在软件已用内存小于软件可用内存上限的情况下，根据该内存申请为对应软件分配内存；
实际分配内存获得单元152，用于获得该内存申请所使用接口函数的底层函数中，实际分配的内存大小；
第一更新单元153，用于根据该实际分配的内存大小，更新所记录的软件已用内存；
所述软件内存释放模块160，可以包括：
实际释放内存获得单元161，用于在判定该内存由软件释放的情况下，获得该内存申请所使用接口函数的底层函数中，实际释放的内存大小；
第二更新单元162，用于根据该实际释放的内存大小，更新所记录的软件已用内存。
在本申请的一种具体实施方式中，所述基础运行内存确定模块110可以用于：
在操作系统启动后、软件启动前，确定当前总已用内存、及软件已用内存；
根据总已用内存及软件已用内存的差值，得到操作系统正常运行所需的基础运行内存。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
虽然本说明书包含许多具体实施细节，但是这些不应被解释为限制任何发明的范围或所要求保护的范围，而是主要用于描述特定发明的具体实施例的特征。本说明书内在多个实施例中描述的某些特征也可以在单个实施例中被组合实施。另一方面，在单个实施例中描述的各种特征也可以在多个实施例中分开实施或以任何合适的子组合来实施。此外，虽然特征可以如上所述在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合中的一个或多个特征在一些情况下可以从该组合中去除，并且所要求保护的组合可以指向子组合或子组合的变型。
类似地，虽然在附图中以特定顺序描绘了操作，但是这不应被理解为要求这些操作以所示的特定顺序执行或顺次执行、或者要求所有例示的操作被执行，以实现期望的结果。在某些情况下，多任务和并行处理可能是有利的。此外，上述实施例中的各种系统模块和组件的分离不应被理解为在所有实施例中均需要这样的分离，并且应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中，或者封装成多个软件产品。
由此，主题的特定实施例已被描述。其他实施例在所附权利要求书的范围以内。在某些情况下，权利要求书中记载的动作可以以不同的顺序执行并且仍实现期望的结果。此外，附图中描绘的处理并非必需所示的特定顺序或顺次顺序，以实现期望的结果。在某些实现中，多任务和并行处理可能是有利的。
以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。