CN112463358A - 内存管理方法、装置、车载系统以及车辆 - Google Patents

内存管理方法、装置、车载系统以及车辆 Download PDF

Info

Publication number
CN112463358A
CN112463358A CN202011181259.2A CN202011181259A CN112463358A CN 112463358 A CN112463358 A CN 112463358A CN 202011181259 A CN202011181259 A CN 202011181259A CN 112463358 A CN112463358 A CN 112463358A
Authority
CN
China
Prior art keywords
memory
amount
current
current memory
application amount
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202011181259.2A
Other languages
English (en)
Inventor
方彦彬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Rockwell Technology Co Ltd
Original Assignee
Beijing Rockwell Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Rockwell Technology Co Ltd filed Critical Beijing Rockwell Technology Co Ltd
Priority to CN202011181259.2A priority Critical patent/CN112463358A/zh
Publication of CN112463358A publication Critical patent/CN112463358A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0253Garbage collection, i.e. reclamation of unreferenced memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5022Mechanisms to release resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System (AREA)

Abstract

本公开涉及内存管理方法、装置、车载系统以及车辆,该方法包括:获取当前内存申请量;基于所述当前内存申请量,确定进行内存主动回收步骤;内存主动回收步骤包括:获取至少一个进程的当前内存占用量和当前内存空闲量;基于所述当前内存申请量、所述当前内存空闲量及运行中进程的所述当前内存占用量,确定需要关闭的进程,以使内存回收后的内存空闲量等于或大于所述当前内存申请量。本公开实施例提供的技术方案可基于当前内存申请量、当前内存占用量和当前内存空闲量,确定需要关闭的正在运行中的至少一个进程,实现内存主动回收,从而可在确保较高的内存利用率的同时,相较于传统的内存被动回收的方式,可节省内存回收时间,提高内存分配效率。

Description

