CN116303117A - 内存回收方法、设备、存储介质和系统 - Google Patents

Abstract

本发明提供一种内存回收方法、设备、存储介质和系统，该方法包括：回收线程响应于在第一时刻对目标内存空间触发的回收请求，对回收线程此时对应的第一版本号进行递增更新以得到第二版本号，确定第二版本号作为目标内存空间对应的版本号；响应于在第二时刻至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号；若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间满足回收条件，则对目标内存空间进行回收处理。本方案可以降低回收内存时的性能开销。

Description

内存回收方法、设备、存储介质和系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种内存回收方法、设备、存储介质和系统。

背景技术

在诸如手机、笔记本电脑、服务器等电子设备中，一个应用程序被启动时会启动相应的进程，进程会申请自己独立的一块或多块内存空间，而且，进程可以启动多个线程(称为应用线程)来执行应用程序运行过程中所需执行的各个任务。在任务执行过程中，会存在多个线程访问同一块内存空间的情形。当这块内存空间不再被访问的时候，可以回收这块内存空间，以提高内存的利用率。

针对上述多个应用线程访问同一内存空间的情况，一般会采用智能指针维护内存空间的生命周期。具体实施时，每个应用线程每次访问该内存空间时，都需要对智能指针进行构建操作和析构操作，举例来说，在某个应用线程访问该内存空间时，先构造指向该内存空间的智能指针，并对智能指针中的原子计数器的数值执行加一操作，在访问内存空间完毕后，析构该智能指针，以对原子计数器的数值执行减一操作。其中，多个应用线程共用该原子计数器，待原子计数器减为零时，即可对该内存空间进行回收处理。而在此过程中，为了保证多个应用线程间的原子性需要使用原子操作，原子操作以及不断地构建、析构智能指针，性能消耗较大。

发明内容

本发明实施例提供一种内存回收方法、设备、存储介质和系统，用于降低回收内存时的性能开销。

第一方面，本发明实施例提供一种内存回收方法，应用于对至少一个应用线程共同访问的目标内存空间进行回收的回收线程，所述方法包括：

响应于在第一时刻对所述目标内存空间触发的回收请求，对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号；

确定所述第二版本号作为所述目标内存空间对应的版本号；

响应于在第二时刻所述至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将所述回收线程此时对应的第三版本号发送至所述目标应用线程作为所述目标应用线程此时对应的版本号，所述目标应用线程是所述至少一个应用线程中任一个；

若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，确定所述目标内存空间满足回收条件，则对所述目标内存空间进行回收处理。

第二方面，本发明实施例提供一种内存回收装置，应用于对至少一个应用线程共同访问的目标内存空间进行回收的回收线程，所述装置包括：

确定模块，用于响应于在第一时刻对所述目标内存空间触发的回收请求，对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号；以及，确定所述第二版本号作为所述目标内存空间对应的版本号；

发送模块，用于响应于在第二时刻所述至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将所述回收线程此时对应的第三版本号发送至所述目标应用线程作为所述目标应用线程此时对应的版本号，所述目标应用线程是所述至少一个应用线程中任一个；

回收模块，用于若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，确定所述目标内存空间满足回收条件，则对所述目标内存空间进行回收处理。

第三方面，本发明实施例提供一种电子设备，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如第一方面所述的内存回收方法。

第四方面，本发明实施例提供一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如第一方面所述的内存回收方法。

第五方面，本发明实施例提供一种内存回收方法，应用于共同访问目标内存空间的至少一个应用线程中的目标应用线程，所述方法包括：

在第一时刻向回收线程触发对所述目标内存空间的回收请求，以使所述回收线程对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号，并确定所述第二版本号作为所述目标内存空间对应的版本号，所述回收线程与所述至少一个应用线程对应；

在第二时刻执行完任务后向所述回收线程发送版本号获取请求，以使所述回收线程将此时对应的第三版本号发送至所述目标应用线程作为所述目标应用线程此时对应的版本号，所述目标应用线程是所述至少一个应用线程中任一个；其中，所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，用于使得所述回收线程在确定所述目标内存空间满足回收条件时对所述目标内存空间进行回收处理。

第六方面，本发明实施例提供一种内存回收装置，应用于共同访问目标内存空间的至少一个应用线程中的目标应用线程，所述装置包括：

发送模块，用于在第一时刻向回收线程触发对所述目标内存空间的回收请求，以使所述回收线程对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号，并确定所述第二版本号作为所述目标内存空间对应的版本号，所述回收线程与所述至少一个应用线程对应；

所述发送模块，还用于在第二时刻执行完任务后向所述回收线程发送版本号获取请求，以使所述回收线程将此时对应的第三版本号发送至所述目标应用线程作为所述目标应用线程此时对应的版本号，所述目标应用线程是所述至少一个应用线程中任一个；

确定模块，用于确定所述第三版本号作为所述目标应用线程此时对应的版本号；

其中，所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，用于使得所述回收线程在确定所述目标内存空间满足回收条件时对所述目标内存空间进行回收处理。

第七方面，本发明实施例提供一种电子设备，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如第五方面所述的内存回收方法。

第八方面，本发明实施例提供一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如第五方面所述的内存回收方法。

第九方面，本发明实施例提供一种内存回收系统，所述内存回收系统包括：共同访问目标内存空间的至少一个应用线程，以及与所述至少一个应用程序对应的回收线程；

所述至少一个应用线程中第一应用线程，用于在第一时刻向所述回收线程触发对所述目标内存空间的回收请求；

