具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的内存泄漏检测方法，可以应用于如图1所示的应用环境中。其中，终端102通过网络与服务器104进行通信。用户可以通过终端102运行应用程序，服务器104可以是该应用程序所在的服务器。内存泄漏检测方法可以应用于安装有应用程序的终端，也可以应用于该应用程序所在的服务器，还可以应用于包括终端和服务器的系统，并通过终端和服务器的交互实现。其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表、车载终端、智能电视等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

在一个实施例中，如图2所示，提供了一种内存泄漏检测方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤S202至步骤S206。

S202，在应用程序运行过程中，监测应用程序中各目标监测对象的业务逻辑状态以及弱引用状态，弱引用状态用于指示是否存在弱引用，弱引用表示不能确保其引用的对象不会被垃圾回收器回收的引用。

目标监测对象是指应用程序中需要被监测的对象。在开启内存泄漏检测之前，开发人员先将应用程序中需要被监测的对象注册到内存泄漏检测程序中。具体而言，内存泄漏检测程序采用软件包文件格式，以Java语言为例，软件包文件格式为jar，将需要被监测的对象在代码中通过jar包中提供的应用程序接口(API)注册到内存泄漏检测程序中。注册成功的对象存储于监测对象池中，目标监测对象即为监测对象池中存储的对象。

目标监测对象的业务逻辑状态用于指示该目标监测对象在上层业务逻辑中是否有效，业务逻辑状态可以包括业务逻辑有效和业务逻辑失效两种状态。当目标监测对象的业务逻辑状态为业务逻辑有效时，认为该目标监测对象处于业务使用中；当目标监测对象的业务逻辑状态为业务逻辑失效时，认为该目标监测对象的业务不再使用。

弱引用是指不能确保其引用的对象不会被垃圾回收器(Garbage Collection,GC)回收的引用，如果一个对象只被弱引用所引用，则该对象被认为是不可访问(或弱可访问)的，并因此可能在任何时刻被回收。目标监测对象的弱引用状态用于指示该目标监测对象的弱引用是否有效，弱引用状态可以包括弱引用有效和弱引用失效两种状态。当目标监测对象的弱引用状态为弱引用有效时，认为该目标监测对象存在弱引用；当目标监测对象的弱引用状态为弱引用失效时，认为该目标监测对象不存在弱引用。

S204，根据各目标监测对象的业务逻辑状态以及弱引用状态，从各目标监测对象中确定可疑对象。

在一个实施例中，根据各目标监测对象的业务逻辑状态以及弱引用状态，从各目标监测对象中确定可疑对象的步骤，具体可以包括：将业务逻辑状态为业务逻辑失效且弱引用状态为弱引用有效的目标监测对象，确定为可疑对象。

可疑对象是指可能存在内存泄漏的对象。当目标监测对象的业务逻辑状态为业务逻辑有效时，认为该目标监测对象处于业务使用中，从而判定该目标监测对象为正常对象。当目标监测对象的弱引用状态失效时，认为该目标监测对象已被垃圾回收器回收，从而判定该目标监测对象为正常对象。将所有目标监测对象中的正常对象排除，保留下来的目标监测对象为业务逻辑状态为业务逻辑失效且弱引用状态为弱引用有效的目标监测对象，也即业务逻辑失效和尚未被垃圾回收器回收的目标监测对象的交集，将该交集作为可能存在内存泄漏的对象集合。

S206，根据各可疑对象的强引用状态，从各可疑对象中确定泄漏对象，强引用状态用于指示是否存在强应用，强引用表示能确保其引用的对象不会被垃圾回收器回收的引用。

在一个实施例中，根据各可疑对象的强引用状态，从各可疑对象中确定泄漏对象的步骤，具体可以包括：将强引用状态为存在强引用的可疑对象，确定为泄漏对象。

强引用是指能够确保其引用的对象不会被垃圾回收器回收的引用，如果一个对象具有强引用，则该对象不会被垃圾回收器回收。可疑对象的强引用状态是指该可疑对象是否存在强引用，强引用状态可以包括存在强引用和不存在强引用两种状态。当可疑对象的强引用状态为不存在强引用时，判定该可疑对象为正常对象。当可疑对象的强引用状态为存在强引用时，判定该可疑对象为泄漏对象，这是因为可疑对象作为已经被上层业务逻辑释放的对象，存在强引用使得其占用的内存无法被释放，继而无法被垃圾回收器回收，最终导致内存泄漏。

上述内存泄漏检测方法中，在应用程序运行过程中，监测应用程序中各目标监测对象的业务逻辑状态以及弱引用状态，弱引用状态用于指示是否存在弱引用，弱引用表示不能确保其引用的对象不会被垃圾回收器回收的引用；根据各目标监测对象的业务逻辑状态以及弱引用状态，从各目标监测对象中确定可疑对象；根据各可疑对象的强引用状态，从各可疑对象中确定泄漏对象，强引用状态用于指示是否存在强应用，强引用表示能确保其引用的对象不会被垃圾回收器回收的引用。据此，基于目标监测对象的业务逻辑状态、弱引用状态以及强引用状态来检测是否存在内存泄漏，检测结果不依赖泄漏对象的数量及内存占用量，即使泄漏对象的数量和内存占用量小，也能够被检测到，从而提高检测准确性。此外，上述内存泄漏检测方法可以通过代码形式嵌入到应用程序内部，无需人工介入就能够在应用程序运行过程中以较少的性能开销实时地监测内存使用情况，提高检测效率，有利于快速发现并修复内存泄漏问题。

在一个实施例中，如图3所示，提供了一个实施例中对象注册的流程示意图。通过实例化将需要被监测的对象注册到监测对象池，内存泄漏检测程序作为内部检测工具嵌入到应用程序内部，检测工具被调用时开启检测线程，遍历监测对象池中的每一个对象，判断其是否为泄露对象。为提高易用程度，检测工具使用了懒初始化的方案，即用户无需事先显示初始化检测工具，仅在检测工具在首次被调用时在内部完成初始化工作，启动后台检测线程，为内存泄漏检测作好准备。

在一个实施例中，在进行对象注册时，对于每个需要被监测的对象，提供的信息需要包括：该对象的实例、该对象所引用的根对象、以及该对象在业务逻辑中有效性的判断方法。

其中，根对象可以作为根节点，为后续的内存扫描提供扫描入口，在实际使用中，根对象可能是引擎实例、框架实例、场景实例等。对象在业务逻辑中有效性的判断方法可以结合实际场景进行设置，举例来说，可以通过判断用户是否已经离线来判断用户实例是否已经在业务逻辑中失效。

在一个实施例中，监测应用程序中各目标监测对象的业务逻辑状态以及弱引用状态的步骤，具体可以包括：调用业务逻辑检查接口，监测应用程序中各目标监测对象的业务逻辑状态；借助弱引用机制，监测应用程序中各目标监测对象的弱引用状态。

在对象注册时提供了业务逻辑检查接口，用于判断对象在业务逻辑中是否有效。对于每一个目标监测对象，调用该目标监测对象对应的业务逻辑检查接口，监测该目标监测对象的业务逻辑状态，用以判断该目标监测对象的业务逻辑有效还是失效。

弱引用机制是一种间接感知对象是否被垃圾回收器回收的机制，如果一个对象只被弱引用所引用，则该对象被认为是不可访问(或弱可访问)的，并因此可能在任何时刻被回收。对于每一个目标监测对象，借助弱引用及引用队列机制，监测该目标监测对象的弱引用状态，用以判断该目标监测对象是否存在弱引用。

在一个实施例中，在根据各可疑对象的强引用状态，从各可疑对象中确定泄漏对象的步骤之前，还可以包括以下步骤：获取各可疑对象引用的根对象；从各可疑对象引用的根对象开始，对内存中指向各可疑对象的引用进行扫描，获得各可疑对象的强引用状态。

在对象注册时提供了对象引用的根对象，用于作为根节点为内存扫描提供扫描入口。调用内存对象布局扫描工具(例如Java Object Layout,JOL)，从根对象开始扫描每一个可疑对象，具体扫描内存中指向每一个可疑对象的引用，获得每一个可疑对象的强引用状态。

在一个实施例中，如图4所示，提供了一种内存泄漏检测方法，包括两个阶段：初步筛选阶段和扫描定位阶段。在初步筛选阶段，对于监测对象池中的目标监测对象，将业务逻辑有效或者弱引用失效的目标监测对象确定为正常对象，将业务逻辑失效且弱引用有效的目标监测对象确定为可疑对象，排除正常对象，保留可疑对象作为下一扫描定位阶段的输入。在扫描定位阶段，将不存在强引用的可疑对象确定为正常对象，将存在强引用的可疑对象确定为泄漏对象，完成内存泄漏检测流程。

上述实施例中，将内存泄漏检测分为两个阶段，通过开销较小的第一阶段完成对目标监测对象的快速筛选，用以降低开销较大的第二阶段的扫描规模，从而降低整体的处理资源及内存开销。

在一个实施例中，在从各可疑对象中确定泄漏对象的步骤之后，还可以包括以下步骤：输出泄漏对象的引用路径至日志文件。

在确定检测到泄漏对象后，可以借助内存对象布局扫描工具，输出泄漏对象的引用路径至日志文件，相关工作人员通过查看日志找到泄漏对象的引用路径，并可以根据泄漏对象的引用路径查找代码中对该引用路径下对象的相关代码引用，找到不恰当的或者遗漏的写操作，进行内存泄漏问题修复。

在一个实施例中，在从各可疑对象中确定泄漏对象的步骤之后，还可以包括以下步骤：发出告警提示。