内存管理方法、装置、车载系统以及车辆
技术领域
本公开涉及车辆技术领域,尤其涉及一种内存管理方法、装置、 车载系统以及车辆。
背景技术
随着车辆技术和互联网技术的不断发展,车辆的智能化程度和可 交互性越来越高。其中,车与人、车与外界(例如车与车、车与远端 控制中心)之间的信息通讯通常由车载系统(例如车机)实现。现有 技术中,车载系统的内存管理方法主要包括使用预留内存的方式和被 动回收的方式。
其中,使用预留内存的方式中,为了避免内存申请过程中可能出 现的问题,比如申请失败、申请时间长等问题,一些功能模块的内存 往往采用了预留内存的方式,从而保证了使用过程安全。但是,如果 该模块需要的内存较多时,且该模块的功能并不是一直运行,那么预 留内存的方式,虽然有效的避免了内存分配中可能出现的问题,但是 也带来了内存利用率低。
被动回收的方式中,对内存的使用者以进程为单位进行分级管理, 当高优先级的任务申请内存时,如果剩余内存较少,导致内存申请失 败,则会触发释放低优先任务的内存占用。这种内存管理方式,实现 了较为动态的内存管理,提升了内存使用效率。但是,当遇到内存申 请量较多时,内存的回收速度非常关键。如果回收太多,则造成了相 关业务下次运行时,需要重新分配内存;如果回收太少,则会触发多 次内存回收,效率太低,影响内存分配速度。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题,本公 开提供了一种内存管理方法、装置、车载系统以及车辆。
本公开实施例提供了一种内存管理方法,该方法包括:
获取当前内存申请量;
基于所述当前内存申请量,确定进行内存主动回收步骤;
所述内存主动回收步骤包括:
获取至少一个进程的当前内存占用量和当前内存空闲量;
基于所述当前内存申请量、所述当前内存空闲量及运行中进程的 所述当前内存占用量,确定需要关闭的进程,以使内存回收后的内存 空闲量等于或大于所述当前内存申请量。
在一些实施例中,所述获取当前内存申请量包括:
基于内存分配接口,获取当前内存申请参数;
统计各所述内存分配接口的所述当前内存申请参数,得到所述当 前内存申请量。
在一些实施例中,所述基于所述当前内存申请量,确定进行内存 主动回收步骤包括:
获取单位时间申请量阈值;
若单位时间内的所述当前内存申请量大于所述单位时间申请量阈 值,则确定进行内存主动回收步骤;和/或
获取单次申请量阈值;
若单次所述当前内存申请量大于所述单次申请量阈值,则确定进 行内存主动回收步骤。
在一些实施例中,所述基于所述当前内存申请量、所述当前内存 空闲量及运行中进程的所述当前内存占用量,确定需要关闭的进程, 以使内存回收后的内存空闲量等于或大于所述当前内存申请量包括:
基于所述当前内存申请量和所述当前内存空闲量,确定待回收内 存量;
基于所述待回收内存量和所述单位时间申请量阈值,或者基于所 述待回收内存量和所述单次申请量阈值,确定待主动回收内存量;
基于所述待主动回收内存量和运行中进程的所述当前内存占用量, 确定需要关闭的进程;
关闭所述进程。
在一些实施例中,所述基于所述待回收内存量和所述单位时间申 请量阈值,或者基于所述待回收内存量和所述单次申请量阈值,确定 待主动回收内存量包括:
对应地,采用R=L1-α*A或R=L1-β*M计算所述待主动回收内存 量R;
其中,L1代表待回收内存量,L1=L0-L,L0代表当前内存申请量, L代表当前内存空闲量;M代表所述单位时间申请量阈值,A代表所 述单次申请量阈值;α和β代表被动回收速率系数。
在一些实施例中,所述关闭所述进程包括:
统计各个业务低优先级进程的当前内存占用量;
基于所述待主动回收内存量和各低优先级进程的所述当前内存占 用量,确定进程列表;其中,所述进程列表中的各进程的当前内存占 用量之和等于或者大于所述待主动回收内存量;
关闭所述进程列表中的进程,释放内存。
在一些实施例中,该方法还包括:
获取单位时间申请量阈值;
若单位时间内的所述当前内存申请量小于或等于所述单位时间申 请量阈值,则确定不进行内存主动回收步骤;或者
获取单次申请量阈值;
若单次所述当前内存申请量小于或等于所述单次申请量阈值,则 确定不进行内存主动回收步骤。
在一些实施例中,所述内存主动回收步骤还包括:
若所述当前内存空闲量满足:L>α*A或L>β*M,则不触发内存主 动回收。
本公开实施例还提供了一种内存管理装置,该装置包括:
第一获取模块,用于获取当前内存申请量;
主动回收步骤确定模块,用于基于所述当前内存申请量,确定进 行内存主动回收步骤;
第二获取模块,用于获取至少一个进程的当前内存占用量和当前 内存空闲量;
内存回收模块,用于基于所述当前内存申请量、所述当前内存空 闲量及运行中进程的所述当前内存占用量,确定需要关闭的进程,以 使内存回收后的内存空闲量等于或大于所述当前内存申请量。
在一些实施例中,所述第一获取模块包括:
内存申请参数获取子模块,用于基于内存分配接口,获取当前内 存申请参数;
内存申请量确定子模块,用于统计各所述内存分配接口的所述当 前内存申请参数,得到所述当前内存申请量。
在一些实施例中,所述主动回收步骤确定模块包括:
第一阈值获取子模块,用于获取单位时间申请量阈值;
第二阈值获取子模块,用于获取单次申请量阈值;
回收确定子模块,用于若单位时间内的所述当前内存申请量大于 所述单位时间申请量阈值,则确定进行内存主动回收步骤,或者若单 次所述当前内存申请量大于所述单次申请量阈值,则确定进行内存主 动回收步骤。
在一些实施例中,所述内存回收模块包括:
待回收内存量确定子模块,用于基于所述当前内存申请量和所述 当前内存空闲量,确定待回收内存量;
待主动回收内存量确定子模块,用于基于所述待回收内存量和所 述单位时间申请量阈值,或者基于所述待回收内存量和所述单次申请 量阈值,确定待主动回收内存量;
进程确定子模块,用于基于所述待主动回收内存量和运行中进程 的所述当前内存占用量,确定需要关闭的进程;
内存回收子模块,用于关闭所述进程。
在一些实施例中,所述待主动回收内存量确定子模块具体用于:
对应地,采用R=L1-α*A或R=L1-β*M计算所述待主动回收内存 量R;
其中,L1代表待回收内存量,L1=L0-L,L0代表当前内存申请量, L代表当前内存空闲量;M代表所述单位时间申请量阈值,A代表所 述单次申请量阈值;α和β代表被动回收速率系数。
在一些实施例中,所述内存回收子模块包括:
当前内存统计单元,用于统计各个业务低优先级进程的当前内存 占用量;
进程列表确定单元,用于基于所述待主动回收内存量和各低优先 级进程的所述当前内存占用量,确定进程列表;其中,所述进程列表 中的各进程的当前内存占用量之和等于或者大于所述待主动回收内存 量;
内存释放单元,用于关闭所述进程列表中的进程,释放内存。
在一些实施例中,该装置还包括:
主动回收不触发模块,用于若单位时间内的所述当前内存申请量 小于或等于所述单位时间申请量阈值,或者单次所述当前内存申请量 小于或等于所述单次申请量阈值,则确定不进行内存主动回收。
在一些实施例中,该装置还包括:
主动内存回收不触发模块,用于若所述当前内存空闲量满足: L>α*A,或者L>β*M,则不触发内存主动回收。
本公开实施例还提供了一种计算机可读存储介质,其上存储有计 算机程序,所述计算机程序被处理器执行时,实现本公开实施例的上 述任一种方法。
本公开实施例还提供了一种车载系统,该车载系统包括:
处理器和存储器;
所述处理器通过调用所述存储器存储的程序或指令,用于执行本 公开实施例的上述任一种方法的步骤。
本公开实施例还提供了一种车辆,该车辆包括本公开实施例的车 载系统。
本公开实施例提供的技术方案与现有技术相比具有如下优点:
本公开实施例提供的内存管理方法包括:获取当前内存申请量; 基于当前内存申请量,确定进行内存主动回收步骤;内存主动回收步 骤包括:获取至少一个进程的当前内存占用量和当前内存空闲量;基 于当前内存申请量、当前内存空闲量及运行中进程的当前内存占用量, 确定需要关闭的进程,以使内存回收后的内存空闲量等于或大于当前 内存申请量。由此,该内存管理方法可基于当前内存申请量、当前内 存占用量以及当前内存空闲量,确定需要关闭的正在运行中的至少一 个进程,实现内存主动回收,从而可在确保较高的内存利用率的同时, 提高内存回收速度,有利于提高内存分配效率。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符 合本公开的实施例,并与说明书一起用于解释本公开的原理。
为了更清楚地说明本公开实施例或现有技术中的技术方案,下面 将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而 易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前 提下,还可以根据这些附图获得其他的附图。
图1为本公开实施例的一种内存管理方法的流程示意图;
图2为本公开实施例的另一种内存管理方法的流程示意图;
图3为本公开实施例的又一种内存管理方法的流程示意图;
图4为本公开实施例的又一种内存管理方法的流程示意图;
图5为本公开实施例的又一种内存管理方法的流程示意图;
图6为本公开实施例的又一种内存管理方法的流程示意图;
图7为本公开实施例的一种内存管理装置的结构示意图;
图8为本公开实施例的另一种内存管理装置的结构示意图;
图9为本公开实施例的又一种内存管理装置的结构示意图;
图10为本公开实施例的一种车载系统的结构示意图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点,下面将 对本公开的方案进行进一步描述。需要说明的是,在不冲突的情况下, 本公开的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本公开,但 本公开还可以采用其他不同于在此描述的方式来实施;显然,说明书 中的实施例只是本公开的一部分实施例,而不是全部的实施例。
基于上述背景技术中的问题,本公开实施例提供了一种结合内存 被动回收和内存主动回收的内存管理方法,该方法首先获取当前内存 申请量,并在当前申请量较大时,或者当前内存分配申请速度较快时, 触发内存主动回收;在进行内存主动回收之前,获取至少一个进程的 当前内存占用量和当前内存空闲量,其后基于上述获取的当前内存申 请量、当前内存空闲量及运行中进程的当前内存占用量,确定需要关 闭的进程,即实现内存主动回收,以使回收后的内存空闲量等于或大 于当前内存申请量,从而满足当前内存申请需求。同时,不需要预留 内存,可提高内存利用率;也不需要循环执行被动回收方式中的多次 触发内存回收的过程,从而内存回收效率较高,有利于提高内存分配 速度,从而利于提高系统(例如下文中的车载设备)的运行速度。
本公开实施例提供的内存管理方法可适用于任何一种用于执行软 件程序或指令的控制器,以用来提高内存释放效率,从而提高内存分 配速度。例如,该方法可应用于固定终端(例如智能电视或电脑)或 移动终端(例如智能手机、平板、移动电脑或智能车辆)。其中,将该 内存管理方法应用于车辆(例如智能车辆)中时,该方法可由车辆中 的任一控制器执行,下文中以车载系统为示例进行示例性说明。
下面结合图1-图10,对本公开实施例提供的内存管理方法、装置、 车载系统以及车辆进行示例性说明。
示例性地,图1为本公开实施例的一种内存管理方法的流程示意 图。参照图1,该方法可包括:
S110、获取当前内存申请量。
其中,当前内存申请量也可称为当前内存需求量,表征将要执行 的业务所要占用的内存量,即内存的大小。
示例性地,依据将要执行的业务的复杂程度,当前内存申请量可 为800M、500M、387M、125.8M或其他内存大小,本公开实施例对此 不限定。
该步骤中,当前内存申请量的获取方式可为,采用程序代码直接 调用内存资源分配请求,或者将当前将要执行的各业务的内存申请量 进行统计,得到当前内存申请量,下文中进行示例性说明。
在其他实施方式中,该步骤还可为:接收内存资源分配请求。
需要说明的是,该步骤可包括获取当前时刻的单次内存申请量, 或者获取当前时段(例如单位时间)内的内存申请总量。
S120、基于当前内存申请量,确定进行内存主动回收步骤。
其中,当S110中获取的当前内存申请量较大而不易被满足时,触 发进行内存主动回收步骤,包括判断是否真正触发内存主动回收、确 定主动回收内存量及确定对应被关闭的进程。
示例性的,该步骤的细化流程,在下文中结合图3和图4详述。
需要说明的是,该步骤中的内存主动回收步骤,是指尝试进行主 动内存回收,包括进行是否触发内存主动回收的进一步判断。基于内 存主动回收判断,确定需要进行内存主动回收,执行S130和S140。即 内存主动回收步骤包括S130和S140。
S130、获取至少一个进程的当前内存占用量和当前内存空闲量。
其中,当前内存空闲量即当前未被占用的内存的大小,进程的当 前内存占用量是指进程运行过程中、在当前时刻所占用的内存的大小。
该步骤中,进程的当前内存占用量和当前内存空闲量的获取方式 可通过在服务器查询得到,或采用为本领域技术人员可知的其他方式, 本公开实施例不限定。
需要说明的是,当进程数量为两个或更多个时,分别获取各进程 的当前内存占用量。
S140、基于当前内存申请量、当前内存空闲量及运行中进程的当 前内存占用量,确定需要关闭的进程,以使内存回收后的内存空闲量 等于或大于当前内存申请量。
其中,当前内存申请量较大时,当前内存空闲量无法满足将要执 行的业务的内存需求,此时,可基于处于运行中状态的各进程的当前 内存占用量,确定可补偿当前内存申请量与当前内存空闲量之间的差 值的进程,即该进程作为可被关闭的进程。当运行中的进程被关闭之 后,该进程所占用的内存资源被释放,可作为内存空闲量的补充,从 而可增加内存剩余总量,以满足当前内存申请需求。
示例性地,若当前内存申请量为800M,当前内存空闲量为500M; 运行中的进程数量为3个,其当前内存占用量分别为100M、300M和 350M;则为了补偿当前内存申请量与当前内存空闲量之间的内存差值, 即800-500=300M,被关闭的进程的当前内存占用量等于或大于300M, 即可关闭当前内存占用量为300M或350M的进程,进程关闭之后,可 对应释放300M或350M的内存,从而使得内存剩余总量为800M或 850M,以满足当前内存申请需求。
需要说明的是,上一段文字中的数值仅为示例性的说明。在其他 实施方式中,可基于实际应用业务场景,基于S110和S130中获取到 的上述各参数,确定需要关闭的至少一个进程,以满足当前内存资源 的分配请求。
本公开实施例提供的内存管理方法中,首先获取当前内存申请量, 并基于当前内存申请量判断是否需要触发内存主动回收步骤;若当前 内存申请量较大而不易被满足时,进行内存主动回收步骤,以触发内 存主动回收,即主动确定需要关闭的至少一个进程;在此之前,获取 至少一个进程的当前内存占用量和当前内存空闲量;并基于当前内存 申请量、当前内存空闲量以及处于运行状态的进程的当前内存占用量, 确定需要被关闭的进程,数量根据需要释放的内存大小确定,以使进 程被杀死之后,内存剩余总量等于或者大于当前内存申请量,从而可 满足当前内存申请需求。同时,基于上述参数主动确定需要结束的进 程,单次内存释放之后即可满足当前内存申请需求,如此内存回收效 率较高,从而内存分配速度较快,如此兼顾了内存使用效率和内存分 配速度。
在上述实施方式的基础上,S110的实现方式可为任一种可确定当 前内存申请量的方式,例如当前内存申请量可直接监测(例如在服务 器中查询)得到,也可间接统计得到,适用于不同的应用场景时,可 采用不同的方式。下面结合图2,对通过统计,间接得到当前内存申请 量进行示例性说明。
在一些实施例中,图2为本公开实施例的另一种内存管理方法的 流程示意图,细化说明了图1中S110的执行流程。在图1的基础上, 参照图2,该方法可包括:
S110、获取当前内存申请量。
本实施例中,S110具体可包括:
S111、基于内存分配接口,获取当前内存申请参数。
其中,内存分配接收可用于接收内存分配请求,以及为不同的业 务或进程配置内存资源。由此,内存分配接口可接收当前内存申请参 数,后续通过对当前内存申请参数进行统计,可确定当前内存申请量。
S112、统计各内存分配接口的当前内存申请参数,得到当前内存 申请量。
其中,当内存分配接口为多个时,对各内存分配接口在同一时刻 接收到的当前内存申请参数进行加和,可计算得出该时刻的单次当前 内存申请量。当内存分配接口为一个、两个或更多个时,对各内存分 配接口在一个时段内接收到的当前内存申请参数进行加和,可计算得 出该时段的内存申请总量。
示例性地,若内存分配接口数量为3个,其在同一时刻获取的当 前内存申请参数分别为100M、200M和500M,则该时刻的单次当前 内存申请量为800M,即100M、200M和500M的加和结果。
示例性的,若内存分配接口数量为2个,其在单位时间内的内存 申请次数分别为2次,前一次的两个当前内存申请参数分别为150M和 300M,后一次的两个当前内存申请参数分别为200M和180M,则该 单位时间内的当前内存申请量为830M,即上述150M、300M、200M及150M的加和结果。
需要说明的是,上述两段文字仅示例性的说明了当前内存申请量 的确定方式,但并不构成对内存分配接口可获取的当前内存申请参数 的限定。在其他实施方式中,内存分配接口可获取的当前内存申请参 数可基于实际业务场景确定,本公开实施例对此不限定。
S120、基于当前内存申请量,确定进行内存主动回收步骤。
S130、获取至少一个进程的当前内存占用量和当前内存空闲量。
S140、基于当前内存申请量、当前内存空闲量及运行中进程的当 前内存占用量,确定需要关闭的进程,以使内存回收后的内存空闲量 等于或大于当前内存申请量。
至此,通过内存主动回收,可满足当前内存申请需求。
上述S120-S140与图1中的步骤对应相同,可参照上文中对图1 中的对应步骤的解释说明进行理解,在此不赘述。
在上述实施方式的基础上,S120的实现方式可包括:设定参考阈 值,用于判断内存的分配速度是否过快,从而确定当前内存申请量能 否被满足。
其中,本实施例中,内存回收方式可包括被动回收和主动回收两 种方式,内存被动回收的速度较快时,当前内存空闲量与被动回收内 存量构成的剩余内存总量通常较多,此时当前内存申请量容易被满足, 此时可认为内存的分配速度较慢,内存被动回收可满足当前内存申请 量需求时,则无需触发内存主动回收。而内存被动回收的速度较慢时, 当前内存空闲量与被动回收内存量构成的剩余内存总量可能较少,此 时当前内存申请量不易被满足,此时可认为内存的分配速度较快,内 存被动回收不能满足当前内存申请量需求,则需要触发内存主动回收。 基于此,利用参考阈值用于判断是否需要触发内存主动回收。下面结 合图3和图4,对是否需要触发内存主动回收进行示例性说明。
在一些实施例中,图3为本公开实施例的又一种内存管理方法的 流程示意图,示出了图1中S120的一种细化执行流程。在图1的基础 上,参照图3,S120可包括:
S1211、获取单位时间申请量阈值。
其中,单位时间申请量阈值用于判断内存的分配速度是否过快, 且单位时间申请量阈值对应与单位时间内的当前内存申请量进行比较, 即下文中S1212中的比较判断。
S1212、若单位时间内的当前内存申请量大于单位时间申请量阈值, 则确定进行内存主动回收步骤。
即,将单位时间内的当前内存申请量与单位时间申请量阈值进行 比较,判断二者相对大小。若单位时间内的当前内存申请量大于单位 时间申请量阈值,则表明内存分配速度过快,无法满足内存需求,需 要触发内存主动回收。
至此,完成S120。
在一些实施例中,图4为本公开实施例的又一种内存管理方法的 流程示意图,示出了图1中S120的另一种细化执行流程。在图1的基 础上,参照图4,S120可包括:
S1221、获取单次申请量阈值。
其中,单次申请量阈值也用于判断内存的分配速度是否过快,单 次申请量阈值与单位时间申请量阈值的区别在于,单次申请量阈值用 于对应与单词当前内存申请量进行比较,即下文中S1222中的比较判 断。
S1222、若单次当前内存申请量大于单次申请量阈值,则确定进行 内存主动回收步骤。
即,将单次当前内存申请量与单次申请量阈值进行比较,判断二 者的相对大小。若单次当前内存申请量大于单次申请量阈值,则表明 内存分配速度过快,无法满足内存请求,需要触发内存主动回收。
至此,完成S120。
其中,单位时间申请量阈值和单次申请量阈值的具体取值可根据 业务场景确定,本公开实施例对此不限定。
此外,图3和图4中的S110、S130及S140均与图1中的步骤对 应相同,可参照上文中对图1中的对应步骤的解释说明进行理解,在 此不赘述。
在上述实施方式的基础上,本公开实施例的内存管理方法中,确 定进行内存主动回收步骤的另一种实现方式为:将单位时间内的当前 内存申请量与单位时间申请量阈值比较,同时,将单次当前内存申请 量与单次申请量阈值比较,只要满足S1212和S1222中的至少一个条 件,则确定进行内存主动回收步骤。如此,可满足瞬时大申请量,也 可满足单位时间对应的平均申请量需求,从而内存分配效率较高。
在上述实施方式的基础上,为实现内存主动回收,需要基于S110 和S130中获取的相关参量(包括当前内存申请量、当前内存空闲量及 运行中进程的当前内存占用量),确定需要关闭的进程,以使内存回收 后的内存空闲量等于或大于当前内存申请量,从而经过单次内存释放 即可满足当前内存申请需求,提高内存回收效率,提高内存分配速度。
下面结合图5对如何基于上述获取的相关参量确定需要关闭的进 程进行示例性说明。
在一些实施例中,图5为本公开实施例的又一种内存管理方法的 流程示意图,示出了图1中S140的一种细化执行流程。在图1的基础 上,参照图5,S140可包括:
S141、基于当前内存申请量和当前内存空闲量,确定待回收内存 量。
其中,若当前内存空闲量不足以满足当前内存申请量,则需要进 行内存回收,以满足当前内存申请需求。基于此,待回收内存量可由 当前内存申请量和当前内存空闲量做差值得到,即待回收内存量等于 当前内存申请量减去当前内存空闲量。
示例性的,当前内存申请量为800M,当前内存空闲量为500M时, 待回收内存量可为300M,即由800M-500M得到。
S142、基于待回收内存量和单位时间申请量阈值,或者基于待回 收内存量和单次申请量阈值,确定待主动回收内存量。
其中,单位时间申请量阈值和单次申请量阈值还分别与内存被动 回收量相关,其中可相差一个可调系数。
示例性的,该步骤具体可包括:对应地,采用R=L1-α*A或 R=L1-β*M计算待主动回收内存量R。
其中,L1代表待回收内存量,L1=L0-L,L0代表当前内存申请量, L代表当前内存空闲量;M代表所述单位时间申请量阈值,A代表所 述单次申请量阈值;α和β是被动回收速率系数,代表被动回收的效率。 当α和β的取值较大时,内存被动回收量较大,此时被动回收较积极, 主动回收可较消极;当α和β的取值较小时,内存被动回收量较小, 此时被动回收较消极,主动回收会较积极。
其中,α*A可代表单次内存被动回收量,β*M可代表单位时间内 的内存被动回收量。利用待回收内存量减去内存被动回收量,即得到 需要主动回收的内存量,即待主动回收内存量。
示例性的,结合上文中对S141的解释说明,待回收内存量为300M, 其可由内存被动回收和内存主动回收共同实现;待主动回收内存量等 于待回收内存量与被动回收内存量之差。基于此,当内存被动回收量 为100M时,待主动回收内存量为200M;当内存被动回收量为30M时, 待主动回收内存量为270M。
需要说明的是,当内存中包括预留的系统内存余量时,当前内存 空闲量、内存被动回收量及内存主动回收量的总和需等于或大于内存 申请量与系统内存余量之和。其中,预留的系统内存余量作为系统中 关键进程的预留空间,以确保系统中的关键进程可正常进行,有利于 确保系统良好运行。上述计算公式中,可将系统内存余量整合至内存 申请量中,即内存申请量中包括了预留出来的系统内存余量。在其他 实施方式中,也可将系统内存余量在计算公式中直观的表示出来。示 例性地,可采用L00代表系统内存余量,此时待回收内存量L1可采用 L1=L0+L00+L计算得到。
或者理解为,由于系统内存余量是在内存中规划出来的不能分配 给当前进程的内存空间,所以对于当前内存申请量而言,这部分系统 内存余量并不是空闲的,而是被分配给了系统中的关键进程的,由此 可认为当前内存空闲量中仅包括可分配给当前进程的剩余空间,即当 前内存空闲量的计算方式可为:
当前内存空闲量=内存总容量-当前内存占用量-系统内存余量。
在其他实施方式中,待主动回收内存量还可采用本领域技术人员 可知的其他方式计算得到,本公开实施例对此不赘述也不限定。
S143、基于待主动回收内存量和运行中进程的当前内存占用量, 确定需要关闭的至少一个进程。
其中,将运行中的进程的当前内存占用量与待主动回收内存量进 行比对匹配,二者相等,或者前者大于后者时,可确定关闭对应的一 个或多个进程。
示例性的,结合上文中对S142的解释说明,待主动回收内存量为 270M时,若运行中进程的当前内存占用量分别为200M、300M和400M, 则为了满足待主动回收内存量小于或者等于确定需要关闭的进程的当 前内存占用量,可被关闭的进程为300M或者400M当前内存占用量对 应的进程。
在一些实施例中,在运行中进程的当前内存占用量作为进程关闭 的确定参数之一的同时,还可结合运行中进程的优先级确定需要关闭 的至少一个进程。下文中结合图6进行示例性说明。
S144、关闭至少一个进程,以进行内存回收。
关闭S143中确定的需要关闭的至少一个进程,以释放其对应的内 存,从而满足当前内存申请需求。
至此,完成S140。
该方法的其他前述步骤可参照图1-图4任一图以及上文中的解释 说明进行理解,在此不赘述。
在上述实施方式中,当需要关闭的进程为两个或更多个时,可生 成进程列表,然后对应关闭进程列表中的进程。下面结合图6对此进 行示例性说明。
在一些实施例中,图6为本公开实施例的又一种内存管理方法的 流程示意图,示出了图5中S144的一种细化执行流程。在图5的基础 上,参照图6,S144包括:
S1441、统计各个业务低优先级进程的当前内存占用量。
其中,业务场景中的低优先级进程相对高优先级进程而言,对当 前运行的系统的稳定性、安全性或其他性能的影响较小,为了最小化 内存主动回收对当前运行系统的影响,本实施例中优先关闭低优先级 进程。
该步骤中,对运行中的各个业务中的低优先级进程的当前内存占 用量进行查询,并汇总;一方面为了确定可被关闭的进程,另一方面, 当多个进程或多种进程组合均满足当前内存申请需求时,选择优先级 较低的进程或进程列表进行关闭。
S1442、基于待主动回收内存量和各低优先级进程的当前内存占用 量,确定进程列表。
其中,进程列表中的各进程的当前内存占用量之和等于或者大于 待主动回收内存量。如此,将进程列表中的各进程关闭之后,释放的 内存可满足当前内存申请需求。
示例性地,结合上文中对S143的解释说明,待主动回收内存量为 270M时,若运行中各低优先级进程的当前内存占用量分别为80M、 100M、120M、150M、280M和300M,则满足待主动回收内存需求的 进程组合可为:120M+150M;80M+100M+120M;280M;300M。此 时,可基于各进程的优先级顺序,选择较低优先级的进程或进程组合, 形成进程列表。例如,若80M+100M+120M对应的进程的优先级整体 低于300M对应的进程的优先级,且均低于280M对应的进程的优先级, 低于120M+150M对应的进程的优先级,则确定由80M+100M+120M 的进程组合形成进程列表。
需要说明的是,进程列表中的进程数量可为一个(为进程列表的 特殊形式,此时也可简称为进程)、两个或更多个,根据内存管理方法 中的待主动回收内存需求确定,本公开实施例对此不限定。同时,进 程与进程组合的优先级对比可基于本领域技术人员公知的方式实现, 本公开实施例对此不赘述也不限定。
S1443、关闭进程列表中的进程,释放内存。
该步骤中,将进程列表中的进程关闭,释放其占用的内存,以满 足待主动回收内存需求。
至此,完成S144。
该方法的其他前述步骤可参照上文中的解释说明进行理解,在此 不赘述。
需要说明的是,本实施例中的上述内存相关数值举例,均为示例 性地说明,并不构成对本实施例提供的内存管理方法的限定。
在一些实施例中,若当前内存分配速度可以满足内存申请需求, 则不需要进行内存主动回收步骤。示例性地,若单位时间内的所述当 前内存申请量小于或等于所述单位时间申请量阈值,或者单次所述当 前内存申请量小于或等于所述单次申请量阈值,则确定不进行内存主 动回收步骤。此时,采用传统的被动回收方式结合当前空闲内存,即 可满足内存申请需求。
在一些实施例中,进行内存主动回收步骤的结果除包括确定进行 内存主动回收,即触发内存主动回收之外;还可包括满足一定条件, 则不触发内存主动回收。示例性地,进行内存主动回收步骤还可包括: 若当前内存空闲量满足:L>α*A,或者L>β*M,则不触发内存主动回 收。此时,仍可采用传统的被动回收方式结合当前空闲内存,即可满 足内存申请需求。
如此设置,可在当前内存空闲量较大,且大于内存被动回收时, 不触发内存主动回收,从而确保当前系统运行不受影响,其稳定性、 安全性和其他性能保持良好。
本公开实施例提供的内存管理方法,可基于内存分配接口获取的 内存申请参数进行统计,得到当前内存申请量,并基于此尝试进行内 存主动回收,以及确定在执行内存主动回收时,获取至少一个进程的 当前内存占用量和当前内存空闲量;其后,基于当前内存申请量、当 前内存空闲量及运行中进程的当前内存占用量,确定需要关闭的进程 或包括两个以上进程的进程列表,以使内存回收后的内存空闲量等于 或大于当前内存申请量,即实现内存主动回收。由此,该内存管理方 法可基于当前内存申请量、当前内存占用量以及当前内存空闲量,确 定需要关闭的正在运行中的至少一个进程,实现内存主动回收,从而 可在确保较高的内存利用率的同时,提高内存分配效率。进一步地, 可结合内存主动回收与内从被动回收的方式,在提高内存分配效率的 同时,确保系统性能保持良好。
在上述实施方式的基础上,本公开实施例还提供了一种内存管理 装置,该内存管理装置可执行上述实施方式中的任一种内存管理方法。 因此,该装置也具有上述实施方式中的任一种方法所具有的有益效果, 相同之处可参照上文中对方法的解释说明进行理解,下文中不再赘述。
示例性地,图7为本公开实施例的一种内存管理装置的结构示意 图。参照图7,该装置包括:第一获取模块310,用于获取当前内存申 请量;主动回收步骤确定模块320,用于基于当前内存申请量,确定进 行内存主动回收步骤;第二获取模块330,用于获取至少一个进程的当 前内存占用量和当前内存空闲量;内存回收模块340,用于基于当前内 存申请量、当前内存空闲量及运行中进程的当前内存占用量,确定需 要关闭的进程,以使内存回收后的内存空闲量等于或大于当前内存申 请量。
本公开实施例提供的内存管理装置中,第一获取模块310可获取 当前内存申请量;主动回收步骤确定模块320可基于当前内存申请量, 确定进行内存主动回收步骤;第二获取模块330可在需要进行内存主 动回收时,获取至少一个进程的当前内存占用量和当前内存空闲量; 内存回收模块340可基于当前内存申请量、当前内存空闲量及运行中 进程的当前内存占用量,确定需要关闭的进程,以使内存回收后的内 存空闲量等于或大于当前内存申请量,从而可满足当前内存申请需求。 同时,基于上述参数主动确定需要结束的进程,单次内存释放之后即 可满足当前内存申请需求,如此内存回收效率较高,从而内存分配速度较快,如此兼顾了内存使用效率和内存分配速度。
在一些实施例中,图8为本公开实施例的另一种内存管理装置的 结构示意图,在图7的基础上,参照图8,第一获取模块310包括:内 存申请参数获取子模块311,用于基于内存分配接口,获取当前内存申 请参数;内存申请量确定子模块312,用于统计各内存分配接口的当前 内存申请参数,得到当前内存申请量。
如此设置,可利用内存分配接口监测到的各内存申请参数进行内 存流量统计,得到当前内存申请量,实现方式较简单。
在一些实施例中,继续参照图8,主动回收步骤确定模块320包括: 第一阈值获取子模块321,用于获取单位时间申请量阈值;第二阈值获 取子模块322,用于获取单次申请量阈值;回收确定子模块323,用于 若单位时间内的当前内存申请量大于单位时间申请量阈值,则确定进 行内存主动回收步骤,或者若单次当前内存申请量大于单次申请量阈 值,则确定进行内存主动回收步骤。
其中,单位时间申请量阈值和单次申请量阈值均为表征内存的分 配速度快慢的参考值。如此设置,可基于内存分配快慢确定当前内存 申请量能否被满足,并在内存分配过快时,确定需要触发内存主动回 收。
在一些实施例中,图9为本公开实施例的又一种内存管理装置的 结构示意图。在图7的基础上,参照图9,内存回收模块340包括:待 回收内存量确定子模块341,用于基于当前内存申请量和当前内存空闲 量,确定待回收内存量;待主动回收内存量确定子模块342,用于基于 待回收内存量和单位时间申请量阈值,或者基于待回收内存量和单次 申请量阈值,确定待主动回收内存量;进程确定子模块343,用于基于 待主动回收内存量和运行中进程的当前内存占用量,确定需要关闭的 至少一个进程;内存回收子模块344,用于关闭至少一个进程,以进行 内存回收。
如此设置,可基于当前内存申请量、当前内存空闲量和单位时间 申请量阈值(或单次申请量阈值),确定待主动回收内存量,并对应确 定需要关闭的至少一个进程,从而内存主动回收的可控性较好。
在一些实施例中,待主动回收内存量确定子模块342具体用于: 对应地,采用R=L1-α*A或R=L1-β*M计算待主动回收内存量R;其 中,L1代表待回收内存量,L1=L0-L,L0代表当前内存申请量,L代 表当前内存空闲量;M代表所述单位时间申请量阈值,A代表所述单次申请量阈值;α和β是被动回收速率系数,代表被动回收的效率。
如此设置,可利用单位时间申请量阈值和单次申请量阈值,结合上 述计算公式计算可得到待主动回收内存量,可实现内存被动回收与内 存主动回收相结合的内存回收方式。
在一些实施例中,继续参照图9,内存回收子模块344包括:当前 内存统计单元3441,用于统计各个业务低优先级进程的当前内存占用 量;进程列表确定单元3442,用于基于待主动回收内存量和各低优先 级进程的当前内存占用量,确定进程列表;其中,进程列表中的各进 程的当前内存占用量之和等于或者大于待主动回收内存量;内存释放 单元3443,用于关闭进程列表中的进程,释放内存。
如此设置,可确定优先级较低的进程为优先关闭的进程,基于待 主动回收内存需求,确定一个或多个可关闭的低优先级进程,形成进 程列表,有利于在降低对系统性能的影响同时,提高内存分配效率。
在一些实施例中,该装置还包括:主动回收步骤不触发模块(图 中未示出),用于若单位时间内的所述当前内存申请量小于或等于所述 单位时间申请量阈值,或者单次所述当前内存申请量小于或等于所述 单次申请量阈值,则确定不进行内存主动回收步骤。
此时,可仅利用内存被动回收方式实现内存回收,以满足当前内 存申请需求。
在一些实施例中,该装置还包括:主动内存回收不触发模块(图 中未示出),用于若当前内存空闲量满足:L>α*A,或者L>β*M,则不 触发内存主动回收。
此时,仍可仅利用内存被动回收方式实现内存回收,以满足当前 内存申请需求。
在上述实施方式的基础上,本公开实施例还提供了一种车载设备, 该车载设备可包括处理器和存储器;处理器通过调用存储器存储的程 序或指令,用于执行本公开实施例的上述任一种方法的步骤。因此, 该车载设备也具有上述实施例中的任一种方法和装置所具有的有益效 果,相同之处可参照上文中对方法和装置的解释说明进行理解,在此 不赘述。
示例性地,车载设备可为整车控制器、驱动系统控制器、影音系 统控制器、辅助驾驶系统控制器或车辆中的其他可执行软件程序的装 置设备或组成构件,本公开实施例对此不限定。
在一些实施例中,图10为本公开实施例的一种车载系统的结构示 意图。参照图10,该车载系统可包括:存储器401,一个或多个处理 器402(图10中以一个处理器402为例);该车载系统还可以包括:输 入装置403和输出装置404。
其中,该车载系统中的处理器401、存储器402、输入装置403和 输出装置404可以通过总线或者其他方式连接,图10中示例性地以通 过总线连接为例示出其连接方式。
其中,存储器402可为一种非暂态计算机可读存储介质,可用于 存储软件程序、计算机可执行程序以及模块,如本公开实施例中的提 高内存分配速度的内存管理方法对应的程序指令/模块(例如,附图7 所示的第一获取模块310、主动回收步骤确定模块320、第二获取模块 330以及内存回收模块340)。处理器401通过运行存储在存储器402 中的软件程序、指令以及模块,从而执行服务器的各种功能应用以及 数据处理,即实现上述方法实施例的内存管理方法。
存储器402可以包括存储程序区和存储数据区,其中,存储程序 区可存储操作系统、至少一个功能所需要的应用程序;存储数据区可 存储根据电子设备的使用所创建的数据等。
此外,存储器402可以包括高速随机存取存储器,还可以包括非 暂态性存储器,例如至少一个磁盘存储器件、闪存器件、或其他非暂 态性固态存储器件。
在一些实施例中,存储器402可选包括相对于处理器401远程设 置的存储器,这些远程存储器可以通过网络连接至终端设备。上述网 络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及 其组合。输入装置403可用于接收输入的数字或字符信息,以及产生 与电子设备的用户设置以及功能控制有关的键信号输入。输出装置404 可包括显示屏等显示设备。
本实施例中,通过对车载系统当前剩余内存的统计和监控,以及 对当前内存申请量的大小判断,在没有增加整体内存的前提下,有效 地改进了较大内存的申请速度,兼顾了系统性能和内存使用效率。
在上述实施方式的基础上,本公开实施例还提供了一种车辆,该 车辆包括本公开实施例的车载系统,车载系统中的处理器可通过调用 存储器存储的程序或指令,以执行本公开实施例的上述任一种方法的 步骤。因此,该车辆中的车载系统内存回收速度较快,内存分配速度 较快,从而车载系统对用户或外界指令的响应速度较快,智能车辆的 车载系统运行更为顺畅,有利于提高用户体验。
需要说明的是,在本文中,诸如“第一”和“第二”等之类的关 系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来, 而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系 或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵 盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或 者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或 者是还包括为这种过程、方法、物品或者设备所固有的要素。
以上仅是本公开的具体实施方式,使本领域技术人员能够理解或 实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是 显而易见的,本文中所定义的一般原理可以在不脱离本公开的精神或 范围的情况下,在其它实施例中实现。因此,本公开将不会被限制于 本文的这些实施例,而是要符合与本文所公开的原理和新颖特点相一 致的最宽的范围。