所述至少一个应用线程中第二应用线程，用于在第二时刻执行完任务后向所述回收线程发送版本号获取请求，所述第二应用线程是所述至少一个应用线程中任一个；

所述回收线程，用于响应于所述回收请求，对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号，并确定所述第二版本号作为所述目标内存空间对应的版本号；响应于所述版本号获取请求，将此时对应的第三版本号发送至所述第二应用线程作为所述第二应用线程此时对应的版本号；以及，若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号确定所述目标内存空间满足回收条件，则对所述目标内存空间进行回收处理。

在本发明实施例提供的方案中,设置与共同访问目标内存空间的至少一个应用线程相对应的一个回收线程，当其中某个应用线程在第一时刻确定需要回收目标内存空间时，向回收线程触发对目标内存空间的回收请求。回收线程维护有单调递增的主版本号，当接收到该回收请求时，假设此时的主版本号为第一版本号，对第一版本号进行递增更新以得到第二版本号，可以确定第二版本号作为目标内存空间对应的版本号。目标内存空间对应的第二版本号，实际上可以作为一个时序排序的依据，可以反映出是什么时候对该目标内存空间触发回收请求的。

另外，上述至少一个应用线程中任一应用线程每当执行完一个任务后，就向回收线程发一个版本号获取请求，以请求得到回收线程此时的主版本号，并以获得的主版本号给自己的版本号进行赋值。比如，在第二时刻目标应用线程执行完任务以向回收线程触发版本号获取请求，假设回收线程此时对应的主版本号为第三版本号，则将第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号。如果回收线程某时刻根据上述至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号确定目标内存空间满足回收条件，则对目标内存空间开始进行回收处理，其中，满足该回收条件说明在开始回收目标内存空间时上述各应用线程没有在访问目标内存空间。

由此可见，在上述方案中，在目标内存空间等待回收期间不影响应用线程对其的正常访问，是否开始回收该目标内存空间，仅依赖于应用线程以及目标内存空间各自对应的版本号的赋值和比较，这些操作不需要加锁，性能开销很小。而且，内存回收处理过程相对较慢，由额外的回收线程来完成内存回收处理过程，避免在应用线程中执行内存回收处理过程，可以降低应用线程的负担，提升应用线程的应用任务处理速度。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种内存回收系统的结构示意图；

图2为本发明实施例提供的一种内存回收方法的流程图；

图3为本发明实施例提供的一种内存回收方法的应用示意图；

图4为本发明实施例提供的一种内存回收方法的流程图；

图5为本发明实施例提供的一种内存回收方法的应用示意图；

图6为本发明实施例提供的一种内存回收方法的流程图；

图7为本发明实施例提供的另一种内存回收方法的流程图；

图8为本发明实施例提供的一种内存回收装置的示意图；

图9为本发明实施例提供的另一种内存回收装置的示意图；

图10为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。另外，下述各方法实施例中的步骤时序仅为一种举例，而非严格限定。

需要说明的是，本发明实施例中所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

下面对本发明实施例中涉及的名词进行说明：

进程：是并发执行的程序在执行过程中分配和管理资源的基本单位，简单来说，进程是指在系统中正在运行的一个应用程序。

线程：是进程中的一个执行单元，它被包含在进程之中，一个进程中可以并发启动多个线程。本发明实施例中，为了区别两种不同的线程，分别命名为应用线程和回收线程，其中，应用线程是指进程启动的用于执行上述应用程序的线程，回收线程是指用于进行内存回收的线程。

版本号：本发明实施例中，涉及到回收线程对应的版本号，应用线程对应的版本号，内存空间对应的版本号这三种版本号，其中，回收线程维护单调递增的版本号，而且应用线程和内存空间对应的版本号源自于回收线程的版本号的赋值，因此将回收线程维护的版本号称为主版本号。

在实际应用中，同一个进程中的各应用线程对应于同一应用程序，各应用线程可以用于执行不同任务。举例来说，一个应用线程创建了一个通信连接，其他应用线程可以使用该通信连接传输数据。

当某个应用程序对应的进程被启动时，该进程会申请自己独立的一块或多块内存空间，进程中的各个应用线程在执行任务过程中会访问这些内存空间。针对其中任一内存空间，在本发明实施例中，为了降低内存回收时的性能开销，在该进程中引入一个额外的回收线程来专门负责该进程所申请的内存空间的回收，避免在应用线程中执行内存回收处理过程，可以降低应用线程的负担，提升应用线程的应用任务处理速度。概括来说，回收线程负责保证在开始回收某内存空间时，已经没有应用线程再访问(即读写)这块内存空间了，以确保可以安全地释放这块内存空间。因为如果在某应用线程正在访问这块内存空间时进行回收处理，那么该访问将会失败，会产生错误。

为了降低内存回收所产生的性能开销，本发明实施例中，回收线程本地会维护单调递增的主版本号，并且会通过该主版本号给应用线程的版本号以及待回收的目标内存空间的版本号进行赋值，以便通过比较应用线程的版本号以及目标内存空间的版本号的大小关系，确定目标内存空间的回收时机。这种版本号赋值、比较的操作，性能开销比较低。其中，版本号的赋值、比较等过程将结合以下实施例进行说明。

图1为本发明实施例提供的一种内存回收系统的结构示意图，如图1所示，该内存回收系统包括：共同访问目标内存空间的至少一个应用线程，以及与至少一个应用程序对应的回收线程。比如，在图1中，示意了应用线程1、应用线程2和应用线程3共同访问目标内存空间的情形。