在确定检测到泄漏对象后，触发实时告警机制，发出告警提示，具体可以在相关工作人员的即时通信软件中弹出告警提示，告警提示中可以包括泄漏对象所在的服务器标识(如服务器名称)，用以指引相关工作人员前往对应的服务器上查看详细日志，并作进一步处理。告警提示中还可以进一步包括泄漏对象所在的进程标识(如进程名称)以及时间，有助于更为快速地找到内存泄漏问题并修复。

在一个实施例中，如图5所示，提供了一个实施例中检测到泄露对象后的处理步骤流程示意图，在确定检测到泄漏对象后，输出泄漏对象的引用路径至日志文件，并发送告警提示至即时通讯软件。据此，一旦检测到发生内存泄漏，立即触发告警提示，引导相关工作人员着手处理，使内存泄漏问题能够得到快速修复。

在一个实施例中，如图6所示，提供了一种内存泄漏检测方法，包括以下步骤S601至步骤S605。

S601，在应用程序运行过程中，调用业务逻辑检查接口监测应用程序中各目标监测对象的业务逻辑状态，借助弱引用机制监测应用程序中各目标监测对象的弱引用状态。

S602，将业务逻辑状态为业务逻辑失效且弱引用状态为弱引用有效的目标监测对象，确定为可疑对象。

S603，获取各可疑对象引用的根对象，从各可疑对象引用的根对象开始，对内存中指向各可疑对象的引用进行扫描，获得各可疑对象的强引用状态。

S604，将强引用状态为存在强引用的可疑对象，确定为泄漏对象。

S605，输出泄漏对象的引用路径至日志文件，发送告警提示至即时通讯软件。

对于步骤S601至步骤S605的具体限定可以参考上文实施例，此处不再赘述。本实施例中，基于目标监测对象的业务逻辑状态、弱引用状态以及强引用状态来检测是否存在内存泄漏，检测结果不依赖泄漏对象的数量及内存占用量，即使泄漏对象的数量和内存占用量小，也能够被检测到，从而提高检测准确性。上述内存泄漏检测方法可以通过代码形式嵌入到应用程序内部，无需人工介入就能够在应用程序运行过程中以较少的性能开销实时地监测内存使用情况，提高检测效率，有利于快速发现并修复内存泄漏问题。此外，一旦检测到发生内存泄漏，立即触发告警提示，引导相关工作人员着手处理，使内存泄漏问题能够得到快速修复。

应该理解的是，虽然上述实施例涉及的各流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述实施例涉及的各流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图7所示，提供了一种内存泄漏检测装置700，该装置可以采用软件模块或硬件模块，或者是二者的结合成为计算机设备的一部分，该装置具体包括：监测模块710、可疑对象确定模块720和泄漏对象确定模块730，其中：

监测模块710，用于在应用程序运行过程中，监测应用程序中各目标监测对象的业务逻辑状态以及弱引用状态，弱引用状态用于指示是否存在弱引用，弱引用表示不能确保其引用的对象不会被垃圾回收器回收的引用。

可疑对象确定模块720，用于根据各目标监测对象的业务逻辑状态以及弱引用状态，从各目标监测对象中确定可疑对象。

泄漏对象确定模块730，用于根据各可疑对象的强引用状态，从各可疑对象中确定泄漏对象，强引用状态用于指示是否存在强应用，强引用表示能确保其引用的对象不会被垃圾回收器回收的引用。

在一个实施例中，监测模块710在监测应用程序中各目标监测对象的业务逻辑状态以及弱引用状态时，具体用于：调用业务逻辑检查接口，监测应用程序中各目标监测对象的业务逻辑状态；借助弱引用机制，监测应用程序中各目标监测对象的弱引用状态。

在一个实施例中，可疑对象确定模块720在根据各目标监测对象的业务逻辑状态以及弱引用状态，从各目标监测对象中确定可疑对象时，具体用于：将业务逻辑状态为业务逻辑失效且弱引用状态为弱引用有效的目标监测对象，确定为可疑对象。

在一个实施例中，该装置还包括扫描模块，用于：获取各可疑对象引用的根对象；从各可疑对象引用的根对象开始，对内存中指向各可疑对象的引用进行扫描，获各得可疑对象的强引用状态。

在一个实施例中，泄漏对象确定模块730在根据各可疑对象的强引用状态，从各可疑对象中确定泄漏对象时，具体用于：将强引用状态为存在强引用的可疑对象，确定为泄漏对象。

在一个实施例中，该装置还包括输出模块，用于输出泄漏对象的引用路径至日志文件。

在一个实施例中，该装置还包括告警模块，用于发出告警提示。

关于内存泄漏检测装置的具体限定可以参见上文中对于内存泄漏检测方法的限定，在此不再赘述。上述内存泄漏检测装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种内存泄漏检测方法。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种内存泄漏检测方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图8和图9中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法实施例中的步骤。

需要理解的是，上述实施例中的术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。