Claims (15)

1.一种内存管理方法,其特征在于,包括:
获取当前内存申请量;
基于所述当前内存申请量,确定进行内存主动回收步骤;
其中,所述内存主动回收步骤包括:
获取至少一个进程的当前内存占用量和当前内存空闲量;
基于所述当前内存申请量、所述当前内存空闲量及运行中进程的所述当前内存占用量,确定需要关闭的进程,以使内存回收后的内存空闲量等于或大于所述当前内存申请量。
2.根据权利要求1所述的方法,其特征在于,所述获取当前内存申请量包括:
基于内存分配接口,获取当前内存申请参数;
统计各所述内存分配接口的所述当前内存申请参数,得到所述当前内存申请量。
3.根据权利要求1所述的方法,其特征在于,所述基于所述当前内存申请量,确定进行内存主动回收步骤包括:
获取单位时间申请量阈值;
若单位时间内的所述当前内存申请量大于所述单位时间申请量阈值,则确定进行内存主动回收步骤;或者
获取单次申请量阈值;
若单次所述当前内存申请量大于所述单次申请量阈值,则确定进行内存主动回收步骤。
4.根据权利要求3所述的方法,其特征在于,所述基于所述当前内存申请量、所述当前内存空闲量及运行中进程的所述当前内存占用量,确定需要关闭的进程,以使内存回收后的内存空闲量等于或大于所述当前内存申请量包括:
基于所述当前内存申请量和所述当前内存空闲量,确定待回收内存量;
基于所述待回收内存量和所述单位时间申请量阈值,确定待主动回收内存量;或者,基于所述待回收内存量和所述单次申请量阈值,确定待主动回收内存量;
基于所述待主动回收内存量和运行中进程的所述当前内存占用量,确定需要关闭的进程;
关闭所述进程。
5.根据权利要求4所述的方法,其特征在于,所述基于所述待回收内存量和所述单位时间申请量阈值,确定待主动回收内存量包括:
采用R=L1-β*M计算所述待主动回收内存量R;
所述基于所述待回收内存量和所述单次申请量阈值,确定待主动回收内存量包括:
采用R=L1-α*A计算所述待主动回收内存量R;
其中,L1代表待回收内存量,L1=L0-L,L0代表当前内存申请量,L代表当前内存空闲量;M代表所述单位时间申请量阈值,A代表所述单次申请量阈值;α和β代表被动回收速率系数。
6.根据权利要求4所述的方法,其特征在于,所述关闭所述进程,包括:
统计各个业务低优先级进程的当前内存占用量;
基于所述待主动回收内存量和各低优先级进程的所述当前内存占用量,确定进程列表;其中,所述进程列表中的各进程的当前内存占用量之和等于或者大于所述待主动回收内存量;
关闭所述进程列表中的进程,释放内存。
7.根据权利要求1所述的方法,其特征在于,还包括:
获取单位时间申请量阈值;
若单位时间内的所述当前内存申请量小于或等于所述单位时间申请量阈值,则确定不进行内存主动回收步骤;或者
获取单次申请量阈值;
若单次所述当前内存申请量小于或等于所述单次申请量阈值,则确定不进行内存主动回收步骤。
8.一种内存管理装置,其特征在于,包括:
第一获取模块,用于获取当前内存申请量;
主动回收步骤确定模块,用于基于所述当前内存申请量,确定进行内存主动回收步骤;
第二获取模块,用于获取至少一个进程的当前内存占用量和当前内存空闲量;
内存回收模块,用于基于所述当前内存申请量、所述当前内存空闲量及运行中进程的所述当前内存占用量,确定需要关闭的进程,以使内存回收后的内存空闲量等于或大于所述当前内存申请量。
9.根据权利要求8所述的装置,其特征在于,所述主动回收步骤确定模块包括:
第一阈值获取子模块,用于获取单位时间申请量阈值;
第二阈值获取子模块,用于获取单次申请量阈值;
回收确定子模块,用于若单位时间内的所述当前内存申请量大于所述单位时间申请量阈值,则确定进行内存主动回收步骤,和/或若单次所述当前内存申请量大于所述单次申请量阈值,则确定进行内存主动回收步骤。
10.根据权利要求9所述的装置,其特征在于,所述内存回收模块包括:
待回收内存量确定子模块,用于基于所述当前内存申请量和所述当前内存空闲量,确定待回收内存量;
待主动回收内存量确定子模块,用于基于所述待回收内存量和所述单位时间申请量阈值,或者基于所述待回收内存量和所述单次申请量阈值,确定待主动回收内存量;
进程确定子模块,用于基于所述待主动回收内存量和运行中进程的所述当前内存占用量,确定需要关闭的进程;
内存回收子模块,用于关闭所述进程。
11.根据权利要求10所述的装置,其特征在于,所述待主动回收内存量确定子模块具体用于:
对应地,采用R=L1-α*A或R=L1-β*M计算所述待主动回收内存量R;
其中,L1代表待回收内存量,L1=L0-L,L0代表当前内存申请量,L代表当前内存空闲量;M代表所述单位时间申请量阈值,A代表所述单次申请量阈值;α和β代表被动回收速率系数。
12.根据权利要求10所述的装置,其特征在于,所述内存回收子模块包括:
当前内存统计单元,用于统计各个业务低优先级进程的当前内存占用量;
进程列表确定单元,用于基于所述待主动回收内存量和各低优先级进程的所述当前内存占用量,确定进程列表;其中,所述进程列表中的各进程的当前内存占用量之和等于或者大于所述待主动回收内存量;
内存释放单元,用于关闭所述进程列表中的进程,释放内存。
13.根据权利要求8所述的装置,其特征在于,所述第一获取模块包括:
内存申请参数获取子模块,用于基于内存分配接口,获取当前内存申请参数;
内存申请量确定子模块,用于统计各所述内存分配接口的所述当前内存申请参数,得到所述当前内存申请量。
14.一种车载系统,其特征在于,包括:
处理器和存储器;
所述处理器通过调用所述存储器存储的程序或指令,用于执行如权利要求1-7任一项所述方法的步骤。
15.一种车辆,其特征在于,包括权利要求14所述的车载系统。
CN202011181259.2A 2020-10-29 2020-10-29 内存管理方法、装置、车载系统以及车辆 Pending CN112463358A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011181259.2A CN112463358A (zh) 2020-10-29 2020-10-29 内存管理方法、装置、车载系统以及车辆

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011181259.2A CN112463358A (zh) 2020-10-29 2020-10-29 内存管理方法、装置、车载系统以及车辆