如上文所述，这至少一个应用线程和回收线程可以位于同一进程中，该目标内存空间可以是该进程申请的多个内存空间中的任一个。

其中，多个应用线程共同访问目标内存空间，并非是指同时访问目标内存空间，而是在各自执行任务的过程中，存在都会访问该目标内存空间的可能性。

可以理解的是，各应用线程对目标内存空间的访问操作实际上就是读、写目标内存空间中存储的数据。

回收线程负责对上述目标内存空间进行回收处理，在开始回收之前，各应用线程可以正常访问目标内存空间，在开始回收之后，各应用线程将不能再访问该目标内存空间。

基于上述系统组成，下面具体说明目标内存空间的回收过程。

图2为本发明实施例提供的一种内存回收方法的流程图，该内存回收方法可以由图1中的回收线程来执行，如图2所示，该方法包括如下步骤：

201、响应于在第一时刻对目标内存空间触发的回收请求，对回收线程此时对应的第一版本号进行递增更新以得到第二版本号。

202、确定第二版本号作为目标内存空间对应的版本号。

203、响应于在第二时刻至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号，目标应用线程是至少一个应用线程中任一个。

204、若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间满足回收条件，则对目标内存空间进行回收处理。

在实际应用中，当至少一个应用线程中的某一应用线程在第一时刻确定需要回收目标内存空间时，会向回收线程触发对目标内存空间的回收请求，该回收请求中携带有目标内存空间对应的虚拟内存地址。

可以理解的是，进程在进行内存空间申请时，使用的内存地址一般是虚拟内存地址，而非物理内存地址，比如假设进程申请了虚拟内存地址为0-100，以及300-400这两块内存空间，当确定需要对0-100这个目标内存空间进行回收时，触发包含该虚拟内存地址的回收请求。

可选地，触发上述回收请求的应用线程可以是上述至少一个应用线程中任一个。需要说明的是，针对上述目标内存空间来说，不管是哪个应用线程触发的回收请求，仅触发一次。

或者，可选地，触发上述回收请求的应用线程可以是上述至少一个应用线程中具有触发回收请求权限的应用线程。可以应用线程之间预先通过某种协商机制确定出具有该权限的应用线程，也可以由进程指定具有该权限的应用线程。

为便于描述，不管是上述哪种情形，都假设至少一个应用线程中的第一应用线程在确定需要回收目标内存空间时，向回收线程触发了上述回收请求，其中，假设该回收请求触发的时刻为第一时刻。

其中，第一应用线程是怎样确定出需要回收目标内存空间的，本发明实施例中不作具体限定，比如在执行了某种会访问该目标内存空间的特定任务后确定回收目标内存空间。举例来说，假设应用线程1创建了一个通信连接，在目标内存空间中写入该通信连接的相关信息，应用线程2和应用线程3可以使用该通信连接传输数据，在传输数据时，从目标内存空间中读取通信连接的相关信息，比如第一应用线程为应用线程1，则应用线程1可以在断开该通信连接时，确定需要回收该目标内存空间，从而在此时(第一时刻)向回收线程触发了上述回收请求。

而回收线程在收到回收请求后，确定此时更新至的主版本号(假设为第一版本号)，并对第一版本号进行递增更新以得到第二版本号，并将该第二版本号作为目标内存空间对应的版本号，即将目标内存空间对应的版本号设置为第二版本号。

为便于理解，结合图3示例说明。如上文所述，回收线程负责本地维护的主版本号的更新，本质就是一个递增的序号，比如从0或1开始，每次更新的时候进行加一处理。举例来说，假设在第一时刻(图3中示意的T1)回收线程收到上述回收请求时，此时对应的第一版本号为10，则对其进行递增更新后得到的第二版本号为11(此时相当于对第一版本号进行了加一操作)，并将该第二版本号11作为目标内存空间对应的版本号，即将目标内存空间对应的版本号设置为11。如图3中所示，可选地，回收线程可以在内存中的设定存储空间中记录该目标内存空间与该第二版本号11的对应关系。实际上，目标内存空间对应的第二版本号，用于反映目标内存空间是何时被触发回收请求的。

对于上述至少一个应用线程，只要是对上述目标内存空间还没有开始进行回收处理，那么这至少一个应用线程都是可以正常访问该目标内存空间的，也就是说，在第一应用线程触发针对目标内存空间的回收请求之前，各应用线程可以正常访问目标内存空间，在第一应用线程触发针对目标内存空间的回收请求之后，只要还没有开始回收该目标内存空间，各应用线程还是可以正常访问目标内存空间。

基于此，本发明实施例中，上述至少一个应用线程中的任一应用线程(为便于描述，假设为目标应用线程)，不管是在上述回收请求触发之前还是之后，可以每当执行完一个任务后向回收线程触发版本号获取请求，以请求回收线程此时的主版本号。

结合图3中的示例，假设目标应用线程为应用线程1，在第二时刻(图中示意的T2)完成了某个任务的执行，向回收线程发送版本号获取请求，假设回收线程此时的主版本号为第三版本号，并假设取值为图中示意的11，则将第三版本号11发送给应用线程1，应用线程1将使用第三版本号11为自己的版本号赋值：V1＝11，其中，V1表示应用线程1对应的版本号。

需要说明的是，在图3中示意的是第二时刻T2不早于第一时刻T1的情形，因为回收线程是在T1时刻将主版本号更新为第二版本号11的，意味着在此之前回收线程的主版本号为小于11的第一版本号10，如果T2时刻早于T1时刻，那么应用线程1获取的主版本号将是第一版本号10。而且，图3中示意的是回收线程在T2时刻对应的主版本号(第三版本号)与T1时刻对应的更新后主版本号(第二版本号)一样的情形，即在接收到应用线程1在T2时刻触发的版本号获取请求之前，回收线程的主版本号为第二版本号，且并未再更新。

另外，结合图3中示例，可以理解的是，假设在T1时刻之后的其他一些时刻，上述至少一个应用线程中的各应用线程都接收到了需要执行的至少一个任务，那么在各个应用线程每次执行完一个任务后，都向回收线程触发版本号获取请求，如果回收线程当时的主版本号仍旧保持为第二版本号，即收到版本号获取请求时回收线程对应的第三版本号等于收到回收请求后更新至的第二版本号，则各应用线程的版本号赋值结果都是11。但是，如果假设在上述至少一个应用线程触发版本号获取请求之前，回收线程的主版本号已经由第二版本号更新到与第二版本号不同的第三版本号(比如从第二版本号11更新为第三版本号12)，那么此时各应用线程在发出版本号获取请求后得到的是第三版本号12。基于此，如图3中所示，假设T3时刻应用线程2发送版本号获取请求后收到的是第三版本号12，则此时应用线程2的版本号V2赋值为12，假设T4时刻应用线程3发送版本号获取请求后收到的是第三版本号12，则此时应用线程3的版本号V3赋值为12，其中，T3和T4时刻都不早于T2时刻。

另外，需要说明的是，如上文所述，上述至少一个应用线程属于同一进程，该进程申请的内存空间可以有多个，比如虚拟内存地址在0-100,300-400这两块内存空间，假设上述目标内存空间为0-100这块内存空间，实际应用中，至少一个应用线程在执行任务是访问的未必都是0-100这块内存空间，可能也会访问300-400这块内存空间。本实施例中，并不限定上述至少一个应用线程是在访问0-100这块内存空间执行完某个任务后才向回收线程发送上述版本号获取请求，而是不管所执行的任务访问的是这两个内存空间中的哪个都在完成任务后向回收线程发送上述版本号获取请求。

针对上述至少一个应用线程中任一应用线程来说，其在每次执行完一个任务之后，以自身角度来说，都不知道后续是否还有其他任务要执行，所以每次执行完任务之后可以认为后续不会再访问目标内存空间了，所以触发版本号获取请求，以请求得到的回收线程的主版本号赋值自己的版本号，用以表明该应用线程何时结束了对目标内存空间的访问。

针对上述目标内存空间来说，可选地，回收线程可以在收到回收请求之后，定期地判断是否应该开始回收该目标内存空间，如果某时刻确定可以开始回收该目标内存空间，则对目标内存空间开始进行回收处理，开始回收目标内存空间之后，上述至少一个应用线程都将不能再访问该目标内存空间了。

其中，假设回收线程在T5时刻执行一次判断过程，此时的判断过程是：根据所述至少一个应用线程各自对应的版本号和目标内存空间对应的所述第二版本号，确定目标内存空间是否满足回收条件，若满足，则对目标内存空间进行回收处理。简单来说就是比较此时目标内存空间所对应的版本号(基于上文中说明，其版本号为第二版本号)以及上述各应用线程此时对应的版本号，以确定是否在当前的T5时刻开始对目标内存空间进行回收。结合图3中示例的情况，目标内存空间对应的第二版本号为11，应用线程1对应的版本号为11，应用线程2和应用线程3对应的版本号为12，基于这些版本号赋值结果来确定T5时刻是否开始回收目标内存空间。

在本实施例中，假设T5时刻确定开始对目标内存空间进行回收处理，则对目标内存空间进行回收处理的过程可以这样理解：对于应用线程来说，访问内存空间使用的是虚拟内存地址，在操作系统内核中存储有虚拟内存地址与物理内存地址之间的映射关系，而对目标内存空间进行回收处理指的是：删除该目标内存空间对应的虚拟内存地址以及该虚拟内存地址与相应物理内存地址之间的映射关系，从而使得该虚拟内存地址对这些应用线程来说不可用。具体地，假设进程在启动的时候申请了多个内存空间，其对应的虚拟内存地址分别为0-100、200-300、500-600、800-900等，若其中0-100这段的虚拟内存地址对应的内存空间被回收处理了，则意味着后续这个进程中的上述各应用线程不能再访问这段内存空间了。

关于上述是否满足回收条件的判断，在一可选实施例中，若确定至少一个应用线程各自对应的版本号均大于目标内存空间对应的第二版本号，则确定开始对目标内存空间进行回收处理。

本实施例中，简单来说就是对目标内存空间对应的第二版本号以及判断时刻上述至少一个应用线程各自对应的版本号进行从小到大的排序，如果目标内存空间对应的第二版本号排在第一位置，意味着在对该目标内存空间触发回收请求之后，各个应用线程对目标内存空间的访问都已经结束了，即在回收目标内存空间前已经没有应用线程正在访问该目标内存空间了，此时可以开始对目标内存空间进行回收。

承接于图3中示例的情形，由于目标内存空间的第二版本号为11，判断时刻(T5时刻)应用线程1对应的版本号为11，应用线程2和应用线程3对应的版本号为12，由于其中应用线程1的版本号11不大于目标内存空间的第二版本号11，所以确定T5时刻还不能开始回收目标内存空间。由于此时还不能回收目标内存空间，所以这些应用线程如果再接收到需要访问目标内存空间的任务，还是可以正常访问目标内存空间以完成任务处理的。直至某时刻各应用线程对应的版本号均大于目标内存空间对应的第二版本号之后，才开始回收目标内存空间。

比如在之后的某时刻，应用线程1执行完某任务向回收线程触发版本号获取请求，并假设此时回收线程的主版本号已经从第二版本号11更新为13了，那么应用线程对应的版本号将被赋值为13，再一次判断时(假设为T6时刻)，由于目标内存空间对应的第二版本号11已经均小于各应用线程对应的版本号(应用线程1对应的版本号为13，应用线程2和应用线程3对应的版本号为12)，则回收线程确定T6时刻开始回收目标内存空间。

而在实际应用中，往往还会存在这样一种情况：至少一个应用线程中的某个应用线程在设定时长(如5s、10s等)内没有收到需要执行的任务，即该应用线程长时间地没有任务需要执行，将会进入休眠状态。从而，该应用线程对应的版本号会出现长时间不更新的情况，该情况下，实际上意味着该应用线程不再访问目标内存空间了。基于此，如果某应用线程在设定时长内没有收到需要处理的任务，可以将自身设置为不活跃状态并休眠。基于此，在另一可选实施例中，回收线程在判断时刻，可以获取至少一个应用线程各自对应的活跃状态信息；若根据活跃状态信息确定至少一个应用线程中存在处于不活跃状态的应用线程，则在根据除处于不活跃状态的应用线程外的其他应用线程各自对应的版本号和目标内存空间对应的第二版本号确定目标内存空间满足回收条件时，对目标内存空间进行回收处理。

具体实施时，各应用线程可以将反映其活跃状态的标志信息记录到内存中的设定存储空间中，比如标志位＝1，表示活跃，标志位＝0，表示不活跃。可以理解的是，如果某应用线程在将其对应的标志位设置为0之后，由于接收到任务而从休眠状态苏醒，可以将该标志位更新为1。

回收线程在判断时刻，从内存中上述设定存储空间中读取上述各应用线程的活跃状态后，可以筛选出处于活跃状态下的应用线程，根据这些活跃的应用线程各自对应的版本号和目标内存空间对应的第二版本号，判断是否满足回收条件，若满足，则对目标内存空间进行回收处理。此时的回收条件判断方法可参见上述实施例，即判断这些活跃的应用线程各自对应的版本号是否均大于目标内存空间对应的第二版本号，若均大于，则满足回收条件，否则，即不满足回收条件。

综上，在目标内存空间等待回收期间不影响应用线程对其的正常访问，是否开始回收该目标内存空间，仅依赖于应用线程以及目标内存空间各自对应的版本号的赋值和比较，这些操作不需要加锁，性能开销很小。而且，内存回收处理过程相对较慢，由额外的回收线程来完成内存回收处理过程，避免在应用线程中执行内存回收处理过程，可以降低应用线程的负担，提升应用线程的应用任务处理速度。

图4为本发明实施例提供的一种内存回收方法的流程图，如图4所示，该方法包括：

401、响应于在第一时刻对目标内存空间触发的回收请求，对回收线程此时对应的第一版本号进行递增更新以得到第二版本号。

402、确定第二版本号作为目标内存空间对应的版本号。

403、响应于在第二时刻至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号，目标应用线程是至少一个应用线程中任一个。

404、若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间不满足回收条件，则对回收线程对应的第三版本号进行递增更新以得到第四版本号。

405、响应于在第三时刻目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第四版本号发送至目标应用线程作为目标应用线程此时对应的版本号。

406、若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间满足回收条件，则对目标内存空间进行回收处理。

本实施例中主要是介绍回收线程在根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间不满足回收条件时的处理逻辑。

为了便于理解，结合图5来示例说明，假设能够访问目标内存空间的共有3个应用线程：应用线程1、应用线程2和应用线程3，假设应用线程1在T1时刻(第一时刻)向回收线程触发了目标内存空间的回收请求，假设此时回收线程的主版本号为第一版本号，具体为10，第一版本号加一得到第二版本号：11，记录目标内存空间与第二版本号之间的对应关系。

之后，假设在T2、T3和T4时刻(第二时刻)，这三个应用线程完成各自的任务后向回收线程发送版本号获取请求，由于此时回收线程的主版本号(第三版本号，假设与第二版本号相同)已经更新为11，所以这三个应用线程的版本号将都被赋值为11。

之后，回收线程根据这三个应用线程的版本号11与目标内存空间对应的第二版本号11确定不满足回收条件，则回收线程将第三版本号加一，得到第四版本号：12，也就是说，回收线程此时进行一次主版本号的更新。注意，目标内存空间对应的第二版本号不会更新。

回收线程此时的主版本号的更新将会影响后续应用线程请求得到的版本号。比如，在第二时刻之后的第三时刻，比如应用线程1在T5时刻执行完一个任务向回收线程请求版本号，此时回收线程反馈的是第四版本号：12，应用线程1的版本号赋值结果由此前的11更新为12。同理，应用线程2在T6时刻执行完一个任务向回收线程请求版本号，此时回收线程反馈的是第四版本号：12，应用线程2的版本号赋值结果由此前的11更新为12；应用线程3在T7时刻执行完一个任务向回收线程请求版本号，此时回收线程反馈的是第四版本号：12，应用线程3的版本号赋值结果由此前的11更新为12。

之后，回收线程再次判断时，由于此时上述三个应用线程的版本号12均大于目标内存空间对应的版本号11，因此满足回收条件，确定此时可以开始回收目标内存空间。

由上述举例可知，在某应用线程针对目标内存空间触发回收请求后，回收线程可能要经过多次判断才会发现在未来某个时刻可以回收该目标内存空间。

图6为本发明实施例提供的一种内存回收方法的流程图，该方法由回收线程执行，如图6所示，该方法包括：

601、响应于在第一时刻将目标内存空间的地址信息写入第一队列而触发的回收请求，从第一队列获取目标内存空间的地址信息，对回收线程此时对应的第一版本号进行递增更新以得到第二版本号，确定第二版本号作为目标内存空间对应的版本号。

602、响应于在第二时刻至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号，目标应用线程是至少一个应用线程中任一个。

603、若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间不满足回收条件，则将目标内存空间的地址信息写入第二队列，将目标内存空间的地址信息从第一队列中删除，对回收线程对应的第三版本号进行递增更新以得到第四版本号。

604、响应于在第三时刻目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第四版本号发送至目标应用线程作为目标应用线程此时对应的版本号。

605、若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间满足回收条件，则对目标内存空间进行回收处理。

本实施例中，引入回收线程维护的两个队列：第一队列和第二队列，用于标记目标内存空间的不同状态。

具体来说，如上文所述，假设至少一个应用线程中的第一应用线程在第一时刻向回收线程触发了目标内存空间的回收请求，具体地，第一应用线程可以将目标内存空间的地址信息(即虚拟内存地址)写入第一队列中，第一队列响应于新的目标内存空间的地址信息的写入事件，向回收线程触发对应的通知，这样回收线程基于该通知从第一队列中确定有目标内存空间写入第一队列中了，进而进行主版本号的更新操作。

由此可见，第一应用线程是通过向第一队列中写入目标内存空间的地址信息的方式向回收线程触发回收请求的。

前述实施例中举例的情形是回收线程在第二时刻收到上述至少一个应用线程中任一应用线程的版本号获取请求时，此时的主版本号与第一时刻更新后的主版本号相同，即第三版本号与第二版本号相同的情况。但是实际上，假设在收到该版本号获取请求之前，第一应用线程针对另一内存空间也发起了回收请求，那么回收线程的主版本号将从第二版本号更新为取值不同的第三版本号。比如上述至少一个应用线程为同一进程内的线程，该进程申请了多块内存空间，第一时刻针对其中的某内存空间触发了回收请求，在之后的另一时刻(第二时刻之前)针对另一内存空间触发了回收请求，每次回收请求都会促使回收线程的主版本号的更新。

在第二时刻接收到某目标应用线程发送的版本号获取请求后，假设此时回收线程的主版本号为第三版本号，将第三版本号发给该目标应用线程，以对其版本号进行赋值。

实际应用中，回收线程可以被配置为每当接收到一个回收请求，即接收到上述第一队列中存入目标内存空间的地址信息的通知，进行目标内存空间对应的版本号的赋值后，就进行目标内存空间是否满足回收条件的一次判断过程。

若判断结果为目标内存空间不满足回收条件，则执行一次回收线程的主版本号的更新，得到第四版本号，而且，将目标内存空间从第一队列中移出，写入第二队列中。第二队列中存储的内存空间是等待回收的内存空间。也就是说，如果目标内存空间添加到第一队列中之后，执行一次判断过程确定还不能回收目标内存空间，则将其移入到第二队列中等待回收，具体地，基于查询第二队列的设定策略，在后续对存入第二队列的目标内存空间再进行一次或多次判断后，在符合回收条件时，对其进行回收，回收后目标内存空间从第二队列中删除。

假设在进行下次判断之前，上述至少一个应用线程中的全部或部分在第三时刻向回收线程发送版本号获取请求，则此时回收线程将第四版本号发生给相应应用线程进行版本号的重新赋值。

再进行下一次判断时，假设回收线程确定目标内存空间满足回收条件，则确定开始对目标内存空间进行回收，回收完毕后可以将目标内存空间从第二队列中删除。

上文中介绍到，回收线程可以在每次收到回收请求的时候，执行一次针对第一队列和第二队列中已写入的内存空间是否满足回收条件的判断，除此之外，回收线程还可以在确定第二队列不为空且设定时长内没有接收到回收请求时，针对第二队列中包含的任一内存空间的地址信息，根据对应的各应用线程此时对应的版本号以及所述任一内存空间对应的版本号确定所述任一内存空间是否满足回收条件。

应理解，目标内存空间的虚拟内存地址在存入第一队列之后，一方面，会更新该目标内存空间对应的版本号，另一方面，会执行一次是否满足回收条件的判断，若判断结果为不满足回收条件，则将该目标内存空间的虚拟内存地址存入第二队列中等待后续再回收。那么，在收到下一个回收请求，或者确定第二队列不为空且设定时长内没有接收到回收请求时，就相当于是将回收线程唤醒了，回收线程会再进行一次是否满足回收条件的判断，若判断结果仍为不满足回收条件，则使其继续在第二队列中等待下次回收，反之，若满足回收条件，直接对其进行回收处理即可。如此循环，直至第二队列为空，而当第二队列为空时，回收线程会阻塞等待应用线程推送新的需要回收的内存空间。

综上所述，本发明实施例中，在目标内存空间等待回收期间不影响应用线程对其的正常访问，是否开始回收该目标内存空间，仅依赖于应用线程以及目标内存空间各自对应的版本号的赋值和比较，这些操作不需要加锁，性能开销很小。而且，内存回收处理过程相对较慢，由额外的回收线程来完成内存回收处理过程，避免在应用线程中执行内存回收处理过程，可以降低应用线程的负担，提升应用线程的应用任务处理速度。

