CN111124822B - 游戏中的信息监测方法、装置及电子设备 - Google Patents

Abstract

本发明提供了一种游戏中的信息监测方法、装置及电子设备，涉及信息监测的技术领域，该方法包括：响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数；若距添加弱引用函数的时间达到指定时长，调用弱引用函数；基于弱引用函数的返回值判断用户实体是否被实际销毁；获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态；周期性统计游戏中处于未销毁状态的用户实体的数量；根据统计得到的数量生成监测结果。本发明提供的游戏中的信息监测方法、装置及电子设备，在一定程度上避免了游戏服务器出现内存泄露的情况，同时，也缓解了游戏逻辑的卡顿，提高了用户对游戏的体验度。

Description

游戏中的信息监测方法、装置及电子设备

技术领域

本发明涉及信息监测技术领域，尤其是涉及一种游戏中的信息监测方法、装置及电子设备。

背景技术

网络游戏的游戏服务端承载了网络游戏的主要内容，在游戏中扮演着非常重要的角色。游戏服务端长期运行，其内存泄露带来的问题一直影响着游戏服务端的开发。游戏服务端的内存问题一直是需要密切关注的，内存泄露，资源未及时销毁等问题都会造成内存暴涨，当内存超过能够容纳的范围时，就会出现进程崩溃、服务器宕机等事故，进而带来很大的损失。

目前，现有技术中多采用离线式的工具对内存泄露进行查找和定位，虽然也有一些在线对内存进行管理的工具，然而，这些方式对服务器的性能要求比较高，难以对所有的游戏服务端进行内存管理，导致内存处理不及时，引起游戏逻辑的卡顿，影响了玩家的体验。

发明内容

有鉴于此，本发明的目的在于提供一种游戏中的信息监测方法、装置及电子设备，以缓解上述技术问题。

第一方面，本发明实施例提供了一种游戏中的信息监测方法，该方法应用于游戏服务器，该方法包括：响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数；若距添加弱引用函数的时间达到指定时长，调用弱引用函数；基于弱引用函数的返回值判断用户实体是否被实际销毁；获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态；周期性统计游戏中处于未销毁状态的用户实体的数量；根据统计得到的数量生成监测结果。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，上述基于弱引用函数的返回值判断用户实体是否被实际销毁的步骤，包括：如果返回值为None，确定用户实体被实际销毁；如果返回值不为None，确定用户实体未被实际销毁。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，上述添加调用用户实体的弱引用函数的步骤之后，上述方法还包括：启动用户实体对应的计时器；其中，计时器的时长为指定时长。

结合第一方面，本发明实施例提供了第一方面的第三种可能的实施方式，其中，上述周期性统计游戏中处于未销毁状态的用户实体的数量的步骤之后，上述方法还包括：将统计出的数量存储至预设数据库，其中，统计出的数量包括指定进程中处于未销毁状态的用户实体的数量。

结合第一方面的第三种可能的实施方式，本发明实施例提供了第一方面的第四种可能的实施方式，其中，上述根据统计得到的数量生成监测结果的步骤，包括：从预设数据库获取当前处于未销毁状态的用户实体的数量；如果数量超过设定阈值，生成包含有报警提示信息的监测结果。

结合第一方面的第四种可能的实施方式，本发明实施例提供了第一方面的第五种可能的实施方式，其中，上述报警提示信息包括指定进程中处于未销毁状态的用户实体的数量。

结合第一方面的第三种可能的实施方式，本发明实施例提供了第一方面的第六种可能的实施方式，其中，上述方法还包括：将预设数据库中存储的数量和用户实体的标识信息添加至进程日志中。

第二方面，本发明实施例还提供一种游戏中的信息监测装置，该装置应用于游戏服务器，该装置包括：添加模块，用于响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数；调用模块，用于若距添加弱引用函数的时间达到指定时长，调用弱引用函数；判断模块，用于基于弱引用函数的返回值判断用户实体是否被实际销毁；标记模块，用于获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态；统计模块，用于周期性统计游戏中处于未销毁状态的用户实体的数量；生成模块，用于根据统计得到的数量生成监测结果。

第三方面，本发明实施例还提供一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法的步骤。

第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述第一方面所述的方法的步骤。

本发明实施例带来了以下有益效果：

本发明实施例提供的游戏中的信息监测方法、装置及电子设备，能够响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数，并在距添加弱引用函数的时间达到指定时长时，调用弱引用函数，并基于弱引用函数的返回值判断用户实体是否被实际销毁，以及，获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态，周期性统计游戏中处于未销毁状态的用户实体的数量；进而根据统计得到的数量生成监测结果，该监测结果可以用于对游戏服务器中的用户实体进行监测，尤其是逻辑上销毁，但还实际占用内存的用户实体，在一定程度上避免了游戏服务器出现内存泄露的情况，同时，也缓解了游戏逻辑的卡顿，提高了用户对游戏的体验度。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

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

图1为本发明实施例提供的一种游戏中的信息监测方法的流程图；

图2为本发明实施例提供的另一种游戏中的信息监测方法的流程图；

图3为本发明实施例提供的一种游戏中的信息监测装置的结构示意图；

图4为本发明实施例提供的另一种游戏中的信息监测装置的结构示意图；

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

具体实施方式

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

目前，网络游戏的网络连接模式主要有P2P(Peer to Peer Computing，对等计算模式)和CS(Client/Server，客户机和服务器)两种模式。其中P2P模式类型的游戏有着很大的局限性，目前，网络游戏的连接模式还是CS模式居多，即，游戏服务端接收来自玩家的客户端发起的连接，承载了游戏的主要内容，在游戏中扮演着非常重要的角色。

游戏服务端长期运行时，资源未及时销毁的情况往往会导致内存暴涨，超过能够容纳的范围时就会出现进程崩溃、服务器宕机等事故，带来很大的损失。

通常，在线人数系统会对每组服务器的玩家实体数量进行统计，然而不能监控已经销毁的玩家实体的数量。如果以普通的方式管理已经销毁的玩家实体，便会对实体产生新的引用，阻碍实体的销毁。现有技术中，大部分的实体监测过程是离线式的，即，在离线时对内存泄露进行查找和定位。虽然也有一些在线对内存进行监测的profile的工具，然而对服务器性能要求比较高，因此，会选择少量的服务器开启，一般不会对所有线上服务器打开。

此外，还有减少GC(Garbage Collection，垃圾回收)机制间隔的方式，也能及时清理一部分玩家实体，但是，这种方式只能对“与”循环引用起作用，同时，也会增加CPU的消耗，导致GC的时候可能会引起游戏逻辑的卡顿，影响玩家的体验，并且，在服务器高负载下不能够使用，然而，在服务器处于高负载时，很容易出现玩家的实体泄露。

基于此，本发明实施例提供的一种游戏中的信息监测方法、装置及电子设备来监测用户实体的数量，以缓解上述技术问题。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种游戏中的信息监测方法进行详细介绍。

在一种可能的实施方式中，本发明实施例提供了一种游戏中的信息监测方法，该方法应用于游戏服务器，具体地，如图1所示的一种游戏中的信息监测方法的流程图，该方法包括以下步骤：

步骤S102，响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数；

具体地，用户实体是由玩家登陆游戏客户端创建游戏账户而在服务器上生成，并用于记录玩家的游戏账号对应游戏角色的所有数据，例如，游戏角色等级、战斗数据、帮派、技能数据、道具等等，因此，海量用户的相关游戏数据将在游戏服务器上占用相当大的存储空间。用户下线一段时间后，例如，1年内，如未再次登录游戏服务器，则视为玩家放弃该游戏账号，服务器中相应存储的用户实体便无需继续存在，可以将其释放掉给其他的用户数据。

弱引用函数是基于弱引用机制实现的，弱引用机制可以用来在不增加对实体引用的方式再指向实体，在实体销毁之后，通过弱引用方式不再能取得实体，因此，这种指向不会像普通引用那样，阻碍实体的销毁，而本发明实施例中，通过上述步骤S102添加弱引用函数的方式，可以对角色已下线的用户实体进行监测。

步骤S104，若距添加弱引用函数的时间达到指定时长，调用弱引用函数；

步骤S106，基于弱引用函数的返回值判断用户实体是否被实际销毁；

步骤S108，获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态；

具体地，该步骤中是对未被实际销毁的用户实体进行标记的过程，即，如果上述步骤S106中判断出用户实体未被实际销毁，则可以获取到该用户实体并对实体的状态进行标记。

在实际使用时，用户实体对应的角色在下线之后，由于用户实体中存放的数据较多，因此，游戏服务器在对用户实体销毁时，会有一定的时间延迟，如果此时立即去调用弱引用函数来判断是否被实际销毁时，则会出现大量的应该被销毁，而实际还未被销毁的用户实体，因此，为了避免用户实体被误标记为未销毁状态，在步骤S104中，采取延时调用弱引用函数的方式，即，当前时间距添加弱引用函数的时间达到指定时长时在调用弱引用函数，如10s、20s、30s或者更长等等，具体可以根据实际情况进行设置，本发明实施例对此不进行限制。

步骤S110，周期性统计游戏中处于未销毁状态的用户实体的数量；

步骤S112，根据统计得到的数量生成监测结果。

通常，在线人数系统会对在线用户实体数量以及下线后应销毁但却未销毁的实体数量进行监测和统计，因此，当监测到用户实体对应的角色的下线时，可以将该角色的下线信息传递给游戏服务器，以便于在用户下线一段时间后执行用户实体的销毁过程，以释放相应的内存。

然而，用户实体销毁的过程并不能完全顺利进行，一些常见的逻辑开发，如数据库访问的异步回调，定时器的回调函数等会阻碍用户实体的内存释放过程，而本发明实施例记载的上述方法，通过对用户实体添加弱引用函数来对游戏中用户实体进行监测的过程，则可以有效避免阻碍用户实体的内存释放过程。

因此，本发明实施例提供的游戏中的信息监测方法，能够响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数，并在距添加弱引用函数的时间达到指定时长时，调用弱引用函数，并基于弱引用函数的返回值判断用户实体是否被实际销毁，以及，获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态，周期性统计游戏中处于未销毁状态的用户实体的数量；进而根据统计得到的数量生成监测结果，该监测结果可以用于对游戏服务器中的用户实体进行监测，尤其是逻辑上销毁，但还实际占用内存的用户实体，在一定程度上避免了游戏服务器出现内存泄露的情况，同时，也缓解了游戏逻辑的卡顿，提高了用户对游戏的体验度。

在计算机程序设计中，弱引用机制与强引用机制相对，是指不能确保其引用的对象不会被垃圾回收器回收的引用。一个对象若只被弱引用所引用，则被认为是不可访问(或弱可访问)的，并因此可能在任何时刻被回收。一些配有垃圾回收机制的语言，如Java、C#、Python、Perl、Lisp等都在不同程度上支持弱引用机制。

而本发明实施例中，以Python语言为例进行说明，将Python语言作为游戏服务端的主要业务开发语言具有很多优势，如，方便进行热更新、开发迭代速度快、方便和游戏服务端引擎C/C++代码做交互等等，因此，越来越多的游戏服务端采用Python语言作为服务端的业务开发语言。

具体地，Python语言采用引用计数的方式管理内存对象，逻辑层面执行destroy相关函数时，只是想解除对本实体的引用，让它可以销毁，释放出的内存可以给新的实体使用。Python中的弱引用机制，常常用来在不增加对实体引用的方式再指向实体，这种指向不会像普通引用那样，会阻碍实体的销毁。在实体销毁之后，通过弱引用机制不再能取得实体，取而代之是None，这种性质，可以被用来监测游戏中占用很大内存的用户实体的销毁情况。

因此，上述步骤S106中判断实体是否被实际销毁的过程，可以通过弱引用函数的返回值来进行判断。具体地，如果返回值为None，则确定用户实体被实际销毁，内存已经可以给其它用户实体复用；反之，如果返回值不为None，则确定用户实体未被实际销毁，该用户实体仍然在内存中，然后再通过周期性统计游戏中处于未销毁状态的用户实体的数量的方式来对用户实体的销毁情况进行监测。

进一步，在调用弱引用函数时的延时操作，可以通过计时器实现，例如，在添加弱引用函数可以相应的带上时间戳以记录添加弱引用函数的时间等等，因此，本发明实施例还提供了另一种游戏中的信息监测方法，对弱引用机制下对用户实体的监测过程进行说明。

考虑到Python语言多作为游戏服务端的主要业务开发语言，因此，本发明实施例中，也以Python语言的弱引用函数为例进行说明，为了便于理解，首先举几个例子来说明游戏服务端中常见的阻碍用户实体内存释放的情形，例如，定时器的应用，Python语言中，定时器的定义可以为：self.timer＝Timer.addRepeatTimer(600,self.request_global_email)，销毁该定时器时，可以通过下述编程语句：

self.timer.cancel()

self.timer＝None；

对于这种定时器的定义，必须得在用户实体销毁的同时匹配上对应定时器的销毁，否则在用户实体销毁时，便会被定时器锁住，导致用户实体的引用计数永远不会减到0，从而永久存在内存中；

进一步，对于数据库访问的例子：游戏中常常需要访问数据库中的数据，常见的游戏服务端不会去阻塞等待数据库的访问的返回，等待返回的这段时间还可以被用来执行其它的业务逻辑代码提高服务器的并发能力，因此，需要记录下数据库返回后将数据交给哪一个对象的某个函数逻辑进行处理，一种常见的方案是，定义一个数据库回调函数，给其分配一个ID，以键值对的方式存在本地的一个字典中。

在数据库访问返回时，通过ID找到对应的函数，把返回的数据库数据作为参数调用之。然而在数据库访问量过大，性能下降时，需要很久才能返回，更有甚者直接没有返回。这时用户实体便会被这个回调函数引用住。

此外，还有循环引用的例子：Python代码中A引用到B，B引用到C，C在引用回A之类的例子也是经常存在，称之为循环引用。用户实体被陷入循环引用中，需要等待GC来清理循环引用，回收掉其中的用户实体，使得其内存可以重复利用，然而，等待GC来释放循环引用中用户实体的过程中，积压的实体会越来越多，占用的内存也越来越多。

对于上述几种阻碍用户实体内存释放的情形，均可以通过本发明实施例提供的用户实体的监测方法来监测用户实体的销毁情况，使游戏的用户，或者游戏开发人员能够在内存泄露的初期便发现，可以为处理游戏服务器线上内存泄露争取时间。

具体地，如图2所示的另一种游戏中的信息监测方法的流程图，该方法包括以下步骤：

步骤S202，响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数；

具体实现时，可以将该用户实体注册至弱引用管理器，通过弱引用管理器来对添加的弱引用函数进行管理。

步骤S204，启动用户实体对应的计时器；

其中，本发明实施例中的计时器的时长为指定时长，该指定时长即为弱引用函数延时调用的时长，如前述实施例提到的10s、20s、30s或者更长时间等等，具体地，可以在添加弱引用函数时，为用户实体打上时间戳，作为计时器的启动信号来启动计时器。

步骤S206，若距添加弱引用函数的时间达到指定时长，调用弱引用函数；

步骤S208，基于弱引用函数的返回值判断用户实体是否被实际销毁；如果是，执行步骤S212；如果否，执行步骤S210；

具体地，在用户实体销毁之后，通过弱引用函数不再能取得该用户实体，取而代之是None，因此，如果返回值为None，则确定用户实体被实际销毁，内存已经可以给其它用户实体复用，此时，可以继续执行步骤S212；反之，如果返回值不为None，则确定用户实体未被实际销毁，该用户实体仍然在内存中，即，执行步骤S210的过程，将该用户实体标记为未销毁状态。

步骤S210，获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态；

步骤S212，周期性统计游戏中处于未销毁状态的用户实体的数量；

此外，为了避免游戏服务器一直去监测未销毁状态的用户实体，在将用户实体标记为未销毁状态之后，上述步骤S212中，通常是周期性地统计当前游戏进程中未销毁状态的用户实体的数量。如每隔5min去检查进程中未销毁的用户实体的数量等等，具体地，该时间周期可以根据实际使用情况进行设置，本发明实施例对此不进行限制。

进一步，在周期性统计完一次处于未销毁状态的用户实体的数量之后，还可以将统计结果进行存储，以便于实时查看进程中的未销毁的用户实体的数量，也方便和游戏服务器内存增加做一些交互验证，具体存储过程可以按照下述步骤是214执行。

步骤S214，将统计出的数量存储至预设数据库；

在实际使用时，上述统计出的数量通常包括指定进程中处于未销毁状态的用户实体的数量，上述预设数据库是一个单独的数据库，专用于存储上述统计出的数量。

进一步，当得到上述统计的数量之后，可以根据统计得到的数量生成监测结果，具体地，生成监测结果的具体过程可以按照下述步骤S216～步骤S220进行。

步骤S216，从预设数据库获取当前处于未销毁状态的用户实体的数量；

步骤S218，判断数量是否超过设定阈值；如果是，执行步骤S220；如果否，返回步骤S212；

在实际使用时，上述步骤S218的判断过程，与前述步骤S212的周期性统计过程类似，也是为了避免游戏服务器一直去监测未销毁状态的用户实体，通过设定一个数量阈值，可以允许游戏进程中存在一定数量的处于未销毁状态的用户实体，如果步骤S212中统计得到的数量未超过设定阈值，则不进行后续操作，继续等待下一个统计周期；当处于未销毁状态的用户实体的数量超高该设定阈值之后，再生成报警提示信息，提示用户或者游戏开发人员进行相应的处理过程。

具体地，该设定阈值可以是20、50、60等等，具体的设定阈值可以根据实际游戏，以及游戏服务器的实际内存进行设置，本发明实施例对此不进行限制。

步骤S220，生成包含有报警提示信息的监测结果；

具体地，本发明实施例中，报警提示信息包括指定进程中处于未销毁状态的用户实体的数量，以便于将报警提示信息发送给游戏开发人员，提醒游戏开发人员进行处理，游戏开发人员也可以通过这些指向它们的弱引用，找到指定进程中未被销毁的用户实体，对这些未被销毁的用户实体进行一些操作，来缓解内存的压力。

进一步，上述监测结果可以由服务器发送至云端，测试人员既可以通过网页访问云端获取监测结果，也可以定时下载至测试客户端，并在测试人员的设备上显示该监测结果。

此外，上述监测结果也可以通过在线人数系统进行显示，如，在线人数系统定期读取上述预设数据库中的数据，显示在网页上，具体地，在显示时，对每个游戏进程，都可以显示本进程在线玩家用户的数量，待销毁的用户实体的数量，以及处于未销毁状态的用户实体的数量，其中，待销毁的用户实体的数量通常是指用户实体对应的角色的下线之后，添加的弱引用函数被调用之前的数量处于未销毁状态的用户实体的数量，通常也称其为存在超过一定时间的用户实体的数量。

进一步，在进行监测结果展示时，还可以根据周期性的统计结果生成处于未销毁状态的用户实体的数量的变化曲线，以方便游戏开发人员的查看。

此外，还可以将预设数据库中存储的数量和用户实体的标识信息添加至进程日志中，通过日志进行记录的方式，可以便于有针对性的处理内存泄露相关的问题，并且，为了便于对未销毁状态的用户实体进行查看和销毁，上述标识信息可以包括“id”、“name”、“time”“expire”、“undestroyed”、“online”、“hostnum”，以及“login”等信息。

综上，本发明实施例提供的游戏中的信息监测方法，通过监控处于未销毁状态的用户实体的数量，可以直观的与游戏服务器内存对比，查看排除掉其它内存泄露的可能，有针对性的处理内存泄露相关的问题，并且，可以以此为依据，判断是否有某些业务在用户实体对应的角色的下线之后还有可能引用住用户实体，阻碍用户实体销毁的情况，比如等待数据库返回，定时器未解引用等，在处于未销毁状态的用户实体的数量超过设定阈值之后，生成包含有报警提示信息的监测结果，并在游戏服务器的服务端界面上展示的过程，在重大内存泄露的初期便可以发现，从而为处理游戏服务器线上内存泄露争取时间。

在上述实施方式的基础上，本发明实施例还提供了一种游戏中的信息监测装置，该装置应用于游戏服务器，如图3所示的一种游戏中的信息监测装置的结构示意图，该装置包括以下模块：

添加模块30，用于响应针对于用户实体对应的角色的下线操作，添加调用用户实体的弱引用函数；

调用模块32，用于若距添加弱引用函数的时间达到指定时长，调用弱引用函数；

判断模块34，用于基于弱引用函数的返回值判断用户实体是否被实际销毁；

标记模块36，用于获取未被实际销毁的用户实体，并将未被实际销毁的用户实体的状态标记为未销毁状态；

统计模块38，用于周期性统计游戏中处于未销毁状态的用户实体的数量；

生成模块40，用于根据统计得到的数量生成监测结果。

进一步，上述判断模块还用于：如果返回值为None，确定用户实体被实际销毁；如果返回值不为None，确定用户实体未被实际销毁。

进一步，在图3的基础上，图4示出了另一种游戏中的信息监测装置的结构示意图，该装置还包括：

启动模块42，用于添加调用用户实体的弱引用函数的步骤之后，启动用户实体对应的计时器；其中，计时器的时长为指定时长。

进一步，如图4所示，上述装置还包括：

存储模块44，用于周期性统计游戏中处于未销毁状态的用户实体的数量的步骤之后，将统计出的数量存储至预设数据库。

进一步，上述生成模块40用于：从预设数据库获取当前处于未销毁状态的用户实体的数量；如果数量超过设定阈值，生成包含有报警提示信息的监测结果。

具体地，上述报警提示信息包括指定进程中处于未销毁状态的用户实体的数量。

进一步，在图4所示的游戏中的信息监测装置的结构示意图中，还包括日志添加模块46：用于将预设数据库中存储的数量和用户实体的标识信息添加至进程日志中。

本发明实施例提供的游戏中的信息监测装置，其实现原理及产生的技术效果和前述游戏中的信息监测方法实施例相同，为简要描述，装置的实施例部分未提及之处，可参考前述方法实施例中相应内容，在此不再赘述。

本发明实施例还提供一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，处理器执行所述计算机程序时实现上述图1所示方法的步骤。

本发明实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述图1所示方法的步骤。

本发明实施例还提供了一种电子设备的结构示意图，如图5所示，为该电子设备的结构示意图，其中，该电子设备包括处理器51和存储器50，该存储器50存储有能够被该处理器51执行的计算机可执行指令，该处理器51执行该计算机可执行指令以实现上述游戏中的信息监测方法。

在图5示出的实施方式中，该电子设备还包括总线52和通信接口53，其中，处理器51、通信接口53和存储器50通过总线52连接。

其中，存储器50可能包含高速随机存取存储器(RAM，Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口53(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。总线52可以是ISA(IndustryStandard Architecture，工业标准体系结构)总线、PCI(Peripheral ComponentInterconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线52可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器51可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器51中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器51可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital SignalProcessor，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器51读取存储器中的信息，结合其硬件完成前述实施例的游戏中的信息监测方法的步骤。

本发明实施例所提供的游戏中的信息监测方法、装置及电子设备的计算机程序产品，包括存储了程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

另外，在本发明实施例的描述中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种游戏中的信息监测方法，其特征在于，所述方法应用于游戏服务器，所述方法包括：

响应针对于用户实体对应的角色的下线操作，添加调用所述用户实体的弱引用函数；其中，所述用户实体是由玩家登陆游戏客户端创建游戏账户而在服务器上生成，并用于记录玩家的游戏账号对应游戏角色的所有数据；

若距添加所述弱引用函数的时间达到指定时长，调用所述弱引用函数；

基于所述弱引用函数的返回值判断所述用户实体是否被实际销毁；

获取未被实际销毁的所述用户实体，并将所述未被实际销毁的所述用户实体的状态标记为未销毁状态；

周期性统计所述游戏中处于未销毁状态的用户实体的数量；

根据统计得到的所述数量生成监测结果。

2.根据权利要求1所述的方法，其特征在于，基于所述弱引用函数的返回值判断所述用户实体是否被实际销毁的步骤，包括：

如果所述返回值为None，确定所述用户实体被实际销毁；

如果所述返回值不为None，确定所述用户实体未被实际销毁。

3.根据权利要求1所述的方法，其特征在于，添加调用所述用户实体的弱引用函数的步骤之后，所述方法还包括：启动所述用户实体对应的计时器；其中，所述计时器的时长为所述指定时长。

4.根据权利要求1所述的方法，其特征在于，周期性统计所述游戏中处于未销毁状态的用户实体的数量的步骤之后，所述方法还包括：

将统计出的所述数量存储至预设数据库，其中，统计出的所述数量包括指定进程中处于未销毁状态的用户实体的数量。

5.根据权利要求4所述的方法，其特征在于，根据统计得到的所述数量生成监测结果的步骤，包括：

从所述预设数据库获取当前处于未销毁状态的用户实体的数量；

如果所述数量超过设定阈值，生成包含有报警提示信息的监测结果。

6.根据权利要求5所述的方法，其特征在于，所述报警提示信息包括指定进程中处于未销毁状态的用户实体的数量。

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

将所述预设数据库中存储的所述数量和所述用户实体的标识信息添加至进程日志中。

8.一种游戏中的信息监测装置，其特征在于，所述装置应用于游戏服务器，所述装置包括：

添加模块，用于响应针对于用户实体对应的角色的下线操作，添加调用所述用户实体的弱引用函数；其中，所述用户实体是由玩家登陆游戏客户端创建游戏账户而在服务器上生成，并用于记录玩家的游戏账号对应游戏角色的所有数据；

调用模块，用于若距添加所述弱引用函数的时间达到指定时长，调用所述弱引用函数；

判断模块，用于基于所述弱引用函数的返回值判断所述用户实体是否被实际销毁；

标记模块，用于获取未被实际销毁的所述用户实体，并将所述未被实际销毁的所述用户实体的状态标记为未销毁状态；

统计模块，用于周期性统计所述游戏中处于未销毁状态的用户实体的数量；

生成模块，用于根据统计得到的所述数量生成监测结果。

9.一种电子设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述权利要求1-7任一项所述的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述权利要求1-7任一项所述的方法的步骤。