Publications (1)

Publication Number Publication Date
CN112463358A true CN112463358A (zh) 2021-03-09

Family

ID=74834623

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011181259.2A Pending CN112463358A (zh) 2020-10-29 2020-10-29 内存管理方法、装置、车载系统以及车辆

Country Status (1)

Country Link
CN (1) CN112463358A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116166573A (zh) * 2023-04-26 2023-05-26 荣耀终端有限公司 控制内存回收的方法、电子设备及存储介质
CN116775506A (zh) * 2023-08-22 2023-09-19 腾讯科技(深圳)有限公司 内存回收方法、装置、设备和介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106294059A (zh) * 2015-06-26 2017-01-04 中兴通讯股份有限公司 网管系统中进程的恢复方法及装置
CN106681933A (zh) * 2016-11-16 2017-05-17 深圳市金立通信设备有限公司 一种内存管理方法及终端
CN110083450A (zh) * 2019-04-09 2019-08-02 Oppo广东移动通信有限公司 内存回收方法、装置、电子设备及存储介质
CN111158910A (zh) * 2019-12-27 2020-05-15 Oppo广东移动通信有限公司 内存管理方法、装置、存储介质及电子设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106294059A (zh) * 2015-06-26 2017-01-04 中兴通讯股份有限公司 网管系统中进程的恢复方法及装置
CN106681933A (zh) * 2016-11-16 2017-05-17 深圳市金立通信设备有限公司 一种内存管理方法及终端
CN110083450A (zh) * 2019-04-09 2019-08-02 Oppo广东移动通信有限公司 内存回收方法、装置、电子设备及存储介质
CN111158910A (zh) * 2019-12-27 2020-05-15 Oppo广东移动通信有限公司 内存管理方法、装置、存储介质及电子设备

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116166573A (zh) * 2023-04-26 2023-05-26 荣耀终端有限公司 控制内存回收的方法、电子设备及存储介质
CN116166573B (zh) * 2023-04-26 2023-09-08 荣耀终端有限公司 控制内存回收的方法、电子设备及存储介质
CN116775506A (zh) * 2023-08-22 2023-09-19 腾讯科技(深圳)有限公司 内存回收方法、装置、设备和介质
CN116775506B (zh) * 2023-08-22 2023-12-05 腾讯科技(深圳)有限公司 内存回收方法、装置、设备和介质