图7为本发明实施例提供的另一种内存回收方法的流程图，该方法应用于共同访问目标内存空间的至少一个应用线程，如图7所示，该方法包括如下步骤：

701、在第一时刻向回收线程触发对目标内存空间的回收请求，以使回收线程对回收线程此时对应的第一版本号进行递增更新以得到第二版本号，并确定第二版本号作为目标内存空间对应的版本号，回收线程与至少一个应用线程对应。

702、在第二时刻执行完任务后向回收线程发送版本号获取请求，以使回收线程将此时对应的第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号，目标应用线程是至少一个应用线程中任一个，其中，至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，用于使得回收线程在确定目标内存空间满足回收条件时对目标内存空间进行回收处理。

如上文所述，触发回收请求的应用线程可以是至少一个应用线程中特定的某个应用线程，也可以是其中任一个应用线程。

如上文所述，该方法还包括：目标应用线程若在设定时长内没有收到需要执行的任务，则设置自身处于不活跃状态后休眠。所述不活跃状态使得回收线程根据除处于不活跃状态的应用线程外的其他应用线程各自对应的版本号和目标内存空间对应的第二版本号确定目标内存空间是否满足回收条件。

本实施例中对应用线程的执行过程不再展开赘述，可以参考前述其他实施例中的说明。

以下将详细描述本发明的一个或多个实施例的内存回收装置。本领域技术人员可以理解，这些装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图8为本发明实施例提供的一种内存回收装置的示意图，该装置应用于对至少一个应用线程共同访问的目标内存空间进行回收的回收线程，如图8所示，该装置包括：确定模块81、发送模块82和回收模块83。

确定模块81，用于响应于在第一时刻对目标内存空间触发的回收请求，对回收线程此时对应的第一版本号进行递增更新以得到第二版本号；以及，确定第二版本号作为目标内存空间对应的版本号。

发送模块82，用于响应于在第二时刻至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号，目标应用线程是至少一个应用线程中任一个。

回收模块83，用于若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间满足回收条件，则对目标内存空间进行回收处理。

可选地，回收模块83具体用于：若确定至少一个应用线程各自对应的版本号均大于目标内存空间对应的第二版本号，则对目标内存空间进行回收处理。

可选地，所述回收模块83具体用于：获取至少一个应用线程各自对应的活跃状态信息；若根据活跃状态信息确定至少一个应用线程中存在处于不活跃状态的应用线程，则在根据除处于不活跃状态的应用线程外的其他应用线程各自对应的版本号和目标内存空间对应的第二版本号确定目标内存空间满足回收条件时，对目标内存空间进行回收处理。

可选地，该装置还包括：更新模块，用于若根据至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，确定目标内存空间不满足回收条件，则对回收线程对应的第三版本号进行递增更新以得到第四版本号。

可选地，所述发送模块82，还用于响应于在第三时刻目标应用线程执行完任务后触发的版本号获取请求，将回收线程此时对应的第四版本号发送至目标应用线程作为目标应用线程此时对应的版本号。

可选地，所述确定模块81具体用于：响应于在第一时刻将目标内存空间的地址信息写入第一队列而触发的回收请求，从第一队列获取目标内存空间的地址信息，对回收线程此时对应的第一版本号进行递增更新以得到第二版本号，将目标内存空间的地址信息写入用于存储等待进行回收的内存空间的第二队列，将目标内存空间的地址信息从第一队列中删除。

可选地，所述回收模块83具体用于：在接收到回收请求，或者确定第二队列不为空且设定时长内没有接收到回收请求时，针对第二队列中包含的任一内存空间的地址信息，根据对应的各应用线程此时对应的版本号以及任一内存空间对应的版本号确定任一内存空间是否满足回收条件。

图8所示装置可以执行前述实施例中回收线程执行的步骤，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

图9为本发明实施例提供的另一种内存回收装置的示意图，该装置应用于共同访问目标内存空间的至少一个应用线程中的目标应用线程，如图9所示，该装置包括：发送模块91和模块92。

发送模块91，用于在第一时刻向回收线程触发对目标内存空间的回收请求，以使回收线程对回收线程此时对应的第一版本号进行递增更新以得到第二版本号，并确定第二版本号作为目标内存空间对应的版本号，回收线程与至少一个应用线程对应。

所述发送模块91，还用于在第二时刻执行完任务后向回收线程发送版本号获取请求，以使回收线程将此时对应的第三版本号发送至目标应用线程作为目标应用线程此时对应的版本号，目标应用线程是至少一个应用线程中任一个。

确定模块92，用于确定所述第三版本号作为所述目标应用线程此时对应的版本号；其中，至少一个应用线程各自对应的版本号和目标内存空间对应的第二版本号，用于使得回收线程在确定目标内存空间满足回收条件时对目标内存空间进行回收处理。

可选地，该装置还包括：设置模块，用于若在设定时长内没有收到需要执行的任务，则设置自身处于不活跃状态后休眠；不活跃状态使得回收线程根据除处于不活跃状态的应用线程外的其他应用线程各自对应的版本号和目标内存空间对应的第二版本号确定目标内存空间是否满足回收条件。

图9所示装置可以执行前述实施例中应用线程执行的步骤，详细的执行过程和技术效果参见前述实施例中的描述，在此不再赘述。

图10为本发明实施例提供的一种电子设备的结构示意图，如图10所示，该电子设备可以包括：处理器21、存储器22、通信接口23。其中，存储器22上存储有可执行代码，当所述可执行代码被处理器21执行时，使处理器21执行前述实施例中的内存回收方法。

