CN109426601B - 一种对程序进行无状态检测的方法和装置 - Google Patents

Abstract

本公开是关于一种对程序进行无状态检测的方法和装置，属于软件编程技术领域。所述方法包括：当检测到针对目标程序进行无状态检测的触发操作后，执行所述目标程序；如果在执行所述目标程序的过程中，监测到所述目标程序的变量发生更改，且所述变量并非被执行所述目标程序所建立的初始线程所更改，则确定所述变量不符合无状态设计原则。通过本发明实施例提供的方法，在执行目标程序的过程中，如果监测到目标程序的变量发生更改，且变量并非被执行目标程序所建立的初始线程所更改，则确定变量不符合无状态设计原则。从根源对目标程序中不符合无状态设计原则的变量进行识别，无需人工进行检测，本发明实现了自动化检测的过程。

Description

一种对程序进行无状态检测的方法和装置

技术领域

本公开是关于软件编程技术领域，尤其是关于一种对程序进行无状态检测的方法和装置。

背景技术

在2000年Roy Fielding发表的博士论文《Architectural styles and thedesign of network-based software architectures(架构风格和基于网络的程序架构设计)》中，REST(Representational State Transfer，表征性状态转移)的概念被首次提出，REST是针对以网络服务为基础的程序所提出的，其中，以网络服务为基础的程序是指服务器为了响应客户端的请求所执行的程序。REST描述的是程序设计架构的约束条件和设计原则，如果一个程序的设计架构符合REST的约束条件和设计原则，那么该程序的设计架构就是RESTful架构。具有RESTful架构的程序比一般的程序更简洁，在客户端与服务器的交互过程中更易于实现缓存等机制。

要实现RESTful架构就需要满足RESTful架构设计所需的五大约束条件和设计原则。在上述五大约束条件和设计原则中，最重要的一个约束条件和设计原则，也是本文讨论的重点，就是：所有在服务器中的操作都是无状态的。如果满足上述条件，也就满足了无状态设计原则。

所谓无状态设计原则，是指服务器不能储存任何客户端的状态相关信息如用户名、密码信息。客户端向服务器发起的每次请求都是独立的，是不能依赖之前发起过的请求的。客户端向服务器发起的每次请求中应该包含服务器处理该请求所需要的全部信息。因此，所有客户端的状态相关信息都应该保存在客户端，在每次客户端向服务器发送请求时，都再发一次客户端的状态相关信息，服务器不需要保存任何客户端的状态相关信息。以此，可以节省服务器的内存空间，而且当一台服务器发生故障时，可以迅速以另一台备用服务器替换发生故障的服务器工作，同时客户端可以马上与备用服务器继续正常进行通信。通过以上可知，程序可以满足无状态设计原则的重要性非常高。

在实现本公开的过程中，发明人发现至少存在以下问题：

当程序员编写好一段程序之后，要怎么样进行程序的无状态检测呢？换句话说，要怎么样才能知道自己所编写的程序是不是满足无状态设计原则呢？或者，以前编写好的旧程序是不是满足无状态设计原则呢？在现有技术中，都是依靠人工对代码一行一行的去排查。然而对于规模庞大的程序代码，人为排查就显得不可靠了。

发明内容

为了克服相关技术中存在的问题，本公开提供了以下技术方案：

第一方面，提供了一种对程序进行无状态检测的方法，该方法包括：当检测到针对目标程序进行无状态检测的触发操作后，执行目标程序；如果在执行目标程序的过程中，监测到目标程序的变量发生更改，且变量并非被执行目标程序所建立的初始线程所更改，则确定变量不符合无状态设计原则。

通过本发明实施例提供的方法，在执行目标程序的过程中，如果监测到目标程序的变量发生更改，且变量并非被执行目标程序所建立的初始线程所更改，则确定变量不符合无状态设计原则。从根源对目标程序中不符合无状态设计原则的变量进行识别，无需人工进行检测，本发明实现了自动化检测的过程。

在一种可能的实现方式中，监测目标程序的变量是否发生更改，包括：通过JVMTI接口监测变量是否发生更改。

可以通过JVMTI接口监测变量是否发生更改。JVMTI接口是Java虚拟机的native编程接口，如果使用JVMTI接口就要涉及Java虚拟机底层的C(一种编程语言)层以及JNI(Javanative interface，Java本地接口)接口的内容。在实际应用中，可以建立一个代理Agent方式来使用JVMTI接口，Agent方式可以使用JVMTI接口的函数，设置回调函数，并从Java虚拟机中得到当前线程的运行态信息，最后还可以对Java虚拟机的运行态进行操作。

在一种可能的实现方式中，判断变量是否被执行目标程序所建立的初始线程所更改，包括：根据变量所属的变量类型，确定与变量对应的判断方式，并根据判断方式，判断变量是否被初始线程所更改，其中，判断方式是用于判断变量是否被初始线程所更改的方式。

根据变量的变量类型，确定与变量对应的判断变量是否被初始线程所更改的方式。

在一种可能的实现方式中，变量类型包括静态变量和成员变量。

在具体应用场景中，由于不同的变量类型对应的变量在使用中具有不同的特点，如静态变量可能会被全局程序修改，而成员变量只可能被对象修改，在对象应用完成之后会被销毁，成员变量也会被随之被销毁。所以，对于不同的变量要用不同的判断方式来判断变量是否被执行目标程序所建立的初始线程所更改。

在一种可能的实现方式中，根据变量的变量类型，确定与变量对应的判断方式，并根据判断方式，判断变量是否被初始线程所更改，包括：如果变量属于静态变量，则确定与静态变量对应的判断方式为：如果静态变量所属的类未装载于初始线程中，则静态变量并非被初始线程所更改；如果变量属于成员变量，则确定与成员变量对应的判断方式为：如果成员变量所属的对象未在初始线程中生成，则成员变量并非被初始线程所更改。

根据变量的变量类型，确定使用与变量对应的判断变量是否被初始线程所更改。

在一种可能的实现方式中，如果静态变量所属的类未装载于初始线程中，则静态变量并非被初始线程所更改，包括：确定初始线程对应的堆栈；如果在堆栈中未查找到静态变量所属的类，则静态变量所属的类未装载于初始线程中，静态变量并非被初始线程所更改；如果成员变量所属的对象未在初始线程中生成，则成员变量并非被初始线程所更改，包括：确定成员变量所属的对象所绑定的标签，如果在初始线程附加的标签列表中不存在标签，则成员变量所属的对象未在初始线程中生成，成员变量并非被初始线程所更改。

根据变量的变量类型，确定使用与变量对应的判断变量是否被初始线程所更改。对于静态变量，在执行目标函数时，静态变量所属的类是直接被装载于初始线程对应的堆栈中的，以准备被调用。因此，如果在初始线程对应的堆栈未查找到该静态变量的类，则该静态变量所属的类未装载于初始线程中，该静态变量并非被初始线程所更改。该静态变量很有可能是被客户端线程所更改的。对于成员变量，当监测到成员变量发生更改时，确定该成员变量所属的对象所绑定的标签，如果在初始线程附加的标签列表中不存在该标签，则成员变量所属的对象未在初始线程中生成，成员变量并非被初始线程所更改。在一种可能的实现方式中，标签列表存储于初始线程对应的局部存储器中。

为标签列表专门开辟一块空间进行存储。

在一种可能的实现方式中，该方法还包括：在开始执行目标程序的入口函数时，建立标签列表；当在执行目标程序的过程中，检测到发生对象创建事件时，将创建的对象绑定上标签；将标签存入标签列表中。

提供了标签列表的建立方式，和标签的存储方式。可以监测是否有对象被创建，在目标程序中，如果执行到带有关键字“new”的语句，可能会创建一个新的对象。当监测到发生对象创建事件时，可以将该对象绑定上标签，并将标签存入标签列表中。

第二方面，提供了一种对程序进行无状态检测的装置，该装置包括至少一个模块，该至少一个模块用于实现上述第一方面所提供的执行任务的方法。

第三方面，提供了一种服务器，该服务器包括处理器、存储器，处理器被配置为执行存储器中存储的指令；处理器通过执行指令来实现上述第一方面所提供的执行任务的方法。

第四方面，提供了计算机可读存储介质，包括指令，当所述计算机可读存储介质在服务器上运行时，使得所述服务器执行上述第一方面所述的方法。

第五方面，提供了一种包含指令的计算机程序产品，当所述计算机程序产品在服务器上运行时，使得所述服务器执行上述第一方面所述的方法。

上述本发明实施例第二到第五方面所获得的技术效果与第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。

本公开的实施例提供的技术方案可以包括以下有益效果：

通过本发明实施例提供的方法，在执行目标程序的过程中，如果监测到目标程序的变量发生更改，且变量并非被执行目标程序所建立的初始线程所更改，则确定变量不符合无状态设计原则。从根源对目标程序中不符合无状态设计原则的变量进行识别，无需人工进行检测，本发明实现了自动化检测的过程。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。在附图中：

图1是根据一示例性实施例示出的一种服务器的结构示意图；

图2是根据一示例性实施例示出的一种对程序进行无状态检测的方法的流程图；

图3是根据一示例性实施例示出的一种对程序进行无状态检测的流程图示意图；

图4是根据一示例性实施例示出的一种对程序进行无状态检测的应用示意图；

图5是根据一示例性实施例示出的一种对程序进行无状态检测的装置的示意图；

图6是根据一示例性实施例示出的一种对程序进行无状态检测的装置的示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

本发明实施例提供了一种对程序进行无状态检测的方法，该方法的执行主体可以为服务器。

图1是根据一示例性实施例示出的服务器1900的框图。参照图1，服务器1900包括处理器1922，以及由存储器1932所代表的存储器资源，用于存储可由处理器1922的执行的指令，例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理器1922被配置为执行指令，以执行对程序进行无状态检测的方法。

服务器1900还可以包括一个电源组件1926被配置为执行服务器1900的电源管理，一个有线或无线网络接口1950被配置为将服务器1900连接到网络，和一个输入输出(I/O)接口1958。服务器1900可以操作基于存储在存储器1932的操作系统，例如WindowsServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

服务器1900可以包括有存储器1932，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器1932中。

本公开一示例性实施例提供了一种对程序进行无状态检测的方法，如图2所示，该方法的处理流程可以包括如下的步骤：

步骤S210，当检测到针对目标程序进行无状态检测的触发操作后，执行目标程序。

其中，目标程序是指需要进行无状态检测的程序，目标程序一般是由Java(一种面向对象的编程语言)进行编程的。

在本发明实施例中，是使目标程序运行起来，在目标程序的运行过程中，监测目标程序的运行情况，来发现目标程序中违反无状态设计原则的相关代码。在运行完整个目标程序之后，将在目标程序运行过程中发现的问题一一输出在报告中，以提示程序员问题所在之处。在报告中，可以将产生问题的代码所在的文件、行号进行标识。

步骤S220，如果在执行目标程序的过程中，监测到目标程序的变量发生更改，且变量并非被执行目标程序所建立的初始线程所更改，则确定变量不符合无状态设计原则。

在服务器1900中，服务器1900在执行目标程序时，会建立相应的初始线程来执行目标程序。一台服务器1900一般会对应多个客户端，当每个客户端向服务器1900发送请求时，在服务器1900中会为每个请求专门建立一个客户端线程去处理这些请求。由于线程之间是可以交互的，因此客户端线程可以修改服务器1900的初始线程中的数据如目标程序运行中的变量。当服务器1900的程序的设计架构不满足无状态设计原则时，服务器1900需要将客户端的状态相关信息进行存储，那么客户端线程就要更改服务器1900的初始线程中的用于存储客户端的状态相关信息的变量，至此就会产生跨线程变量更改事件。故而，本发明实施例针对上述跨线程变量更改事件进行检测，以监测目标程序中不符合无状态设计原则的变量。

在实施中，在开始执行目标程序的入口函数时，利用代码注入技术，在不改变原有目标程序的情况下，可以将本实施例所述方法对应的代码注入到目标程序中，以在目标程序边执行的同时，边对目标程序进行监测。

可选地，监测目标程序的变量是否发生更改的步骤包括：通过JVMTI(JVM ToolInterface，Java虚拟机工具)接口监测变量是否发生更改。

其中，JVMTI接口是Java虚拟机所提供的本地(native)编程接口，是JVMPI(JavaVirtual Machine Profiler Interface，Java虚拟机分析接口)和JVMDI(Java VirtualMachine Debug Interface，Java虚拟机调试接口)的更新版本。从JVMTI接口的发展历史轨迹中就可以知道，JVMTI接口提供了分析和调试Java程序的功能。与此同时，在Java第五版本中，JVMTI接口也增加了监听(Monitoring)、线程分析(Thread analysis)以及覆盖率分析(Coverage Analysis)等功能。JVMTI接口的强大功能使得一些Java调试器以及其它Java运行态测试与分析工具的实现。

JVMTI接口是Java虚拟机的native编程接口，如果使用JVMTI接口就要涉及Java虚拟机底层的C层以及JNI接口的内容。在实际应用中，可以建立一个代理Agent方式来使用JVMTI接口，Agent方式可以使用JVMTI接口的函数，设置回调函数，并从Java虚拟机中得到当前线程的运行态信息，最后还可以对Java虚拟机的运行态进行操作。

在实施中，当执行目标程序时，会装载目标程序中的类，对于类中的变量，可以通过JVMTI接口进行监测。如图3所示，在Java层，目标程序从入口函数处开始执行。在C层，通过JVMTI接口实时监测目标程序中的变量是否发生更改。当监测到变量发生更改时，通过JVMTI接口将更改的变量发送到无状态检测识别引擎中的识别器中。在识别器中，可以判断更改的变量是否被执行目标程序所建立的初始线程所更改，确定该变量符不符合无状态设计原则。

需要说明的是，在具体执行上述方法的过程中，服务器1900是先加载C层的内容，再去加载Java层的内容的。

可选地，变量存在多种，对于不同的变量类型应有不同的监测处理方式。相应地，判断变量是否被执行目标程序所建立的初始线程所更改的步骤包括：根据变量所属的变量类型，确定与变量对应的判断方式，并根据判断方式，判断变量是否被初始线程所更改，其中，判断方式是用于判断变量是否被初始线程所更改的方式。

可选地，变量类型包括静态变量和成员变量。

需要说明的是，在具体应用场景中，由于不同的变量类型对应的变量在使用中具有不同的特点，如静态变量可能会被全局程序修改，而成员变量只可能被对象修改，在对象应用完成之后会被销毁，成员变量也会被随之被销毁。所以，对于不同的变量要用不同的判断方式来判断变量是否被执行目标程序所建立的初始线程所更改。以下针对静态变量和成员变量这两种变量类型分别进行判断变量是否被执行目标程序所建立的初始线程所更改的方式的说明：

可选地，根据变量的变量类型，确定与变量对应的判断方式，并根据判断方式，判断变量是否被初始线程所更改的步骤包括：

首先，如果变量属于静态变量，则确定与静态变量对应的判断方式为：如果静态变量所属的类未装载于初始线程中，则静态变量并非被初始线程所更改。

在实施中，当监测到变量发生更改，接下来就可以判断该更改的变量所述的变量类型，如果是静态变量，则判断静态变量所属的类是否装载于初始线程中。

其次，如果变量属于成员变量，则确定与成员变量对应的判断方式为：如果成员变量所属的对象未在初始线程中生成，则成员变量并非被初始线程所更改。

在实施中，当监测到变量发生更改，依然判断该更改的变量所述的变量类型，如果是成员变量，则判断成员变量所属的对象是否在初始线程中生成。

可选地，接下来提供的方法可以用于判断静态变量所属的类是否装载于初始线程中或者成员变量所属的对象是否在初始线程中生成。

相应地，如果静态变量所属的类未装载于初始线程中，则静态变量并非被初始线程所更改的步骤包括：确定初始线程对应的堆栈；如果在堆栈中未查找到静态变量所属的类，则静态变量所属的类未装载于初始线程中，静态变量并非被初始线程所更改。

在实施中，在执行目标函数时，静态变量所属的类是直接被装载于初始线程对应的堆栈中的，以准备被调用。因此，如果在初始线程对应的堆栈未查找到该静态变量的类，则该静态变量所属的类未装载于初始线程中，该静态变量并非被初始线程所更改。该静态变量很有可能是被客户端线程所更改的。在客户端线程更改该静态变量时，首先客户端线程会将该静态变量所属的类装载于自己的堆栈中。该静态变量则具有被不同线程读写的属性。进而，该静态变量不符合无状态设计原则，可以将该静态变量输出在检测报告中。需要说明的是，如果在堆栈中未查找到该静态变量的所属的类，则可以在检测报告中也将该静态变量作为低级别错误如WARNING报出来。因为，当静态变量所属的类未装载于初始线程中，可以确定该静态变量并非被初始线程所更改，此时可以将该静态变量作为高级别错误如ERROR报出来，而当静态变量所属的类装载于初始线程中，对于该静态变量是否是被初始线程所更改是不确定的。

如果成员变量所属的对象未在初始线程中生成，则成员变量并非被初始线程所更改的步骤包括：确定成员变量所属的对象所绑定的标签，如果在初始线程附加的标签列表中不存在标签，则成员变量所属的对象未在初始线程中生成，成员变量并非被初始线程所更改。

可选地，标签列表存储于初始线程对应的局部存储器中。

可选地，本实施例提供的方法还包括在开始执行目标程序的入口函数时，建立标签列表；当在执行目标程序的过程中，检测到发生对象创建事件时，将创建的对象绑定上标签；将标签存入标签列表中。

在实施中，在开始执行目标程序的入口函数时，声明一个标签列表。该标签列表可以使用Java提供的List、Set等数据结构进行声明。当声明好标签列表后，将该标签列表存储于初始线程对应的局部存储器中。该局部存储器是专门为该初始线程所开辟的一块内存空间，只为该初始线程所使用。因此，可以保障只有初始线程可以对标签列表进行操作，以防止其他线程对标签列表的更改。

接着，可以监测是否有对象被创建，在目标程序中，如果执行到带有关键字“new”的语句，可能会创建一个新的对象。当监测到发生对象创建事件时，可以将该对象绑定上标签tag，并将tag存入标签列表中。需要说明的是，对象本身存在标识，但是该标识比较类似于指针，该指针指向于对象。因此，对象标识随着目标程序的运行，或者其他线程的运行，对象标识会从指向对象A变为指向对象B，或者直接消失，或者存在多个相同的对象标识。因此，如图3所示，为了在上述情况中，对对象进行唯一标识并进行追踪，在检测到有新的对象被创建时，通过JNI接口，将该对象从Java层传至C层的JVMTI接口，再由JVMTI接口将该对象传至无状态检测引擎中，以在标签生成器中将该对象绑定上tag。

最后，当监测到成员变量发生更改时，确定该成员变量所属的对象所绑定的tag，如果在初始线程附加的标签列表中不存在该tag，则成员变量所属的对象未在初始线程中生成，成员变量并非被初始线程所更改。需要说明的是，标签列表是专用于记录初始线程所创建的对象的，当发现成员变量所属的对象不存在tag或者所绑定的tag不在初始线程附加的标签列表中，则证明该成员变量所属的对象不是由初始线程所创建的，那么极有可能是被客户端线程所创建的，进而，成员变量并非被初始线程所更改。