Similar Documents

Publication Publication Date Title
CN112463358A (zh) 内存管理方法、装置、车载系统以及车辆
CN110858843B (zh) 业务请求处理方法、装置及计算机可读存储介质
CN112905342B (zh) 资源调度方法、装置、设备及计算机可读存储介质
CN110532197A (zh) 内存回收方法及装置、电子设备、存储介质
CN112214313A (zh) 内存分配方法及相关设备
CN114189482A (zh) 一种集群资源的控制方法、装置和系统
CN113364697A (zh) 流量控制方法、装置、设备及计算机可读存储介质
CN113361913A (zh) 一种通信业务编排方法、装置、计算机设备及存储介质
CN114385370B (zh) 内存分配方法、系统、设备及介质
CN113254220A (zh) 网联汽车负载协同控制方法、装置、设备及存储介质
CN107168333A (zh) 一种机器人的管理方法及服务器
US20230273833A1 (en) Resource scheduling method, electronic device, and storage medium
CN107809497B (zh) 号码资源池管理方法和系统
CN117032977A (zh) 混部应用资源分配方法、装置、计算机设备及存储介质
CN113212333B (zh) 一种域控制器及车辆
CN102811154B (zh) 资源获取方法与网络服务器系统
CN116450328A (zh) 内存分配方法、装置、计算机设备和存储介质
CN112162864A (zh) 一种云资源分配方法、装置及存储介质
CN112363828A (zh) 内存碎片管理方法、装置、车载系统及车辆
CN110222016B (zh) 一种文件处理方法及装置
CN116010019A (zh) 一种内存资源的分配方法、相关装置及设备
CN110704489A (zh) 一种数据库的查询方法、装置、设备及计算机存储介质
CN113608896B (zh) 一种动态切换数据流的方法、系统、介质及终端
CN117284252B (zh) 车辆自适应制动方法、装置、电子设备及存储介质
CN117519988B (zh) 一种基于raid的内存池动态调配方法、装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination