CN113918350A - 垃圾回收方法、装置、存储介质及电子设备 - Google Patents

Abstract

本申请实施例公开了一种垃圾回收方法、装置、存储介质及电子设备，其中，方法包括：确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型，若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。采用本申请实施例，可以优化垃圾回收流程，保障垃圾回收过程中的应用性能。

Description

垃圾回收方法、装置、存储介质及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种垃圾回收方法、装置、存储介质及电子设备。

背景技术

随着计算机技术的快速发展，电子设备上所搭载的应用也越来越多。电子设备在运行应用的过程中会涉及到垃圾回收，垃圾回收是通过线程对堆中的待回收对象进行回收，以释放内存空间的一种机制，通过垃圾回收可以释放内存，保障应用的正常运行。

发明内容

本申请实施例提供了一种垃圾回收方法、装置、存储介质及电子设备，所述技术方案如下：

第一方面，本申请实施例提供了一种垃圾回收方法，所述方法包括：

确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。

第二方面，本申请实施例提供了一种垃圾回收装置，所述装置包括：

任务确定模块，用于确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

回收处理模块，用于若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。

第三方面，本申请实施例提供一种计算机存储介质，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行上述的方法步骤。

第四方面，本申请实施例提供一种电子设备，可包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行上述的方法步骤。

本申请一些实施例提供的技术方案带来的有益效果至少包括：

在本申请一个或多个实施例中，电子设备通过确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型，若所述垃圾回收类型为显式回收类型，则电子设备对垃圾回收任务进行并行回收处理，避免以显式回收类型对应的原显式回收流程进行垃圾回收，优化了垃圾回收流程，可以在执行垃圾回收的同时顺利保障目标应用线程的任务运行，保障了垃圾回收过程中的应用性能，也提升了垃圾回收过程中的容灾能力。

附图说明

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

图1是本申请实施例提供的一种垃圾回收方法的流程示意图；

图2是本申请实施例提供的一种显式回收类型涉及的垃圾回收示意图；

图3是本申请实施例提供的垃圾回收方法涉及的另一种实施例的流程示意图；

图4是本申请实施例提供的一种并行垃圾回收涉及的场景示意图；

图5是本申请实施例提供的一种执行垃圾回收的场景示意图；

图6是本申请实施例提供的垃圾回收方法涉及的另一种实施例的流程示意图；

图7是本申请实施例提供的一种垃圾回收装置的结构示意图；

图8是本申请实施例提供的一种回收处理模块的结构示意图；

图9是本申请实施例提供的一种电子设备的结构示意图；

图10是本申请实施例提供的操作系统和用户空间的结构示意图；

图11是图10中安卓操作系统的架构图；

图12是图10中IOS操作系统的架构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

下面结合具体的实施例对本申请进行详细说明。

在一个实施例中，如图1所示，特提出了一种垃圾回收方法，该方法可依赖于计算机程序实现，可运行于基于冯诺依曼体系的垃圾回收装置上。该计算机程序可集成在应用中，也可作为独立的工具类应用运行。所述垃圾回收装置可以为电子设备，包括但不限于：个人电脑、平板电脑、手持设备、车载设备、可穿戴设备、计算设备或连接到无线调制解调器的其它处理设备等。在不同的网络中终端设备可以叫做不同的名称，例如：用户设备、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置、蜂窝电话、无绳电话、5G网络或未来演进网络中的电子设备等。

具体的，该垃圾回收方法包括：

S101：确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

所述垃圾回收(garbage collection，GC)可以理解为对堆中的一些待回收对象进行回收，以释放内存空间的一种机制，在一些实施例中，待回收对象至少包括孤立对象。孤立对象可以理解为在堆中与其他对象没用引用的对象。

所述堆(heap)可以理解为电子设备内存中用于存放对象(如对象实例)的区域，在一些实施例中，若该内存托管技术使用的是JAVA语言，则所述堆是系统虚拟机所管理的内存中最大的一块区域，该区域是被所有线程共享的一块内存区域，在虚拟机启动时就会创建堆，通常对象都是可以在堆中分配内存。

可以理解的，对于电子设备而言，电子设备上搭载至少一个应用，所述应用可以是电子设备操作系统本身自带的应用，可以是第三方应用；所述应用线程是操作系统能够进行应用业务运算调度的最小单位。通常应用线程与进程相关，应用线程被包含在进程之中，并作为进程中的实际运作单位。其中，一条应用线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个应用线程，每条应用线程并行执行不同的应用任务。进一步的，电子设备上的应用程序在运行时会对应一个进程，根据应用程序的应用业务的不同通常会对应不同的应用线程。也可以理解为：应用线程是应用与对象之间的桥梁，当用户在电子设备上操作应用执行相应的功能时，该应用会触发与该功能对应的应用线程访问堆中的对象以实现相应的功能。

所述目标应用线程可以理解为当前所触发了垃圾回收任务的应用线程，

可以理解的，电子设备可以对线程池中的各应用线程进行监测，监测应用线程待执行的应用任务，若监测到某一目标应用线程的待执行任务为垃圾回收任务(GC任务)，可以确定目标应用线程即将触发垃圾回收任务，然后电子设备对该应用线程对应的垃圾回收任务进行解析，可以获取到垃圾回收任务对应的垃圾回收类型。

在一种可行的实施方式中，电子设备可以对垃圾回收接口进行监测，通常目标应用线程执行垃圾回收任务时会先调用相应的垃圾回收接口，电子设备通过对垃圾回收接口进行监测，可以确定目标应用线程触发垃圾回收任务；进一步的，通常不同垃圾回收类型的垃圾回收任务可以对应不同的垃圾回收接口，电子设备仅需基于目标应用线程所触发的垃圾回收接口的类型，可以确定垃圾回收任务对应的垃圾回收类型，可以理解为垃圾回收接口的类型与垃圾回收任务的垃圾回收类型相对应。

可选的，可以预先建立各“垃圾回收任务对应的参考垃圾回收类型”与相应“垃圾回收接口的参考类型”的映射关系，基于该映射关系电子设备可以在确定当前垃圾回收接口被目标应线程触发(或调用)之后，基于垃圾回收接口的类型确定垃圾回收任务对应的垃圾回收类型。

可以理解为的，所述垃圾回收类型至少可分为并行垃圾回收类型和阻塞垃圾回收类型，所述阻塞回收类型从垃圾回收流程上来区分：阻塞回收类型可称之为串行回收类型。在一些实施例中阻塞回收类型包括但不限于Explicit GC(显式回收类型，可理解为显示调用场景下的垃圾回收类型)、Alloc GC(内存分配场景下的垃圾回收类型)、Background GC(后台运行场景下的垃圾回收类型)...等等。

在一种具体的实施场景中，当垃圾回收任务为Explicit GC显式回收类型时，通常目标应用线程会调用Explicit GC接口(Explicit垃圾回收接口)来执行垃圾回收任务，可以理解的，电子设备通过监测到Explicit GC接口被目标应用线程调用时，可确定目标应用线程即将触发垃圾回收任务执行Explicit GC接口对应的垃圾回收流程。

S102：若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。

可以理解的，在目标应用线程触发的垃圾回收任务为显式回收类型时，目标应用线程若基于显式回收类型对应的显式回收流程，通常需要等待执行完毕垃圾回收任务后才能够执行垃圾回收任务的下一个目标线程任务；

示意性的，如图2所示，图2是一种显式回收类型涉及的垃圾回收示意图，电子设备上的某一应用的线程A此时调用Explicit GC接口以执行垃圾回收任务的显式回收流程，待垃圾回收任务从图2中02步骤一直到07步骤执行完毕之后，线程A才能执行垃圾回收任务的下一任务。

如图2所示，显式回收流程通常可以是：

步骤02：目标应用线程-线程A调用应用侧的Explicit GC接口触发垃圾回收，例如Runtime.gc()、System.gc()；

步骤03：通过Explicit GC接口在本地接口侧(JNI侧)调用Native接口触发垃圾回收；

步骤04：通过Native接口在虚拟机侧(ART侧)调用JVM GC接口(java虚拟机垃圾回收接口)触发垃圾回收；

步骤05：在虚拟机侧(ART侧)通过JVM GC接口调用执行显式GC任务的GC接口触发显式垃圾回收，例如，CollectGarbage接口

步骤06：在虚拟机侧(ART侧)通过执行显式GC任务的GC接口调用垃圾回收实现接口开始进行垃圾回收，例如：CollectGarbageInternal()

步骤07：在虚拟机侧(ART侧)通过垃圾回收实现接口完成显式回收类型的垃圾回收任务。

可以理解的，电子设备基于显式回收类型由目标应用线程执行对应的显式回收流程，目标应用线程在一些实施场景中需等待显式回收流程执行完垃圾回收，才能执行下一任务，垃圾回收效率较低，线程逻辑运行增加耗时较长进而影响了目标应用线程的任务进度。在本申请中，电子设备若确定垃圾回收类型为显式回收类型，可对所述垃圾回收任务进行并行回收处理，可以理解为基于并行回收类型的并行回收流程进行垃圾回收，同时在目标应用线程触发垃圾回收任务后可并行执行垃圾回收任务的下一任务，在一些实施例中，电子设备目标应用线程通过触发并行回收流程的并行垃圾回收接口，一方面此时电子设备通过触发并行垃圾回收接口采用目标应用线程之外的辅助线程执行垃圾回收任务，另一方面，辅助线程在调用完并行垃圾回收接口之后，执行垃圾回收任务对应的下一线程任务。可以理解的，目标应用线程无需等待垃圾回收的完成即可进行下一任务，提高了任务处理效率，可避免诸如垃圾回收任务执行出错时的影响目标应用线程的运行。

可以理解的，在垃圾回收过程中，可以通过确定对堆中各已创建对象的引用关系，基于引用关系对已创建对象进行标记以及整理，如标记存活对象和孤立对象，然后可以对相应对象进行回收以释放内存空间，例如删除孤立对象来释放孤立对象所占用的内存空间。标记存活对象可以是基于垃圾回收策略从根对象开始，由于根对象只能引用其他对象不能被其他对象引用，从根对象开始，递归地标记根对象引用的对象为存活对象。

在本申请实施例中，电子设备通过确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型，若所述垃圾回收类型为显式回收类型，则电子设备对垃圾回收任务进行并行回收处理，避免以显式回收类型对应的原显式回收流程进行垃圾回收，优化了垃圾回收流程，可以在执行垃圾回收的同时顺利保障目标应用线程的任务运行，保障了垃圾回收过程中的应用性能，也提升了垃圾回收过程中的容灾能力。

请参见图3，图3是本申请提出的一种垃圾回收方法的另一种实施例的流程示意图。具体的：

S201：确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

根据一些实施例中，电子设备通过确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型，然后若所述垃圾回收类型为显式回收类型，则通常可以将所述垃圾回收任务对应的垃圾回收流程更新为并行回收流程；

具体可参考本申请其他实施例的方法步骤，此处不再赘述。

S202：若所述垃圾回收类型为显式回收类型，则获取所述垃圾回收任务对应的垃圾回收流程，对所述垃圾回收流程对应的垃圾回收接口进行接口更新处理；

根据一些实施例中，当垃圾回收任务为Explicit GC显式回收类型时，通常目标应用线程会调用Explicit GC接口(Explicit垃圾回收接口)来执行垃圾回收任务，可以理解的，电子设备通过监测到Explicit GC接口被目标应用线程调用时，可确定目标应用线程即将触发垃圾回收任务执行Explicit GC接口对应的垃圾回收流程。

可以理解的，针对于Explicit GC显式回收，通常电子设备的应用所对应的工作线程基于显示调用的方式直接调用相关垃圾回收接口，以主动发起一次垃圾回收；在相关技术中通常这次垃圾回收由发起方(发起显式回收的线程)执行完后，再继续执行垃圾回收任务的下一线程任务，如调用下一函数或下一方法。

可以理解的，为了避免目标应用线程在一些实施场景中需等待显式回收流程执行完垃圾回收才能执行下一任务，以避免垃圾回收效率较低。在本申请的一个或多个的实施例中，可以将所述垃圾回收任务对应的垃圾回收流程更新为并行回收流程，以并行回收的方式进行垃圾回收，具体实施中，电子设备可以是对所述垃圾回收流程对应的垃圾回收接口进行接口更新处理来实现的，电子设备通获取垃圾回收任务对应的垃圾回收流程(通常为显式回收类型对应的显式回收流程)，然后对显式回收流程中的相应GC接口进行更新，也即对显式回收流程中的垃圾回收接口进行接口更新处理，以释放目标应用线程正在执行的垃圾回收任务使得目标应用线程可以执行下一目标线程任务，同时原垃圾回收任务通过在接口更新处理之后由其他辅助线程来完成。

在一种可行的实施方式中，显式回收类型的垃圾回收流程通常由应用的发起方目标应用线程在应用侧触发显式回收接口，通过显式回收接口调用本地接口侧的执行垃圾回收的本地接口，基于“本地接口层的执行垃圾回收的本地接口”调用虚拟机侧中的相关GC接口进行，在本申请中可以是对虚拟机侧中的底层相关GC接口进行接口更新处理，以避免在应用侧或本地接口侧改变执行逻辑造成的任务崩溃现象，同时保障垃圾回收的进行，以JAVA为例，电子设备不在应用层和JNI层(JAVA本地接口层)进行执行逻辑更新，而是在ART层(虚拟机)对显式回收流程对应的垃圾回收接口进行接口更新处理，控制调用其他辅助线程来完成垃圾回收任务，从而实现与目标应用线程并行完成垃圾回收任务。

在一种可行的实施方式中，

1、获取所述垃圾回收任务对应的第一回收接口。

所述第一回收接口通常为所述显式回收类型对应的显式回收流程中的垃圾回收接口；

可以理解的，针对于显式回收类型的垃圾回收任务而言，应用层目标应用线程通常调用Explicit GC接口，在虚拟机层(或虚拟机侧，如ART层)显式回收流程中涉及的是虚拟机中的用于执行显示GC的显示GC接口，在一些实施方式，虚拟机中的用于执行显示GC的显示GC接口可以是CollectGarbage接口，以执行显式GC任务的GC接口触发显式垃圾回收。可以理解为，第一回收接口至少可以包括虚拟机层中的(用于执行显示GC任务)显示GC接口

2、电子设备可以将所述第一回收接口更新为第二回收接口，所述第二回收接口与并行回收流程相关联。

所述第二回收接口可以理解为用于将显式回收类型的垃圾回收任务转换为并行回收流程执行的函数接口；在一些实施例中，第一回收接口与第二回收接口属于同一虚拟机层(侧)的接口。

在一些实施例中，第二回收接口可以是新建的用于将显式回收类型的垃圾回收任务转换为并行回收流程执行的函数接口，第二回收接口的接口定义可以基于实际应用环境确定，如第二回收接口的名称可以设置为RequestConcurrentGCInExplicit()接口，进一步的可以将图2中步骤05调用的CollectGarbage()接口替换成新增的RequestConcurrentGCInExplicit()接口；

可以理解的，第二回收接口的函数功能可以设置为用于将显式回收类型的垃圾回收任务转换为并行回收流程；

可选的，第二回收接口的函数功能可以设置为调用并行回收接口为并行回收流程的专属线程(也即第一回收线程)添加垃圾回收任务。

可选的，第二回收接口的函数功能可以设置为其他工作线程执行垃圾回收流程。

可以理解的，电子设备通过将第一回收接口更新为第二回收接口，以实现对垃圾回收任务的并行回收处理，同时电子设备此时可控制目标应用线程执行垃圾回收任务的下一目标线程任务。

S203：通过接口更新处理后的所述垃圾回收接口将所述垃圾回收任务与并行回收流程关联。

可以理解的，电子设备通过接口更新处理后的垃圾回收接口来实现垃圾回收任务与并行回收流程关联，基于并行回收流程执行该垃圾回收任务，原目标应用线程不再执行垃圾回收任务而执行下一目标线程任务。例如，目标应用线程可以是应用对应的应用主线程、渲染线程等，这些目标应用线程通常在发起垃圾回收任务时以显式回收类型发起显式回收流程。

可以理解的，在本申请中，目标应用线程不再执行垃圾回收任务，基于此，电子设备可控制除目标应用线程之外的辅助线程来执行垃圾回收任务。从而实现垃圾回收任务与目标线程任务(垃圾回收任务的下一任务)并行执行。

在一种具体的实施场景中，电子设备可以通过触发第二回收接口向辅助线程添加并行垃圾回收任务，例如通过新增的RequestConcurrentGCInExplicit()接口实现向辅助线程调节并行垃圾回收任务。

具体的，通过触发第二回收接口向辅助线程添加并行垃圾回收任务，在添加并行垃圾回收任务的过程中对任务参数进行设置，以保障GC回收及内存整理与原GC流程一致，且请求辅助线程后，辅助线程线程立刻执行。任务参数的设置包括但不限于：“将并行垃圾回收任务的gc_cause(触发原因)设置为目标应用线程触发，例如设置为目标应用线程的名称”、“将并行垃圾回收任务的任务执行时间设置为当前时间(可理解为当前时间立即执行)，例如设置为NanoTime”、回收对象数量、回收对象类型等等。

可以理解的，向辅助线程调节并行垃圾回收任务后，辅助线程接收到目标应用线程添加的并行垃圾回收任务后，从睡眠状态唤醒以执行并行垃圾回收任务，进一步的辅助线程还可以检测是否满足执行条件，如检查任务执行时间是否小于等于当前时间，满足执行(并行)垃圾回收任务。

可以理解的，所述并行垃圾回收任务用于指示辅助线程并行执行所述垃圾回收任务，可以理解为实现垃圾回收任务与目标线程任务(垃圾回收任务的下一任务)并行执行

进一步的，并行垃圾回收任务可以是由并行回收流程对应的默认回收线程完成的，也即将并行回收流程对应的默认回收线程作为当前的辅助线程；

进一步的，并行垃圾回收任务可以是由除所述目标应用线程和第一回收线程之外的应用工作线程完成的，也即将该工作线程作为当前的辅助线程；

在一种可行的实施方式中，可以通过第二回收接口向第一回收线程添加并行垃圾回收任务，所述第一回收线程为并行回收流程对应的默认回收线程；

可以理解的，第一回收线程作为并行回收流程对应的默认回收线程，专职处理并行回收流程。在相关技术中，若触发的是垃圾回收任务的垃圾回收类型为并行回收类型，通常与运行在每个工作进程的HeapTaskDaemon线程(也可称之专职GC回收线程)，与工作线程功能逻辑并行执行。在本申请中可理解为：对属于显式回收类型的垃圾回收任务进行并行垃圾回收。

进一步的，作为并行回收流程对应默认回收线程的第一回收线程，通常由相应的垃圾回收接口来实现调用，可以理解为，电子设备可以通过第二回收接口调用第三回收接口以通过第三回收接口触发第一回收线程执行并行回收流程，第三回收接口可理解为并行回收流程对应的垃圾回收接口，例如：第三回收接口可以基于实际应用情况其名称可为RequestConcurrentGC接口。

示意性的，如图4所示，图4是一种并行垃圾回收涉及的场景示意图，电子设备上的某一应用的线程A此时调用Explicit GC接口以执行垃圾回收任务的显式回收流程，再通过触发第二回收接口向第一回收线程添加并行垃圾回收任务后，后续第一回收线程执行垃圾回收任务同时目标应用线程执行垃圾回收任务的下一目标线程任务。

具体而言，步骤12：目标应用线程调用应用侧的Explicit GC接口触发垃圾回收，例如Runtime.gc()、System.gc()；

步骤13：通过Explicit GC接口在本地接口侧(JNI侧)调用Native接口触发垃圾回收；

步骤14：通过Native接口在虚拟机侧(ART侧)调用JVM GC接口(java虚拟机垃圾回收接口)触发垃圾回收；

步骤15：在虚拟机侧(ART侧)通过将第一回收接口更新为第二回收接口，以后续实现对垃圾回收任务的并行回收处理，同时电子设备此时可控制目标应用线程执行垃圾回收任务的下一目标线程任务。具体实施中，通过诸如新增的RequestConcurrentGCInExplicit接口实现向第一回收线程增加并行垃圾回收任务。

步骤16：通过第二回收接口(如RequestConcurrentGCInExplicit接口)调用第三回收接口(RequestConcurrentGC接口)以通过第三回收接口触发调用第一回收线程。

步骤17：通过第三回收接口向第一回收线程添加并行垃圾回收任务。

步骤18：目标应用线程执行垃圾回收任务的下一目标线程任务。

步骤19：在虚拟机侧(ART侧)第一回收线程执行并行垃圾回收任务，以完成显式回收类型的垃圾回收任务。

在一种具体的实施场景中，如图5所示，图5是一种执行垃圾回收的场景示意图。

步骤191：在虚拟机侧(ART侧)为第一回收线程(如HeapTaskDaemon线程)添加并行回收任务完成任务参数设置之后，电子设备将第一回收任务唤醒，进一步的辅助线程还可以检测是否满足执行条件，如检查任务执行时间是否小于等于当前时间，满足执行(并行)垃圾回收任务。

步骤192：第一回收线程(如HeapTaskDaemon线程)执行并行垃圾回收任务；

步骤193：第一回收线程执行并行垃圾回收任务以在虚拟机测内部调用GC实现接口进行垃圾回收，内部GC实现接口可以是CollectGarbageInternal接口:虚拟机ART运行时内部调用的GC接口，可以执行各种类型的GC。

步骤193：完成并行垃圾回收任务，显式垃圾回收类型的垃圾回收任务完成。

需要说明的是，上述第一回收线程是并行回收流程对应的默认回收线程，也可理解为专职并行回收线程或(并行)守护线程。

在一种可行的实施方式中，可以确定第二回收线程，通过第二回收接口向第二回收线程添加并行垃圾回收任务，所述第二回收线程为除所述目标应用线程和第一回收线程之外的应用工作线程。也就是说，电子设备可以不基于已存在的并行回收流程对应的第一回收线程执行当前的(并行)垃圾回收任务，而是采用其外的第二回收线程。

可选的，第二回收线程可以采用线程新建的方式：新建第二回收线程，将所述第二回收线程设置为所述并行回收流程的默认回收线程；

具体实施中：电子设备可以再新建一个并行回收流程对应的默认回收线程作为第二回收线程，通过新建的第二回收线程专职来处理Explicit GC类型的垃圾回收任务。可以理解的是，此时的第二回收线程进行垃圾回收时通常以并行垃圾回收流程进行。

示意性的：1、在虚拟机侧(ART侧)为第二回收线程(如新建的HeapTaskDaemon线程)添加并行回收任务完成任务参数设置之后，电子设备将第一回收任务唤醒，进一步的辅助线程还可以检测是否满足执行条件，如检查任务执行时间是否小于等于当前时间，满足执行(并行)垃圾回收任务。

2：第二回收线程(如新建的HeapTaskDaemon线程)执行并行垃圾回收任务；

3：第二回收线程(如新建的HeapTaskDaemon线程)执行并行垃圾回收任务以在虚拟机测内部调用GC实现接口进行垃圾回收，内部GC实现接口可以是CollectGarbageInternal接口:虚拟机ART运行时内部调用的GC接口，可以执行各种类型的GC。

4：完成并行垃圾回收任务，显式垃圾回收类型的垃圾回收任务完成。

需要说明的是，上述第二回收线程是新建的并行回收流程对应的默认回收线程，也可理解为新建的专职并行回收线程或(并行)守护线程。

可选的，第二回收线程可以基于已有的工作线程来确定，也就是说不新建所述并行回收流程的默认回收线程；而是从应用的至少一个工作线程来确定一个用于执行当前的垃圾回收任务的第二回收线程。

具体实施中，可以获取至少一个工作线程的线程状态，基于所述线程状态从所述至少一个工作线程中确定第二回收线程；

所述工作线程的线程状态可以是基于该工作线程的状态信息反馈的，基于工作线程的寄存器状态信息可以实时更新相应工作线程的线程状态。

所述工作线程的状态信息可以是工作线程的寄存器状态参数、任务执行参数、线程处理时延参数、待执行任务量参数、待执行任务量参数、任务可执行时间参数等状态类型参数中的一种或多种类型状态信息的拟合。

可选的，电子设备可采用轮询的方式周期性获取至少一个工作线程的状态信息，基于工作线程的状态信息对线程状态进行参数评估，以得到反馈工作线程状态的评估值。

进一步的，参数评估可以是设置参数评估规则，参数评估规则可以是：针对每一状态类型参数设置权重，采用加权求和的方式得到评估值，该评估值反馈工作线程的状态。

进一步的，参数评估可以是设置参数评估规则，参数评估规则可以是：针对状态类型参数设置至少一个参数范围，每个参数范围对应一种类型的线程状态，实际应用中，在获取到工作线程的状态类型参数后，仅需确定状态类型参数所落入的参数范围，即可确定该参数范围所对应的线程状态。

所述线程状态可以基于实际情况定义，例如可分为闲时状态、忙碌状态、正常状态等等。

可以理解的，电子设备可以从至少一个工作线程中选择属于目标状态的第二回收线程，目标状态可以是自定义的，如闲时状态。

具体实施中，在从至少一个工作线程中确定第二回收线程之后，通过第二回收接口向第二回收线程添加并行垃圾回收任务，第二回收线程为除所述目标应用线程和第一回收线程之外的工作线程。

进一步的，此时第二回收线程在执行并行垃圾回收任务时，第二回收线程可以采用显示回收流程进行垃圾回收。也就是说，在完成向第二回收线程添加并行垃圾回收任务之后，“第二回收线程采用显示回收流程进行垃圾回收”同时“原目标应用线程释放垃圾回收任务而执行垃圾回收任务之后的目标线程任务”，这两者是并行执行的从而实现了垃圾回收任务与目标线程任务的并行执行，提升了垃圾回收的效率，避免了由于垃圾回收任务故障时阻塞目标线程任务的执行，提升了垃圾回收过程中的应用性能。

S204：基于所述并行回收流程并行执行所述垃圾回收任务以及目标线程任务。

具体可参见本申请的方法实施例的其他方法步骤，此处不再赘述。

在本申请的一个或多个实施例中，应用的目标应用线程原本调用Explicit GC接口触发显式垃圾回收流程开始一次GC回收，通常这将极大概率阻塞工作应用线程(也即应用的工作应用线程，如目标应用线程)，从而引起卡顿、卡死、定屏等垃圾回收中的故障问题，通过执行本申请实施例，将显式回收类型的垃圾回收任务对应的显示回收流程转换成并行执行垃圾回收任务，可有效解决此类问题。并且通过垃圾回收任务的设定基于目标线程来完成，可确保优化前后的垃圾回收效果，针对应用的目标应用线程而言无需再等待垃圾回收任务的完成即可执行下一目标线程任务，避免垃圾回收过程中的故障问题，提高了垃圾回收的容灾能力，同时可基于目标线程实现了与“目标应用线程执行下一任务”并行垃圾回收任务，也保障了垃圾回收任务的进行避免了垃圾回收任务的等待，也保障了应用的应用性能，满足垃圾回收任务的回收效果。

请参见图6，图6是本申请提出的一种垃圾回收方法的另一种实施例的流程示意图。具体的：

S301：确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

具体可参见本申请涉及的其他实施例的方法步骤，此处不再赘述。

S302：若所述垃圾回收类型为显式回收类型，则获取当前的状态参数；

所述状态参数可以是反馈系统中与垃圾回收相关的虚拟机状态和/或反馈应用线程对应应用的应用运行状态；

所述虚拟机状态可以是反馈虚拟机状态的当前堆内存大小，垃圾对象个数，垃圾对象占用内存大小，上次垃圾回收后的对象分配个数、上次垃圾回收后的分配内存大小，Explicit GC请求(显式垃圾回收请求)次数、上次垃圾回收的时间等参数中的一种或多种的拟合来反馈。可以理解的，垃圾回收通常是对虚拟机所对应的堆区域中相关对象进行垃圾回收操作。在本申请中，可在垃圾回收任务执行前，先获取反馈“虚拟机的状态”的状态参数，以衡量堆中垃圾对象的程度，确定是否执行显示回收类型的垃圾回收任务。

所述应用运行状态用于指示应用的负载状态的：当前应用的吞吐量、当前应用占用的内存、应用任务量等参数中的一种或多种的拟合来反馈。

可以理解的，电子设备可以在应用运行过程中创建状态监测线程，基于状态监测线程实时或周期性的对当前的状态参数进行收集并保存，如对当前反馈系统中与垃圾回收相关的虚拟机状态的参数进行收集，又如对反馈应用线程对应应用的应用运行状态的参数进行收集。这样在目标应用线程触发显式回收类型的垃圾回收任务之后，可快速获取到所保存的当前的状态参数。

S303：若所述状态参数与参考状态参数匹配，则执行对所述垃圾回收任务进行并行回收处理的步骤。

S304：若所述状态参数与参考状态参数不匹配，则对所述垃圾回收任务进行任务忽略处理。

所述参考状态参数可以理解为针对状态参数所设置，如针对状态参数设置的一个参数范围，又如针对状态参数设置的一个参数阈值等等，设置参考状态参数用于评判是否执行显示回收类型的垃圾回收任务，以保障在当前状态忙时不触发或少触发显示回收类型的垃圾回收任务，以及保证应用的线程事务需求。

在一种可行的实施方式中，可以是根据实际需求针对至少一个类型的状态参数分别设备参考状态参数，可以理解的：若纳入参考的状态参数类型为多个，则分别针对各类型的状态参数设置参考状态参数，例如，基于系统虚拟机的内存占用率的设定占用率参数阀值、基于“上次垃圾回收后的对象分配个数”设置个数阈值、基于应用的吞吐量设置吞吐量范围。

所述状态参数与参考状态参数匹配可以理解为：针对状态参数设置的参数阈值，若状态参数满足参数阈值，则认为状态参数与参考状态参数匹配，反之，则不匹配；

所述状态参数与参考状态参数匹配可以理解为：针对状态参数设置的参数范围，若状态参数落入参数范围内，则认为状态参数与参考状态参数匹配，反之，则不匹配；

可以理解的：若纳入参考的状态参数类型为多个，可以是在多个类型的状态参数均与参考状态参数匹配时，则确定状态参数与参考状态参数匹配；反之，若存在一个类型的状态参数均与参考状态参数不匹配时，则确定状态参数与参考状态参数不匹配。

在本申请中，结合状态参数来确定是否执行对所述垃圾回收任务进行并行回收处理的步骤，若所述状态参数与参考状态参数不匹配，则对所述垃圾回收任务进行任务忽略处理，也即不执行垃圾回收任务，以减少不必要的Explicit GC垃圾回收；可以保证在执行显示垃圾回收时减少垃圾回收引发的处理量冲击，可以控制垃圾回收时机避免造成垃圾阻塞情况影响应用性能；可以实现基于当前状态有规律的显示垃圾回收，提高垃圾回收过程中的系统容灾能力。

S305：基于所述状态参数调整所述垃圾回收任务的任务参数，基于所述任务参数对所述垃圾回收任务进行并行回收处理；

所述任务参数可以是垃圾回收对象的个数、垃圾回收的执行时间点、垃圾回收的执行回收强度、垃圾回收的频率等任务类型参数中的一种或多种的拟合。在实际应用中，目标应用线程在触发垃圾回收任务时，垃圾回收任务会对应默认任务参数，默认任务参数用于指示电子设备通过目标应用线程进行显式垃圾回收处理。在本申请在对垃圾回收任务调整为并行回收处理的同时，将当前的状态参数纳入参考，以及当前的状态对垃圾回收任务的任务参数进行动态调整，可以实现基于当前状态有规律的进行显示回收类型的垃圾回收，提高垃圾回收过程中的系统容灾能力。

可以理解的，预先可建立各类型状态参数与参考任务参数的参数映射关系，所述参数映射关系可以是以参数表、参数集合、参数数组等形式进行表征。参考任务参数可以是垃圾回收对象的参考个数、垃圾回收的参考执行时间点、垃圾回收的参考执行回收强度、垃圾回收的参考频率等等。则基于前述参数映射关系，可以结合当前的任务参数对垃圾回收任务进行并行回收处理。

S306：基于所述状态参数设置所述垃圾回收任务的垃圾回收对象类型，基于所述垃圾回收对象类型对所述垃圾回收任务进行并行回收处理。

所述垃圾回收对象类型通常基于对象的引用关系来划分，垃圾回收对象类型可以是强引用对象类型、软引用对象类型、弱引用对象类型、虚引用对象类型、孤立对象类型等。

可以理解的，预先可建立各类型状态参数与参考垃圾回收对象类型的对象类型映射关系，所述对象类型映射关系可以是以对象类型表、对象类型集合、对象类型数组等形式进行表征。基于前述对象类型映射关系，可以结合当前的任务参数设置所述垃圾回收任务的垃圾回收对象类型，以基于所述垃圾回收对象类型对所述垃圾回收任务进行并行回收处理。

例如，基于当前的状态参数在对象类型映射关系中确定应设置垃圾回收对象类型为虚引用对象类型、孤立对象类型，则电子设备遍历虚拟机堆中所有对象的类型，对属于虚引用对象类型、孤立对象类型的对象执行垃圾回收，回收这些对象的占用内容。

在本申请一个或多个实施例中，电子设备通过确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型，若所述垃圾回收类型为显式回收类型，则电子设备对垃圾回收任务进行并行回收处理，避免以显式回收类型对应的原显式回收流程进行垃圾回收，优化了垃圾回收流程，可以在执行垃圾回收的同时顺利保障目标应用线程的任务运行，保障了垃圾回收过程中的应用性能以及，可以结合当前的状态参数来有规律的进行显示回收类型的垃圾回收，提高垃圾回收过程中的系统容灾能力；以及，通过调整原垃圾回收任务的任务参数以及设置垃圾回收对象类型，可以不仅仅只对孤立对象进行垃圾回收实现了基于当前状态的智能对相应类型对象的会后，提升了了垃圾回收过程中的智能化程度。

下面将结合图7，对本申请实施例提供的垃圾回收装置进行详细介绍。需要说明的是，图7所示的垃圾回收装置，用于执行本申请图1～图6所示实施例的方法，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请图1～图6所示的实施例。

请参见图7，其示出本申请实施例的垃圾回收装置的结构示意图。该垃圾回收装置1可以通过软件、硬件或者两者的结合实现成为用户终端的全部或一部分。根据一些实施例，该垃圾回收装置1包括任务确定模块11和回收处理模块12，具体用于：

任务确定模块11，用于确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

回收处理模块12，用于若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。

可选的，所述回收处理模块12，具体用于：

将所述垃圾回收任务对应的垃圾回收流程更新为并行回收流程，基于所述并行回收流程并行执行所述垃圾回收任务以及目标线程任务；

其中，所述目标线程任务为所述垃圾回收任务之后的线程任务。

可选的，如图8所示，所述回收处理模块12，包括；

接口更新单元121，用于获取所述垃圾回收任务对应的垃圾回收流程，对所述垃圾回收流程对应的垃圾回收接口进行接口更新处理；

流程关联单元122，用于通过接口更新处理后的所述垃圾回收接口将所述垃圾回收任务与并行回收流程关联。

可选的，所述接口更新单元121，具体用于：

获取所述垃圾回收任务对应的第一回收接口，所述第一回收接口为所述显式回收类型对应的显式回收流程中的垃圾回收接口；

将所述第一回收接口更新为第二回收接口，所述第二回收接口与并行回收流程相关联。

可选的，所述接口更新单元121，具体用于：

通过第二回收接口向辅助线程添加并行垃圾回收任务；

其中，所述并行垃圾回收任务用于指示辅助线程并行执行所述垃圾回收任务。

可选的，所述回收处理模块12，具体用于：

通过第二回收接口向第一回收线程添加并行垃圾回收任务，所述第一回收线程为所述并行回收流程对应的默认回收线程；

确定第二回收线程，通过第二回收接口向第二回收线程添加并行垃圾回收任务，所述第二回收线程为除所述目标应用线程和第一回收线程之外的线程。

可选的，所述回收处理模块12，具体用于：

新建第二回收线程，将所述第二回收线程设置为所述并行回收流程的默认回收线程；或，

获取至少一个工作线程的线程状态，基于所述线程状态从所述至少一个工作线程中确定第二回收线程。

可选的，所述回收处理模块12，具体用于：

获取当前的状态参数；

若所述状态参数与参考状态参数匹配，则执行对所述垃圾回收任务进行并行回收处理的步骤。

可选的，所述回收处理模块12，具体用于：

若所述状态参数与参考状态参数不匹配，则对所述垃圾回收任务进行任务忽略处理。

可选的，所述回收处理模块12，具体用于：

获取当前的状态参数，基于所述状态参数调整所述垃圾回收任务的任务参数，基于所述任务参数对所述垃圾回收任务进行并行回收处理；和/或，

获取当前的状态参数，基于所述状态参数设置所述垃圾回收任务的垃圾回收对象类型，基于所述垃圾回收对象类型对所述垃圾回收任务进行并行回收处理。

需要说明的是，上述实施例提供的垃圾回收装置在执行垃圾回收方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的垃圾回收装置与垃圾回收方法实施例属于同一构思，其体现实现过程详见方法实施例，这里不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请实施例还提供了一种计算机存储介质，所述计算机存储介质可以存储有多条指令，所述指令适于由处理器加载并执行如上述图1～图6所示实施例的所述垃圾回收方法，具体执行过程可以参见图1～图6所示实施例的具体说明，在此不进行赘述。

本申请还提供了一种计算机程序产品，该计算机程序产品存储有至少一条指令，所述至少一条指令由所述处理器加载并执行如上述图1～图6所示实施例的所述垃圾回收方法，具体执行过程可以参见图1～图6所示实施例的具体说明，在此不进行赘述。

请参考图9，其示出了本申请一个示例性实施例提供的电子设备的结构方框图。本申请中的电子设备可以包括一个或多个如下部件：处理器110、存储器120、输入装置130、输出装置140和总线150。处理器110、存储器120、输入装置130和输出装置140之间可以通过总线150连接。

处理器110可以包括一个或者多个处理核心。处理器110利用各种接口和线路连接整个电子设备内的各个部分，通过运行或执行存储在存储器120内的指令、程序、代码集或指令集，以及调用存储在存储器120内的数据，执行电子设备100的各种功能和处理数据。可选地，处理器110可以采用数字信号处理(digital signal processing，DSP)、现场可编程门阵列(field－programmable gate array，FPGA)、可编程逻辑阵列(programmable logicArray，PLA)中的至少一种硬件形式来实现。处理器110可集成中央处理器(centralprocessing unit，CPU)、图像处理器(graphics processing unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器110中，单独通过一块通信芯片进行实现。

存储器120可以包括随机存储器(random Access Memory，RAM)，也可以包括只读存储器(read-only memory，ROM)。可选地，该存储器120包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等，该操作系统可以是安卓(Android)系统，包括基于Android系统深度开发的系统、苹果公司开发的IOS系统，包括基于IOS系统深度开发的系统或其它系统。存储数据区还可以存储电子设备在使用中所创建的数据比如电话本、音视频数据、聊天记录数据，等。

参见图10所示，存储器120可分为操作系统空间和用户空间，操作系统即运行于操作系统空间，原生及第三方应用程序即运行于用户空间。为了保证不同第三方应用程序均能够达到较好的运行效果，操作系统针对不同第三方应用程序为其分配相应的系统资源。然而，同一第三方应用程序中不同应用场景对系统资源的需求也存在差异，比如，在本地资源加载场景下，第三方应用程序对磁盘读取速度的要求较高；在动画渲染场景下，第三方应用程序则对GPU性能的要求较高。而操作系统与第三方应用程序之间相互独立，操作系统往往不能及时感知第三方应用程序当前的应用场景，导致操作系统无法根据第三方应用程序的具体应用场景进行针对性的系统资源适配。

为了使操作系统能够区分第三方应用程序的具体应用场景，需要打通第三方应用程序与操作系统之间的数据通信，使得操作系统能够随时获取第三方应用程序当前的场景信息，进而基于当前场景进行针对性的系统资源适配。

以操作系统为Android系统为例，存储器120中存储的程序和数据如图11所示，存储器120中可存储有Linux内核层320、系统运行时库层340、应用框架层360和应用层380，其中，Linux内核层320、系统运行库层340和应用框架层360属于操作系统空间，应用层380属于用户空间。Linux内核层320为电子设备的各种硬件提供了底层的驱动，如显示驱动、音频驱动、摄像头驱动、蓝牙驱动、Wi-Fi驱动、电源管理等。系统运行库层340通过一些C/C++库来为Android系统提供了主要的特性支持。如SQLite库提供了数据库的支持，OpenGL/ES库提供了3D绘图的支持，Webkit库提供了浏览器内核的支持等。在系统运行时库层340中还提供有安卓运行时库(Android runtime)，它主要提供了一些核心库，能够允许开发者使用Java语言来编写Android应用。应用框架层360提供了构建应用程序时可能用到的各种API，开发者也可以通过使用这些API来构建自己的应用程序，比如活动管理、窗口管理、视图管理、通知管理、内容提供者、包管理、通话管理、资源管理、定位管理。应用层380中运行有至少一个应用程序，这些应用程序可以是操作系统自带的原生应用程序，比如联系人程序、短信程序、时钟程序、相机应用等；也可以是第三方开发者所开发的第三方应用程序，比如游戏类应用程序、即时通信程序、相片美化程序等。

以操作系统为IOS系统为例，存储器120中存储的程序和数据如图12所示，IOS系统包括：核心操作系统层420(Core OS layer)、核心服务层440(Core Services layer)、媒体层460(Media layer)、可触摸层480(Cocoa Touch Layer)。核心操作系统层420包括了操作系统内核、驱动程序以及底层程序框架，这些底层程序框架提供更接近硬件的功能，以供位于核心服务层440的程序框架所使用。核心服务层440提供给应用程序所需要的系统服务和/或程序框架，比如基础(Foundation)框架、账户框架、广告框架、数据存储框架、网络连接框架、地理位置框架、运动框架等等。媒体层460为应用程序提供有关视听方面的接口，如图形图像相关的接口、音频技术相关的接口、视频技术相关的接口、音视频传输技术的无线播放(AirPlay)接口等。可触摸层480为应用程序开发提供了各种常用的界面相关的框架，可触摸层480负责用户在电子设备上的触摸交互操作。比如本地通知服务、远程推送服务、广告框架、游戏工具框架、消息用户界面接口(User Interface，UI)框架、用户界面UIKit框架、地图框架等等。

在图12所示出的框架中，与大部分应用程序有关的框架包括但不限于：核心服务层440中的基础框架和可触摸层480中的UIKit框架。基础框架提供许多基本的对象类和数据类型，为所有应用程序提供最基本的系统服务，和UI无关。而UIKit框架提供的类是基础的UI类库，用于创建基于触摸的用户界面，iOS应用程序可以基于UIKit框架来提供UI，所以它提供了应用程序的基础架构，用于构建用户界面，绘图、处理和用户交互事件，响应手势等等。

其中，在IOS系统中实现第三方应用程序与操作系统数据通信的方式以及原理可参考Android系统，本申请在此不再赘述。

其中，输入装置130用于接收输入的指令或数据，输入装置130包括但不限于键盘、鼠标、摄像头、麦克风或触控设备。输出装置140用于输出指令或数据，输出装置140包括但不限于显示设备和扬声器等。在一个示例中，输入装置130和输出装置140可以合设，输入装置130和输出装置140为触摸显示屏，该触摸显示屏用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作，以及显示各个应用程序的用户界面。触摸显示屏通常设置在电子设备的前面板。触摸显示屏可被设计成为全面屏、曲面屏或异型屏。触摸显示屏还可被设计成为全面屏与曲面屏的结合，异型屏与曲面屏的结合，本申请实施例对此不加以限定。

除此之外，本领域技术人员可以理解，上述附图所示出的电子设备的结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，电子设备中还包括射频电路、输入单元、传感器、音频电路、无线保真(wireless fidelity，WiFi)模块、电源、蓝牙模块等部件，在此不再赘述。

在本申请实施例中，各步骤的执行主体可以是上文介绍的电子设备。可选地，各步骤的执行主体为电子设备的操作系统。操作系统可以是安卓系统，也可以是IOS系统，或者其它操作系统，本申请实施例对此不作限定。

本申请实施例的电子设备，其上还可以安装有显示设备，显示设备可以是各种能实现显示功能的设备，例如：阴极射线管显示器(cathode ray tubedisplay，简称CR)、发光二极管显示器(light-emitting diode display，简称LED)、电子墨水屏、液晶显示屏(liquid crystal display，简称LCD)、等离子显示面板(plasma display panel，简称PDP)等。用户可以利用电子设备101上的显示设备，来查看显示的文字、图像、视频等信息。所述电子设备可以是智能手机、平板电脑、游戏设备、AR(Augmented Reality，增强现实)设备、汽车、数据存储装置、音频播放装置、视频播放装置、笔记本、桌面计算设备、可穿戴设备诸如电子手表、电子眼镜、电子头盔、电子手链、电子项链、电子衣物等设备。

在图9所示的电子设备中，其中电子设备可以是一种终端，处理器110可以用于调用存储器120中存储的垃圾回收应用程序，并具体执行以下操作：

确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。

在一个实施例中，所述处理器1001在执行所述对所述垃圾回收任务进行并行回收处理时，具体执行以下步骤：

将所述垃圾回收任务对应的垃圾回收流程更新为并行回收流程，基于所述并行回收流程并行执行所述垃圾回收任务以及目标线程任务；

其中，所述目标线程任务为所述垃圾回收任务之后的线程任务。

在一个实施例中，所述处理器1001在执行所述将所述垃圾回收任务对应的垃圾回收流程更新为并行回收流程时，具体执行以下步骤：

获取所述垃圾回收任务对应的垃圾回收流程，对所述垃圾回收流程对应的垃圾回收接口进行接口更新处理；

通过接口更新处理后的所述垃圾回收接口将所述垃圾回收任务与并行回收流程关联。

在一个实施例中，所述处理器1001在执行所述对所述垃圾回收流程对应的垃圾回收接口进行接口更新处理时，具体执行以下步骤：

获取所述垃圾回收任务对应的第一回收接口，所述第一回收接口为所述显式回收类型对应的显式回收流程中的垃圾回收接口；

将所述第一回收接口更新为第二回收接口，所述第二回收接口与并行回收流程相关联。

在一个实施例中，所述处理器1001在执行所述通过接口更新处理后的所述垃圾回收接口将所述垃圾回收任务与并行回收流程关联时，具体执行以下步骤：

通过第二回收接口向辅助线程添加并行垃圾回收任务；

其中，所述并行垃圾回收任务用于指示辅助线程并行执行所述垃圾回收任务。

在一个实施例中，所述处理器1001在执行所述通过第二回收接口调用第三回收接口向辅助线程添加并行垃圾回收任务时，具体执行以下步骤：

通过第二回收接口向第一回收线程添加并行垃圾回收任务，所述第一回收线程为所述并行回收流程对应的默认回收线程；或，

确定第二回收线程，通过第二回收接口向第二回收线程添加并行垃圾回收任务，所述第二回收线程为除所述目标应用线程和第一回收线程之外的线程。

在一个实施例中，所述处理器1001在执行所述确定第二回收线程时，具体执行以下步骤：

新建第二回收线程，将所述第二回收线程设置为所述并行回收流程的默认回收线程；或，

获取至少一个工作线程的线程状态，基于所述线程状态从所述至少一个工作线程中确定第二回收线程。

在一个实施例中，所述处理器1001在执行所述对所述垃圾回收任务进行并行回收处理时，具体执行以下步骤：

获取当前的状态参数；

若所述状态参数与参考状态参数匹配，则执行对所述垃圾回收任务进行并行回收处理的步骤。

在一个实施例中，所述处理器1001在执行所述垃圾回收方法时，还执行以下步骤：

若所述状态参数与参考状态参数不匹配，则对所述垃圾回收任务进行任务忽略处理。

在一个实施例中，所述处理器1001在执行所述对所述垃圾回收任务进行并行回收处理时，具体执行以下步骤：

获取当前的状态参数，基于所述状态参数调整所述垃圾回收任务的任务参数，基于所述任务参数对所述垃圾回收任务进行并行回收处理；和/或，

获取当前的状态参数，基于所述状态参数设置所述垃圾回收任务的垃圾回收对象类型，基于所述垃圾回收对象类型对所述垃圾回收任务进行并行回收处理。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体或随机存储记忆体等。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (13)

1.一种垃圾回收方法，其特征在于，所述方法包括：

确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。

2.根据权利要求1所述的方法，其特征在于，所述对所述垃圾回收任务进行并行回收处理，包括：

将所述垃圾回收任务对应的垃圾回收流程更新为并行回收流程，基于所述并行回收流程并行执行所述垃圾回收任务以及目标线程任务；

其中，所述目标线程任务为所述垃圾回收任务之后的线程任务。

3.根据权利要求2所述的方法，其特征在于，所述将所述垃圾回收任务对应的垃圾回收流程更新为并行回收流程，包括：

获取所述垃圾回收任务对应的垃圾回收流程，对所述垃圾回收流程对应的垃圾回收接口进行接口更新处理；

通过接口更新处理后的所述垃圾回收接口将所述垃圾回收任务与并行回收流程关联。

4.根据权利要求3所述的方法，其特征在于，所述对所述垃圾回收流程对应的垃圾回收接口进行接口更新处理，包括：

获取所述垃圾回收任务对应的第一回收接口，所述第一回收接口为所述显式回收类型对应的显式回收流程中的垃圾回收接口；

将所述第一回收接口更新为第二回收接口，所述第二回收接口与并行回收流程相关联。

5.根据权利要求4所述的方法，其特征在于，所述通过接口更新处理后的所述垃圾回收接口将所述垃圾回收任务与并行回收流程关联，包括：

通过第二回收接口向辅助线程添加并行垃圾回收任务；

其中，所述并行垃圾回收任务用于指示辅助线程并行执行所述垃圾回收任务。

6.根据权利要求4所述的方法，其特征在于，所述通过第二回收接口调用第三回收接口向辅助线程添加并行垃圾回收任务，包括：

通过第二回收接口向第一回收线程添加并行垃圾回收任务，所述第一回收线程为所述并行回收流程对应的默认回收线程；或，

确定第二回收线程，通过第二回收接口向第二回收线程添加并行垃圾回收任务，所述第二回收线程为除所述目标应用线程和第一回收线程之外的线程。

7.根据权利要求4所述的方法，其特征在于，所述确定第二回收线程，包括：

新建第二回收线程，将所述第二回收线程设置为所述并行回收流程的默认回收线程；或，

获取至少一个工作线程的线程状态，基于所述线程状态从所述至少一个工作线程中确定第二回收线程。

8.根据权利要求1所述的方法，其特征在于，所述对所述垃圾回收任务进行并行回收处理，包括：

获取当前的状态参数；

若所述状态参数与参考状态参数匹配，则执行对所述垃圾回收任务进行并行回收处理的步骤。

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

若所述状态参数与参考状态参数不匹配，则对所述垃圾回收任务进行任务忽略处理。

10.根据权利要求1所述的方法，其特征在于，所述对所述垃圾回收任务进行并行回收处理，包括：

获取当前的状态参数，基于所述状态参数调整所述垃圾回收任务的任务参数，基于所述任务参数对所述垃圾回收任务进行并行回收处理；和/或，

获取当前的状态参数，基于所述状态参数设置所述垃圾回收任务的垃圾回收对象类型，基于所述垃圾回收对象类型对所述垃圾回收任务进行并行回收处理。

11.一种垃圾回收装置，其特征在于，所述装置包括：

任务确定模块，用于确定目标应用线程触发垃圾回收任务，获取所述垃圾回收任务对应的垃圾回收类型；

回收处理模块，用于若所述垃圾回收类型为显式回收类型，则对所述垃圾回收任务进行并行回收处理。

12.一种计算机存储介质，其特征在于，所述计算机存储介质存储有多条指令，所述指令适于由处理器加载并执行如权利要求1～10任意一项的方法步骤。

13.一种电子设备，其特征在于，包括：处理器和存储器；其中，所述存储器存储有计算机程序，所述计算机程序适于由所述处理器加载并执行如权利要求1～10任意一项的方法步骤。

Images