在执行完毕步骤S220之后，可选地，可以判断是否执行完目标程序，如果还未执行完目标程序，则可以重复执行步骤S220，以将整个目标程序运行完，并检测目标程序中所有的变量。在执行完目标程序后，并检测出所有的不符合无状态设计原则的变量后，可以将检测到的问题以报告的形式输出出来，以展示给程序员。

可选地，在建立标签列表时，为初始线程专门开辟了一块内存作为初始线程的局部存储器，该局部存储器不会在目标程序执行完毕之后，自动清空，而是需要人工在目标程序将要执行完毕之前，进行清空，否则会造成内存泄露的问题。

如图4所示，服务器1900中运行的目标程序是Java程序，支撑Java程序的是Java模拟机，而Java模拟机对应的是底层的代码翻译处理操作，也就对应上面所述的C层。可以将人工输入的入口函数放入到Java模拟机中，以告诉Java模拟机从哪里开始进行无状态检测操作。通过本发明实施例提供的方法，可以得到一段在C层实现的代码，将该代码进行编译可以得到相应的动态链接库即.dll文件，和通过代码注入技术得到的jar(打包好的类文件)包。与此同时，将动态链接库以及jar包添加至服务器1900的启动参数中，以自动启用动态链接库以及jar包。在服务器1900运行目标程序时，本实施例提供的方法对应的代码也会自动运行，以在服务器1900运行的过程中，检测目标程序是否符合无状态设计原则，最后将检测报告输出出来。

通过本发明实施例提供的方法，在执行目标程序的过程中，如果监测到目标程序的变量发生更改，且变量并非被执行目标程序所建立的初始线程所更改，则确定变量不符合无状态设计原则。从根源对目标程序中不符合无状态设计原则的变量进行识别，无需人工进行检测，本发明实现了自动化检测的过程。

基于相同的技术构思，本发明实施例还提供了一种对程序进行无状态检测的装置，如图5所示，该装置包括：

执行模块510，用于当检测到针对目标程序进行无状态检测的触发操作后，执行所述目标程序。

执行模块510的具体实现方式，可以参见在本发明实施例中一种对程序进行无状态检测的方法中的步骤S210的具体描述。

确定模块520，用于在执行所述目标程序的过程中，监测到所述目标程序的变量发生更改，且所述变量并非被执行所述目标程序所建立的初始线程所更改，确定所述变量不符合无状态设计原则。

确定模块520的具体实现方式，可以参见在本发明实施例中一种对程序进行无状态检测的方法中的步骤S220的具体描述。

可选地，所述确定模块520用于通过JVMTI接口监测所述变量是否发生更改。

可选地，所述确定模块520用于根据所述变量所属的变量类型，确定与所述变量对应的判断方式，并根据所述判断方式，判断所述变量是否被所述初始线程所更改，其中，所述判断方式是用于判断所述变量是否被所述初始线程所更改的方式。

可选地，所述变量类型包括静态变量和成员变量。

可选地，如图6所示，所述确定模块520包括：

第一判断单元621，用于所述变量属于静态变量，确定与所述静态变量对应的判断方式为：如果所述静态变量所属的类未装载于所述初始线程中，则所述静态变量并非被所述初始线程所更改；

第二判断单元622，用于所述变量属于成员变量，确定与所述成员变量对应的判断方式为：如果所述成员变量所属的对象未在所述初始线程中生成，则所述成员变量并非被所述初始线程所更改。

可选地，所述第一判断单元621用于确定所述初始线程对应的堆栈；如果在所述堆栈中未查找到所述静态变量所属的类，则所述静态变量所属的类未装载于所述初始线程中，所述静态变量并非被所述初始线程所更改；