另外，本发明实施例提供了一种非暂时性机器可读存储介质，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行前述实施例中的内存回收方法。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助加必需的通用硬件平台的方式来实现，当然也可以通过硬件和软件结合的方式来实现。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以计算机产品的形式体现出来，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (13)

1.一种内存回收方法，其特征在于，应用于对至少一个应用线程共同访问的目标内存空间进行回收的回收线程，所述方法包括：

响应于在第一时刻对所述目标内存空间触发的回收请求，对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号；

确定所述第二版本号作为所述目标内存空间对应的版本号；

响应于在第二时刻所述至少一个应用线程中目标应用线程执行完任务后触发的版本号获取请求，将所述回收线程此时对应的第三版本号发送至所述目标应用线程作为所述目标应用线程此时对应的版本号，所述目标应用线程是所述至少一个应用线程中任一个；

若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，确定所述目标内存空间满足回收条件，则对所述目标内存空间进行回收处理。

2.根据权利要求1所述的方法，其特征在于，所述若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，确定所述目标内存空间满足回收条件，则对所述目标内存空间进行回收处理，包括：

若确定所述至少一个应用线程各自对应的版本号均大于所述目标内存空间对应的所述第二版本号，则对所述目标内存空间进行回收处理。

3.根据权利要求1所述的方法，其特征在于，所述若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，确定所述目标内存空间满足回收条件，则对所述目标内存空间进行回收处理，包括：

获取所述至少一个应用线程各自对应的活跃状态信息；

若根据所述活跃状态信息确定所述至少一个应用线程中存在处于不活跃状态的应用线程，则在根据除所述处于不活跃状态的应用线程外的其他应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号确定所述目标内存空间满足回收条件时，对所述目标内存空间进行回收处理。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，确定所述目标内存空间不满足回收条件，则对所述回收线程对应的所述第三版本号进行递增更新以得到第四版本号。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

响应于在第三时刻所述目标应用线程执行完任务后触发的版本号获取请求，将所述回收线程此时对应的所述第四版本号发送至所述目标应用线程作为所述目标应用线程此时对应的版本号。

6.根据权利要求4所述的方法，其特征在于，所述响应于在第一时刻对所述目标内存空间触发的回收请求，对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号，包括：

响应于在第一时刻将所述目标内存空间的地址信息写入第一队列而触发的回收请求，从所述第一队列获取所述目标内存空间的地址信息，对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号；

所述若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，确定所述目标内存空间不满足回收条件之后，所述方法还包括：

将所述目标内存空间的地址信息写入用于存储等待进行回收的内存空间的第二队列，将所述目标内存空间的地址信息从所述第一队列中删除。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

在接收到回收请求，或者确定所述第二队列不为空且设定时长内没有接收到回收请求时，针对所述第二队列中包含的任一内存空间的地址信息，根据对应的各应用线程此时对应的版本号以及所述任一内存空间对应的版本号确定所述任一内存空间是否满足回收条件。

8.一种内存回收方法，其特征在于，应用于共同访问目标内存空间的至少一个应用线程中的目标应用线程，所述方法包括：

在第一时刻向回收线程触发对所述目标内存空间的回收请求，以使所述回收线程对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号，并确定所述第二版本号作为所述目标内存空间对应的版本号，所述回收线程与所述至少一个应用线程对应；

在第二时刻执行完任务后向所述回收线程发送版本号获取请求，以使所述回收线程将此时对应的第三版本号发送至所述目标应用线程作为所述目标应用线程此时对应的版本号，所述目标应用线程是所述至少一个应用线程中任一个；

其中，所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号，用于使得所述回收线程在确定所述目标内存空间满足回收条件时对所述目标内存空间进行回收处理。

9.根据权利要求8的所述方法，其特征在于，所述方法还包括：

若在设定时长内没有收到需要执行的任务，则设置自身处于不活跃状态后休眠；

所述不活跃状态使得所述回收线程根据除所述处于不活跃状态的应用线程外的其他应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号确定所述目标内存空间是否满足回收条件。

10.一种电子设备，其特征在于，包括：存储器、处理器、通信接口；其中，所述存储器上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1至7中任一项所述的内存回收方法，或者执行如权利要求8或9所述的内存回收方法。

11.一种非暂时性机器可读存储介质，其特征在于，所述非暂时性机器可读存储介质上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至7中任一项所述的内存回收方法，或者执行如权利要求8或9所述的内存回收方法。

12.一种内存回收系统，其特征在于，包括：

共同访问目标内存空间的至少一个应用线程，以及与所述至少一个应用程序对应的回收线程；

所述至少一个应用线程中第一应用线程，用于在第一时刻向所述回收线程触发对所述目标内存空间的回收请求；

所述至少一个应用线程中第二应用线程，用于在第二时刻执行完任务后向所述回收线程发送版本号获取请求，所述第二应用线程是所述至少一个应用线程中任一个；

所述回收线程，用于响应于所述回收请求，对所述回收线程此时对应的第一版本号进行递增更新以得到第二版本号，并确定所述第二版本号作为所述目标内存空间对应的版本号；响应于所述版本号获取请求，将此时对应的第三版本号发送至所述第二应用线程作为所述第二应用线程此时对应的版本号；以及，若根据所述至少一个应用线程各自对应的版本号和所述目标内存空间对应的所述第二版本号确定所述目标内存空间满足回收条件，则对所述目标内存空间进行回收处理。

13.根据权利要求12的所述系统，其特征在于，所述第一应用线程是所述至少一个应用线程中具有触发回收请求权限的应用线程。

Images