所述第二判断单元用于622确定所述成员变量所属的对象所绑定的标签，如果在初始线程附加的标签列表中不存在所述标签，则所述成员变量所属的对象未在所述初始线程中生成，所述成员变量并非被所述初始线程所更改。

可选地，所述标签列表存储于所述初始线程对应的局部存储器中。

可选地，所述装置还包括：

建立模块，用于在开始执行所述目标程序的入口函数时，建立所述标签列表；

绑定模块，用于当在执行所述目标程序的过程中，检测到发生对象创建事件时，将创建的对象绑定上标签；

存入模块，用于将所述标签存入所述标签列表中。

需要说明的是，上述执行模块510、确定模块520可以由处理器1922实现，或者处理器1922配合存储器1932来实现，或者，处理器1922执行存储器1932中的程序指令来实现。

通过本发明实施例提供的装置，在执行目标程序的过程中，如果监测到目标程序的变量发生更改，且变量并非被执行目标程序所建立的初始线程所更改，则确定变量不符合无状态设计原则。从根源对目标程序中不符合无状态设计原则的变量进行识别，无需人工进行检测，本发明实现了自动化检测的过程。

需要说明的是：上述实施例提供的对程序进行无状态检测的装置在执行任务时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将服务器1900的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的对程序进行无状态检测的装置与对程序进行无状态检测的方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现，当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令，在服务器1900上加载和执行所述计算机程序指令时，全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴光缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是服务器1900能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(如软盘、硬盘和磁带等)，也可以是光介质(如数字视盘(DigitalVideo Disk，DVD)等)，或者半导体介质(如固态硬盘等)。

以上所述仅为本发明一个实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (20)

1.一种对程序进行无状态检测的方法，其特征在于，所述方法包括：

当检测到针对目标程序进行无状态检测的触发操作后，执行所述目标程序；

如果在执行所述目标程序的过程中，监测到所述目标程序的变量发生更改，在所述变量属于成员变量的情况下，如果所述成员变量所属的对象未在执行所述目标程序所建立的初始线程中生成，则所述成员变量并非被所述初始线程所更改，确定所述成员变量不符合无状态设计原则。

2.根据权利要求1所述的方法，其特征在于，监测所述目标程序的变量是否发生更改，包括：

通过JVMTI接口监测所述变量是否发生更改。

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

如果所述变量属于静态变量，则确定与所述静态变量对应的判断方式为：如果所述静态变量所属的类未装载于所述初始线程中，则所述静态变量并非被所述初始线程所更改，确定所述静态变量不符合无状态设计原则。

4.根据权利要求3所述的方法，其特征在于，

如果所述静态变量所属的类未装载于所述初始线程中，则所述静态变量并非被所述初始线程所更改，包括：

确定所述初始线程对应的堆栈；如果在所述堆栈中未查找到所述静态变量所属的类，则所述静态变量所属的类未装载于所述初始线程中，所述静态变量并非被所述初始线程所更改；

如果所述成员变量所属的对象未在所述初始线程中生成，则所述成员变量并非被所述初始线程所更改，包括：

确定所述成员变量所属的对象所绑定的标签，如果在初始线程附加的标签列表中不存在所述标签，则所述成员变量所属的对象未在所述初始线程中生成，所述成员变量并非被所述初始线程所更改。

5.根据权利要求4所述的方法，其特征在于，所述标签列表存储于所述初始线程对应的局部存储器中。

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

在开始执行所述目标程序的入口函数时，建立所述标签列表；

当在执行所述目标程序的过程中，检测到发生对象创建事件时，将创建的对象绑定上标签；

将所述标签存入所述标签列表中。

7.一种对程序进行无状态检测的装置，其特征在于，所述装置包括执行模块和确定模块，所述确定模块包括第一判断单元，其中：

所述执行模块，用于当检测到针对目标程序进行无状态检测的触发操作后，执行所述目标程序；

所述第一判断单元，用于在执行所述目标程序的过程中，监测到所述目标程序的变量发生更改，在所述变量属于成员变量的情况下，如果所述成员变量所属的对象未在执行所述目标程序所建立的初始线程中生成，则所述成员变量并非被所述初始线程所更改，确定所述成员变量不符合无状态设计原则。

8.根据权利要求7所述的装置，其特征在于，所述确定模块用于通过JVMTI接口监测所述变量是否发生更改。

9.根据权利要求7或8所述的装置，其特征在于，所述确定模块还包括：

第二判断单元，用于在所述变量属于静态变量的情况下，如果所述静态变量所属的类未装载于所述初始线程中，则所述静态变量并非被所述初始线程所更改，确定所述静态变量不符合无状态设计原则。

10.根据权利要求9所述的装置，其特征在于，所述第一判断单元用于确定所述初始线程对应的堆栈；如果在所述堆栈中未查找到所述静态变量所属的类，则所述静态变量所属的类未装载于所述初始线程中，所述静态变量并非被所述初始线程所更改；

所述第二判断单元用于确定所述成员变量所属的对象所绑定的标签，如果在初始线程附加的标签列表中不存在所述标签，则所述成员变量所属的对象未在所述初始线程中生成，所述成员变量并非被所述初始线程所更改。

11.根据权利要求10所述的装置，其特征在于，所述标签列表存储于所述初始线程对应的局部存储器中。

12.根据权利要求10所述的装置，其特征在于，所述装置还包括：

建立模块，用于在开始执行所述目标程序的入口函数时，建立所述标签列表；

绑定模块，用于当在执行所述目标程序的过程中，检测到发生对象创建事件时，将创建的对象绑定上标签；

存入模块，用于将所述标签存入所述标签列表中。

13.一种服务器，其特征在于，所述服务器包括处理器：

所述处理器用于当检测到针对目标程序进行无状态检测的触发操作后，执行所述目标程序；如果在执行所述目标程序的过程中，监测到所述目标程序的变量发生更改，在所述变量属于成员变量的情况下，如果所述成员变量所属的对象未在执行所述目标程序所建立的初始线程中生成，则所述成员变量并非被所述初始线程所更改，则确定所述成员变量不符合无状态设计原则。

14.根据权利要求13所述的服务器，其特征在于，所述处理器用于通过JVMTI接口监测所述变量是否发生更改。

15.根据权利要求13或14所述的服务器，其特征在于，所述处理器用于在所述变量属于静态变量的情况下，如果所述静态变量所属的类未装载于所述初始线程中，则所述静态变量并非被所述初始线程所更改，确定所述成员变量不符合无状态设计原则。

16.根据权利要求15所述的服务器，其特征在于，所述处理器用于如果所述变量属于静态变量，确定所述初始线程对应的堆栈；如果在所述堆栈中未查找到所述静态变量所属的类，则所述静态变量所属的类未装载于所述初始线程中，所述静态变量并非被所述初始线程所更改；如果所述变量属于成员变量，确定所述成员变量所属的对象所绑定的标签，如果在初始线程附加的标签列表中不存在所述标签，则所述成员变量所属的对象未在所述初始线程中生成，所述成员变量并非被所述初始线程所更改。

17.根据权利要求16所述的服务器，其特征在于，所述标签列表存储于所述初始线程对应的局部存储器中。

18.根据权利要求16所述的服务器，其特征在于，所述处理器还用于在开始执行所述目标程序的入口函数时，建立所述标签列表；当在执行所述目标程序的过程中，检测到发生对象创建事件时，将创建的对象绑定上标签；将所述标签存入所述标签列表中。

19.一种计算机可读存储介质，其特征在于，包括指令，当所述计算机可读存储介质在服务器上运行时，使得所述服务器执行权利要求1-6中任一权利要求所述的方法。

20.一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在服务器上运行时，使得所述服务器执行权利要求1-6中任一权利要求所述的方法。

Images