CN103942113B - ***重启原因的检测方法、装置及终端设备 - Google Patents
***重启原因的检测方法、装置及终端设备 Download PDFInfo
- Publication number
- CN103942113B CN103942113B CN201310594935.2A CN201310594935A CN103942113B CN 103942113 B CN103942113 B CN 103942113B CN 201310594935 A CN201310594935 A CN 201310594935A CN 103942113 B CN103942113 B CN 103942113B
- Authority
- CN
- China
- Prior art keywords
- thread
- lock
- mutual exclusion
- message
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Debugging And Monitoring (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本公开实施例公开了一种***重启原因检测方法、装置及终端设备，在智能终端重启后，所述***重启原因检测方法首先需要获取***日志文件，接着，查找***日志文件中是否包含强制结束***进程的进程消息，当包含强制结束***进程的进程消息时，获取相关的线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因；当导致***死锁的原因为由于线程间互锁时，确定互锁的线程；当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。从而在智能终端重启后能够快速检测出是否由于***死锁导致重启，如果由于***死锁导致重启，能够快速确定死锁的线程，无需研发人员逐条分析***消息，因此，速度快、效率高。
Description
技术领域
本公开涉及计算机技术领域，特别是涉及***重启原因的检测方法、装置及终端设备。
背景技术
随着智能终端的广泛应用，智能终端设备生产商为了推出具有自己特色的产品，通常会针对自己的智能终端设备深度定制属于自己的***(例如，Android***)。由于***研发人员对智能终端的***认识不足，编写程序不规范，使得***资源分配策略不当，导致进程(或线程)因竞争资源而产生死锁现象，进而导致***频繁重启。但是，当智能终端重启后，***研发人员需要逐条分析***消息确定是否由于死锁导致智能终端重启，此种方式速度慢、效率低。
发明内容
本公开实施例中提供了***重启原因的检测方法、装置及终端设备，以实现在智能终端重启后，能够快速、高效地检测出是否由于***死锁导致重启，如果由于***死锁导致***重启时，能够快速确定导致***死锁的线程。
为了解决上述技术问题，本公开实施例公开了如下技术方案：
第一方面，本公开提供一种***重启原因的检测方法，包括：获取***日志文件；查找所述***日志文件中是否包含强制结束***进程的进程消息；当***日志文件中包含强制结束***进程的进程消息时，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因；当导致***死锁的原因为线程间互锁时，确定互锁的线程；当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。
结合第一方面，在第一方面第一种可能的实现方式中，还包括：查找所述强制结束***进程的进程消息中是否包含线程名称，当所述强制结束***进程的进程消息中包含线程名称时，执行获取线程堆栈数据的步骤；当不包含线程名称时，确定线程持锁时间超过预设时间导致***死锁。
结合第一方面或第一方面第一种可能的实现方式，在第一方面第二种可能的实现方式中，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因的步骤，采用如下方式：
获取所述进程消息中第一线程对应的第一线程堆栈数据；
查找所述第一线程堆栈数据中是否包含等待互斥锁消息，所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程；
当第一线程堆栈数据不包含等待互斥锁消息时，确定第一线程持锁时间超过预设时间导致***死锁；
当第一线程堆栈数据存在等待互斥锁消息时，获取持有第一线程所等待互斥锁的第二线程对应的第二线程堆栈数据；
查找所述第二线程堆栈数据中是否包含等待互斥锁消息；
当第二线程堆栈数据不包含等待互斥锁消息时，确定第二线程持锁时间过长导致***死锁；
当第二线程堆栈数据包含等待互斥锁消息时，判断第二线程与第一线程是否构成持锁依赖关系；
当第二线程与第一线程构成持锁依赖关系时，确定由于线程间互锁导致***死锁；
当第二线程与第一线程未构成持锁依赖关系时，将持有第二线程所等待互斥锁的线程作为新的第二线程，返回执行获取新的第二线程对应第二线程堆栈数据。
结合第一方面的第二种可能的实现方式，在第一方面第三种可能的实现方式中，判断第二线程与第一线程是否构成持锁依赖关系的步骤，采用如下方式：
判断第一线程持有的互斥锁是否是第二线程所等待的互斥锁；当第一线程持有的互斥锁是第二线程所等待的互斥锁时，确定第一线程和第二线程间构成持锁依赖关系；当第一线程持有的互斥锁不是第二线程所等待的互斥锁时，确定第一线程和第二线程间未构成持锁依赖关系。
结合第一方面的第二种可能的实现方式，在第一方面第四种可能的实现方式中，判断第二线程与第一线程是否构成持锁依赖关系的步骤，采用如下方式：
根据获得的线程堆栈数据中的等待互斥锁消息，构建持锁依赖关系图数据；判断所述持锁依赖关系图数据中是否存在环路，如果所述持锁依赖关系图数据存在环路，确定由于环路上的各个线程构成持锁依赖关系。
结合第一方面的第三种可能的实现方式或第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，确定构成持锁依赖关系的线程为互锁的线程。
第二方面，本公开还提供了一种***重启原因的检测装置，包括：
第一获取单元，用于获取***日志文件；
第一查找单元，用于所述***日志文件中是否包含强制结束***进程的进程消息；
第二获取单元，用于当所述***日志文件包含强制结束***进程的进程消息时，获取线程堆栈数据，并根据获得的线程堆栈数据获取导致***死锁的原因；
第一确定单元，用于当导致***死锁的原因为线程间互锁时，确定互锁的线程；
第二确定单元，用于当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。
结合第二方面，在第二方面第一种可能的实现方式中，还包括：
第二查找单元，用于查找所述强制结束***进程的进程消息中是否包含线程名称，当所述强制结束***进程的进程消息中包含线程名称时，触发第二获取单元获取线程堆栈数据；当不包含线程名称时，确定线程持锁时间超过预设时间导致***死锁。
结合第二方面或第二方面第一种可能的实现方式，在第二方面第二种可能的实现方式中，所述第二获取单元包括：
第一获取子单元，用于获取所述进程消息中第一线程对应的第一线程堆栈数据；
第一查找子单元，用于查找所述第一线程堆栈数据中是否包含等待互斥锁消息，所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程；
第一确定子单元，用于当第一线程堆栈数据不包含等待互斥锁消息时，确定第一线程持锁时间超过预设时间导致***死锁；
第二获取子单元，用于当第一线程堆栈数据存在等待互斥锁消息时，获取持有第一线程所等待互斥锁的第二线程对应的第二线程堆栈数据；
第二查找子单元，用于查找所述第二线程堆栈数据中是否包含等待互斥锁消息；
第二确定子单元，用于当第二线程堆栈数据不包含等待互斥锁消息时，确定第二线程持锁时间过长导致***死锁；
第一判断子单元，用于当第二线程堆栈数据包含等待互斥锁消息时，判断第二线程与第一线程是否构成持锁依赖关系；
第三确定子单元，用于当第二线程与第一线程构成持锁依赖关系时，确定由于线程间互锁导致***死锁；
线程更新单元，用于当第二线程与第一线程未构成持锁依赖关系时，将持有第二线程所等待互斥锁的线程作为新的第二线程，并触发第二获取子单元获取新的第二线程对应的第二线程堆栈数据。
结合第二方面第二种可能的实现方式，在第二方面第三种可能的实现方式中，所述第一判断子单元包括：
第二判断子单元，用于判断第一线程持有的互斥锁是否是第二线程所等待的互斥锁；
第四确定子单元，用于当第一线程持有的互斥锁是第二线程所等待的互斥锁时，确定第一线程和第二线程间构成持锁依赖关系；或者，当第一线程持有的互斥锁不是第二线程所等待的互斥锁时，确定第一线程和第二线程间未构成持锁依赖关系。
结合第二方面第二种可能的实现方式，在第二方面第四种可能的实现方式中，所述第一判断子单元包括：
构建单元，用于根据获得的线程堆栈数据中的等待互斥锁消息，构建持锁依赖关系图数据；
第三判断子单元，用于判断所述持锁依赖关系图数据中是否存在环路；
第五确定子单元，用于当所述持锁依赖关系图数据存在环路时，确定环路上的各个线程构成持锁依赖关系。
结合第二方面第三种可能的实现方式或第二方面第四种可能的实现方式，在第二方面第五种可能的实现方式中，第一确定单元配置为确定构成持 锁依赖关系的线程为互锁的线程。
第三方面，本公开提供了一种终端设备，包括存储器，以及一个或者一个以上的指令，其中一个或者一个以上指令存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上指令所包含用于进行以下操作的指令：
获取***日志文件；
查找所述***日志文件中是否包含强制结束***进程的进程消息；
当***日志文件中包含强制结束***进程的进程消息时，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因；
当导致***死锁的原因为由于线程间互锁时，确定互锁的线程；
当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。
本公开的有益效果可以包括：在智能终端重启后，首先获取***日志文件，判断所述***日志文件中是否包含强制结束***进程的进程消息，如果包含则确定由于死锁导致智能终端重启，进一步判断由于线程间互锁导致死锁，还是由于线程持锁时间过长导致死锁，如果由于线程间互锁导致死锁，确定互锁的线程；如果线程持锁时间过长导致死锁，确定该线程。从而，在智能终端重启后，无需研发人员逐条分析***消息，能够快速、高效地确定出现死锁的线程。
附图说明
为了更清楚地说明本公开实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为一种线程间互锁关系的示意图；
图2为本公开实施例一种***重启原因的检测方法的流程示意图；
图3为图2所示实施例的步骤S230的流程示意图；
图4为本公开实施例另一种***重启原因的检测方法的流程示意图；
图5为本公开一种***重启原因的检测方法实例的流程示意图；
图6为本公开实施例一种***重启原因检测装置的结构示意图；
图7为本公开实施例另一种***重启原因检测装置的结构示意图；
图8为本公开实施例的第二获取单元的结构示意图；
图9为本公开实施例一种终端设备的结构示意图。
具体实施方式
本公开提供了一种***重启原因检测方法、装置及终端设备，在智能终端重启后，所述***重启原因检测方法首先需要获取***日志文件，接着，查找***日志文件中是否包含强制结束***进程的进程消息，当包含强制结束***进程的进程消息时，获取相关的线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因；当导致***死锁的原因为由于线程间互锁时，确定互锁的线程；当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。从而在智能终端重启后能够快速检测出是否由于***死锁导致重启，如果由于***死锁导致重启，能够快速确定死锁的线程，无需研发人员逐条分析***消息，因此，速度快、效率高。
以上是本公开的核心思想，为了使本领域技术人员更好地理解本公开方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所述描述的实施例仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。
在详细介绍本公开的实施例之前，首先介绍下***死锁的相关内容。
***死锁(deadlock)是指两个或两个以上的进程在执行过程中，因争夺资源造成互相等待的现象，如果没有外力作用，它们都将无法继续执行，此时称***处于死锁状态。
由于智能终端中的资源有限，因此资源占用具有互斥性，即当某个进程(线程)占用资源后，使得其他进程(线程)在无外力的协助下，不能获取到该资源而无法继续运行。在多进程(线程)应用中，通常利用互斥锁对***中的共享资源进行保护。当一个进程(线程)请求占用共享资源时，首先获取该资源的互斥锁，获得对应的互斥锁之后才能占用该共享资源，最后释 放所述互斥锁，以使其他进程(线程)获得进而占用所述共享资源。如果资源分配策略不当，将可能出现互斥锁被某个进程(线程)无限期的占用，导致其他进程(线程)无法使用共享资源，最终引起进程(线程)死锁。
请参见图1，示出了一种线程间互锁关系的示意图，在同一进程中有多个并行运行的线程。
假设在Android***中，线程1、线程2和线程3并行运行在system_server进程中，其中，线程1持有互斥锁A等待互斥锁B，线程2持有互斥锁B等待互斥锁C，同时，线程3持有互斥锁C等待互斥锁A。而且，每个线程都要获得等待的互斥锁后，才释放其他线程所等待的互斥锁，即线程1在获得互斥锁B后才释放互斥锁A、而线程2在获得互斥锁C后才释放互斥锁B，线程3在获得互斥锁A后才释放互斥锁C，此时线程1、线程2、线程3都得不到等待的互斥锁，并且会一直等待下去，从而造成线程死锁。此时，Android***中的WatchDog程序就会强制结束(杀死)system_server进程，最终导致Android***重启。
请参见图2，示出了本公开实施例一种***重启原因的检测方法的流程示意图，该方法应用于终端设备，如图2所示，所述方法可以包括以下步骤：
首先，在步骤S210，获取***日志文件。所述***日志文件是记录***操作事件的记录文件或文件集合。
接着，在步骤S220，查找所述***日志文件中是否包含强制结束***进程的进程消息，若***日志文件中包含强制结束***进程的进程消息，执行步骤S230；若***日志文件中不包含强制结束***进程的进程消息，则确定不是由于***死锁导致***重启，进而结束。
当操作***是Android***时，通过查找Android***内的***日志文件中是否包含“Watchdog killing system process：thread1”的进程消息，其中，“thread1”表示线程名称。如果***日志文件中包含所述进程消息，表明Android***发生了死锁。如果不包含类似的信息，表明Android***未发生死锁。本领域技术可以理解的是，在其他的操作***中，可以是其他形式的强制结束***进程的进程消息。
然后，在步骤S230，获取线程堆栈数据，并根据所述线程堆栈数据获取 导致***死锁的原因。
该步骤获取与强制结束***进程的进程消息的相关线程的线程堆栈数据，所述相关线程包括所述强制结束***进程的进程消息所携带的线程名称对应的线程及与所述线程名称对应的线程堆栈数据直接或间接相关联的线程。进一步跟进获得的线程堆栈数据确定导致***死锁的原因。
在步骤S240，当导致***死锁的原因为线程间互锁时，确定互锁的线程。
在步骤S250，当导致***死锁的原因为线程持锁时间超过预设时间时，，确定持锁时间超过预设时间的线程。
本实施例提供的***重启原因的检测方法，在***重启后，首先获取***日志文件，通过判断***日志文件中是否包含强制结束***进程的进程消息，确定是否是***死锁导致***重启；如果***日志文件中包含强制结束***进程的进程消息，则表明由于***死锁导致***重启，然后，获取相关线程的线程堆栈数据，从而确定导致***死锁的原因，进而确定导致***死锁的线程。由上述的检测过程可知，***能够自动检测出是否由于***死锁导致***重启，进而当***死锁导致***重启时，能够确定出导致***死锁的线程，无需研发人员逐条分析***消息，因此，检测速度快、效率高。
在本公开的一个实施例中，如图3所示，上述实施例中的步骤S230可以包括以下步骤：
首先，在步骤S310，获取强制结束***进程的进程消息中第一线程对应的第一线程堆栈数据。所述第一线程为强制结束***进程的进程消息中所包含线程名称，该步骤从应用程序错误信息反馈文件(例如，Android***中的traces.txt文件)中获取所述第一线程对应的第一线程堆栈数据。
接下来，在步骤S320，查找所述第一线程堆栈数据中是否包含等待互斥锁消息；所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程。
例如，在Android***中，查找第一线程堆栈数据中是否包含“waiting**held bytid＝*”的类似消息，其中，“**”代表第一线程所等待的互斥锁的名称，“*”代表持有互斥锁“**”的线程号，如果存在类似消息，则表明第一线程堆栈数据中包含等待互斥锁消息；如果不存在类似消息，则表明第一线程堆 栈数据中不包含等待互斥锁消息。
当第一线程堆栈数据不包含等待互斥锁消息时，执行步骤S330，确定第一线程持锁时间超过预设时间导致***死锁；即，第一线程执行某个函数时间超过预设时间导致***死锁。
当第一线程堆栈数据存在等待互斥锁消息时，执行步骤S340，获取第二线程对应的第二线程堆栈数据。
假设，第一线程堆栈数据中包含的等待互斥锁消息为“waiting A held by tid＝2”，此等待互斥锁消息表征第一线程等待的线程锁A被线程号为2的线程“thread2”所持有，则线程“thread2”为该步骤中的第二线程。获取第二线程对应的第二线程堆栈数据。
然后，在步骤S350，查找所述第二线程堆栈数据中是否包含等待互斥锁消息。该步骤的查找过程与步骤S320的查找过程相同，此处不再赘述。
当第二线程堆栈数据不包含等待互斥锁消息时，在步骤S360，确定第二线程持锁时间过长导致***死锁；即由于第二线程执行某个函数时间超过预设时间导致***死锁。
当第二线程堆栈数据包含等待互斥锁消息时，在步骤S370，判断第二线程与第一线程是否构成持锁依赖关系。
在本公开的一个实施例中，判断第二线程与第一线程是否构成持锁依赖关系的过程可以包括以下子步骤：
首先，判断第一线程持有的互斥锁是否是最新的第二线程所等待的互斥锁。
当第一线程持有的互斥锁是最新的第二线程所等待的互斥锁时，确定第一线程和全部的第二线程间构成持锁依赖关系。
当第一线程持有的互斥锁不是最新的第二线程所等待的互斥锁时，确定第一线程和全部的第二线程间未构成持锁依赖关系。
在本公开的另一个实施例中，判断第二线程与第一线程是否构成持锁依赖关系的过程可以包括以下子步骤：
首先，根据获得的线程堆栈数据中的等待互斥锁消息，构建持锁依赖关系图数据。
在构建持锁依赖关系图数据时，以线程为节点，用有向线段连接存在互斥锁等待关系的线程，且有向线段的方向指向请求互斥锁的线程，从而生成持锁依赖关系图数据。
然后，判断所述持锁依赖关系图数据中是否存在环路，如果所述持锁依赖关系图数据存在环路，确定由于环路上的各个线程构成持锁依赖关系。
依次以持锁依赖关系图数据中的各个节点为起点沿有向线段的方向进行追踪，以查询是否存在环路，若存在环路，则确定处于环路上的各个线程间存在持锁依赖关系。
若步骤S370判断出第二线程与第一线程构成持锁依赖关系，在步骤S380，确定由于线程间互锁导致***死锁。
若步骤S370判断出第二线程与第一线程未构成持锁依赖关系，在步骤S390，将持有第二线程所等待互斥锁的线程作为新的第二线程，返回执行步骤S340获取新的第二线程对应第二线程堆栈数据，直到判断出构成持锁依赖关系的线程，或者，确定出某个线程持锁时间超过预设时间。
请参见图4，示出了本公开实施例另一种***重启原因的检测方法的流程示意图，在图2对应的实施例的基础上，增加查找强制结束***进程的进程消息中是否包含线程名称的过程，如图4所示，所述方法可以包括以下步骤：
首先，在步骤S210，获取***日志文件。
接着，在步骤S220，查找所述***日志文件中是否包含强制结束***进程的进程消息，若***日志文件中包含强制结束***进程的进程消息，执行步骤S260；若***日志文件中不包含强制结束***进程的进程消息，则确定不是由于***死锁导致***重启，进而结束。
然后，在步骤S260，查找所述强制结束***进程的进程消息中是否包含线程名称；当包含线程名称时，执行步骤S230；当不包含线程名称(即线程名称为Null)时，表明由于***线程(Android***中，所述***线程为 ServerThread)持锁时间超过预设时间导致***死锁；即***线程执行某个函数时间超过预设时间导致***死锁。
在步骤S230，获取相应的线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因。
在步骤S240，当导致***死锁的原因为线程间互锁时，确定互锁的线程。
在步骤S250，当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。
本实施例提供的***重启原因的检测方法，在查找到***日志文件中包含强制结束***进程的进程消息后，进一步查找所述进程消息中是否包含线程名称，若不包含线程名称，则确定***线程执行某个函数时间超过预设时间导致***死锁；若包好线程名称，再进一步获取所述线程名称对应线程的线程堆栈数据，进而确定导致***死锁的线程，即只有强制结束***进程的进程消息满足一定条件时才获取线程堆栈数据，节省了***资源。
下面以一个具体实例说明***重启原因的检测方法，如图5所示，所述方法以可以包括以下步骤：
当***重启后，在步骤S510，获取***日志文件。
接着，在步骤S520，查找所述***日志文件中是否包含强制结束***进程的进程消息；
当***日志文件中包含强制结束***进程的进程消息时，执行步骤S530；当***日志文件中不包含强制结束***进程的进程消息时，则确定不是***死锁导致***重启，进而结束。
在步骤S530，查找强制结束***进程的进程消息中是否包含线程名称；假设所述进程消息为“Watchdog killing system process：thread1”，所包含的线程名称为“Thread1”，则执行步骤S540；
在步骤S540，获取线程“Thread1”对应的线程堆栈数据。
若所述进程消息中不包含线程名称(即线程名称为Null)时，在步骤S550中，确定***线程持锁时间超过预设时间导致死锁，即***线程执行某个函 数的时间超过预设时间导致***死锁。例如，在Android***中，ServerThread线程执行某个函数的时间超过预设时间导致Android***死锁。
获得线程“Thread1”的线程堆栈数据后，在步骤S560，查找“Thread1”的线程堆栈数据中是否包含等待互斥锁消息。
若“Thread1”的线程堆栈数据中不包含等待互斥锁消息，在步骤S570，确定线程“Thread1”执行某个函数时间超过预设时间导致***死锁。
假设等待互斥锁消息：“waiting A held by tid＝2”，该消息表明线程“Thread1”等待的互斥锁A被线程号为2的线程所持有，则在步骤S580，获取“Thread2”的线程堆栈数据。
获得“Thread2”的线程堆栈数据之后，在步骤S590，查找“Thread2”的线程堆栈数据中是否包含等待互斥锁消息。
若“Thread2”的线程堆栈数据中不包含等待互斥锁消息，则在步骤S5100，确定线程“Thread2”执行某个函数时间超过预设时间导致***死锁。
若“Thread2”的线程堆栈数据中包含等待互斥锁消息，则在步骤S5110，判断线程“Thread2”与线程“Thread1”是否构成持锁依赖关系；
假设所述等待互斥锁消息：“waiting B held by tid＝3”，表明线程“Thread2”所等待的互斥锁B被线程号为3的线程“Thread3”所持有，线程“Thread2”所等待的互斥锁B并非被线程“Thread1”所持有，因此，线程“Thread2”与线程“Thread1”未构成持锁依赖关系。
判断出线程“Thread2”与线程“Thread1”未构成持锁依赖关系后，在步骤S5130，将“Thread2”更新为“Thread3”；其中，线程“Thread3”持有线程“Thread2”等待的互斥锁。
然后，返回执行步骤S580，获取线程“Thread3”的线程堆栈数据。进而，在步骤S590，查找线程“Thread3”的线程堆栈数据中是否包含等待互斥锁消息。
若“Thread3”的线程堆栈数据中不包含等待互斥锁消息，则在步骤S5100，确定线程“Thread3”执行某个函数时间超过预设时间导致***死锁。
若“Thread3”的线程堆栈数据中包含等待互斥锁消息：“waiting C held by tid＝1”，表明线程“Thread3”所等待的互斥锁C被线程号为1的线程“Thread1”所持有，因此，在步骤S5110，判断出线程“Thread3”与线程“Thread1”构成持锁依赖关系。
在步骤S5120，确定线程间互锁导致***死锁，并确定互锁的线程。线程“Thread1”、“Thread2”和“Thread3”为互锁的线程。线程“Thread1”、“Thread2”和“Thread3”的持锁依赖关系与图1所示的关系示意图相同。
与本公开的***重启原因的检测方法实施例相对应，本公开还提供了***重启原因的检测装置实施例。
请参见图6，示出了本公开实施例一种***重启原因的检测装置的结构示意图，所述装置可以包括：第一获取单元100、第一查找单元200、第二获取单元300、第一确定单元400和第二确定单元500，其中：
第一获取单元100，用于获取***日志文件。
第一查找单元200，用于所述***日志文件中是否包含强制结束***进程的进程消息。在Android***中，强制结束***进程的进程消息为“Watchdog killing systemprocess：thread1”的类似消息。
第二获取单元300，用于当所述***日志文件中包含强制结束***进程的进程消息时，获取相应的线程堆栈数据，并根据获得的线程堆栈数据获取导致***死锁的原因。
第一确定单元400，用于当导致***死锁的原因为线程间互锁时，确定互锁的线程。
第二确定单元500，用于当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。
本实施例提供的***重启原因的检测装置，在***重启后，能够根据***日志文件判断是否由于***死锁导致***重启，如果***重启原因是***死锁，则进一步能够确定导致***死锁的线程，无需研发人员逐条分析***消息，因此，检测速度快、效率高。
请参见图7，示出了本公开实施例另一种***重启原因的检测装置的结 构示意图，该装置在图6所示的装置的基础上，增加了第二查找单元600。本实施例提供的装置包括：第一获取单元100、第一查找单元200、第二获取单元300、第一确定单元400、第二确定单元500和第二查找单元600。
其中，本实施例中名称、编号与图6所示的实施例相同的单元，其功能也相同，此处不再赘述，下面着重介绍第二查找单元600。
第二查找单元600连接在第一查找单元200和第二获取单元300之间。第二查找单元用于查找所述强制结束***进程的进程消息中是否包含线程名称，当所述强制结束***进程的进程消息中包含线程名称时，触发第二获取单元300获取线程堆栈数据；当不包含线程名称时，确定线程持锁时间超过预设时间导致***死锁。
本实施例提供的***重启原因的检测装置，在查找到***日志文件中包含强制结束***进程的进程消息后，进一步查找所述进程消息中是否包含线程名称，若不包含线程名称，则确定***线程执行某个函数时间超过预设时间导致***死锁；若包好线程名称，再进一步获取所述线程名称对应线程的线程堆栈数据，进而确定导致***死锁的线程，即只有强制结束***进程的进程消息满足一定条件时才获取线程堆栈数据，节省了***资源。
请参见图8所示，示出了本公开实施例提供的第二获取单元的结构示意图，所述第二获取单元可以包括：第一获取子单元310、第一查找子单元320、第一确定子单元330、第二获取子单元340、第二查找子单元350、第二确定子单元360、第一判断子单元370、第三确定子单元380和线程更新单元390。
第一获取子单元310，用于获取所述进程消息中第一线程对应的第一线程堆栈数据。所述第一线程为强制结束***进程的进程消息所包含的线程名称对应的线程。
第一查找子单元320，用于查找所述第一线程堆栈数据中是否包含等待互斥锁消息；所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程。
第一确定子单元330，用于当第一线程堆栈数据不包含等待互斥锁消息时，确定第一线程持锁时间超过预设时间导致***死锁。
第二获取子单元340，用于当第一线程堆栈数据存在等待互斥锁消息时，获取持有第一线程所等待互斥锁的第二线程对应的第二线程堆栈数据。
第二查找子单元350，用于查找所述第二线程堆栈数据中是否包含等待互斥锁消息。
第二确定子单元360，用于当第二线程堆栈数据不包含等待互斥锁消息时，确定第二线程持锁时间过长导致***死锁。
第一判断子单元370，用于当第二线程堆栈数据包含等待互斥锁消息时，判断第二线程与第一线程是否构成持锁依赖关系。
在本公开的一个可能的实施例中，所述第一判断子单元可以包括：第二判断子单元和第四确定子单元，其中：
第二判断子单元，用于判断第一线程持有的互斥锁是否是第二线程所等待的互斥锁。
第四确定子单元，用于当第一线程持有的互斥锁是第二线程所等待的互斥锁时，确定第一线程和第二线程间构成持锁依赖关系；或者，当第一线程持有的互斥锁不是第二线程所等待的互斥锁时，确定第一线程和第二线程间未构成持锁依赖关系。
在本公开的另一个可能的实施例中，所述第一判断子单元可以包括：构建单元、第三判断子单元和第五确定子单元，其中：
构建单元，用于根据获得的线程堆栈数据中的等待互斥锁消息，构建持锁依赖关系图数据。
第三判断子单元，用于判断所述持锁依赖关系图数据中是否存在环路。
第五确定子单元，用于当所述持锁依赖关系图数据存在环路时，确定环路上的各个线程构成持锁依赖关系。
第三确定子单元380与第一判断子单元370连接，用于当第二线程与第一线程构成持锁依赖关系时，确定由于线程间互锁导致***死锁。进而由图6或图7对应的实施例中的第一确定单元确定出构成持锁依赖关系的线程为互锁的线程。
线程更新单元390连接在第一判断子单元370和第二获取子单元340之间，用于当第二线程与第一线程未构成持锁依赖关系时，将持有第二线程所等待互斥锁的线程作为新的第二线程，并触发第二获取子单元获取新的第二线程对应的第二线程堆栈数据。
相对于上述实施例提供的***重启原因的检测方法和装置，本公开还提供了终端设备。
请参见图9，示出了本公开涉及的终端设备的结构示意图，该终端设备可以用于实施上述实施例中提供的***重启原因的检测方法，具体而言：
终端设备可以包括RF(Radio Frequency，射频)电路110、包括有一个或一个以上计算机可读存储介质的存储器120、输入单元130、显示单元140、传感器150、音频电路160、WiFi模块170、包括有一个或者一个以上处理核心的处理器180、以及电源190等部件。本领域技术人员可以理解，图9中示出的终端设备结构并不构成对终端设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
RF电路110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器180处理；另外，将涉及上行的数据发送给基站。通常，RF电路110包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、LNA(Low Noise Amplifier，低噪声放大器)、双工器等。此外，RF电路110还可以通过无线通信与网络和其他设备通信。该无线通信可以使用任一通信标准或协议，包括但不限于GSM(Global System of Mobile communication，全球移动通讯***)、GPRS(General Packet Radio Service，通用分组无线服务)、CDMA(CodeDivision Multiple Access，码分多址)、WCDMA(Wideband Code Division MultipleAccess,宽带码分多址)、LTE(Long Term Evolution,长期演进)、电子邮件、SMS(ShortMessaging Service，短消息服务)等。
存储器120可用于存储软件程序以及模块，处理器180通过运行存储在存储器120的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操 作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端设备的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器120还可以包括存储器控制器，以提供处理器180和输入单元130对存储器120的访问。
输入单元130可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元130可以包括触敏表面131以及其他输入设备132。触敏表面131，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面131上或在触敏表面131附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面131可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器180，并能接收处理器180发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面131。除了触敏表面131，输入单元130还可以包括其他输入设备132。具体地，其他输入设备132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元140可用于显示由用户输入的信息或提供给用户的信息以及终端设备的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元140可包括显示面板141，可选的，可以采用LCD(Liquid Crystal Display，液晶显示器)、OLED(Organic Light-Emitting Diode,有机发光二极管)等形式来配置显示面板141。进一步的，触敏表面131可覆盖显示面板141，当触敏表面131检测到在其上或附近的触摸操作后，传送给处理器180以确定触摸事件的类型，随后处理器180根据触摸事件的类型在显示面板141上提供相应的视觉输出。虽然在图9中，触敏表面131与显示面板141是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面131与显示面板141集成而实现输入 和输出功能。
终端设备还可包括至少一种传感器150，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板141的亮度，接近传感器可在终端设备移动到耳边时，关闭显示面板141和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于终端设备还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。
音频电路160、扬声器161，传声器162可提供用户与终端设备之间的音频接口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161，由扬声器161转换为声音信号输出；另一方面，传声器162将收集的声音信号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输出处理器180处理后，经RF电路110以发送给比如另一终端设备，或者将音频数据输出至存储器120以便进一步处理。音频电路160还可能包括耳塞插孔，以提供外设耳机与终端设备的通信。
WiFi属于短距离无线传输技术，终端设备通过WiFi模块170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图9示出了WiFi模块170，但是可以理解的是，其并不属于终端设备的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。
处理器180是终端设备的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器120内的软件程序和/或模块，以及调用存储在存储器120内的数据，执行终端设备的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器180可包括一个或多个处理核心；优选的，处理器180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作***、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器180中。
终端设备还包括给各个部件供电的电源190(比如电池)，优选的，电源可以通过电源管理***与处理器180逻辑相连，从而通过电源管理***实现管理充电、放电、以及功耗管理等功能。电源190还可以包括一个或一个以上的直流或交流电源、再充电***、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
尽管未示出，终端设备还可以包括摄像头、蓝牙模块等，在此不再赘述。在本实施例中，终端设备的显示单元时触摸屏显示器。
所述终端设备还包括一个或者一个以上的指令(instruction或program)，其中一个或者一个以上指令存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上指令所包含用于进行以下操作的指令：
获取***日志文件；
查找所述***日志文件中是否包含强制结束***进程的进程消息；
当***日志文件中包含强制结束***进程的进程消息时，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因；
当导致***死锁的原因为由于线程间互锁时，确定互锁的线程；
当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程。
较佳地，所述一个或者一个以上指令还包括用于进行以下操作的指令：
查找所述强制结束***进程的进程消息中是否包含线程名称，当所述强制结束***进程的进程消息中包含线程名称时，执行获取线程堆栈数据的步骤；当不包含线程名称时，确定线程持锁时间超过预设时间导致***死锁。
较佳地，所述一个或者一个以上指令还包括用于进行以下操作的指令：
获取进程消息中第一线程对应的第一线程堆栈数据；
查找所述第一线程堆栈数据中是否包含等待互斥锁消息，所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程；
当第一线程堆栈数据不包含等待互斥锁消息时，确定第一线程持锁时间超过预设时间导致***死锁；
当第一线程堆栈数据存在等待互斥锁消息时，获取持有第一线程所等待互斥锁的第二线程对应的第二线程堆栈数据；
查找所述第二线程堆栈数据中是否包含等待互斥锁消息；
当第二线程堆栈数据不包含等待互斥锁消息时，确定第二线程持锁时间过长导致***死锁；
当第二线程堆栈数据包含等待互斥锁消息时，判断第二线程与第一线程是否构成持锁依赖关系；
当第二线程与第一线程构成持锁依赖关系时，确定由于线程间互锁导致***死锁；
当第二线程与第一线程未构成持锁依赖关系时，将持有第二线程所等待互斥锁的线程作为新的第二线程，返回执行获取新的第二线程对应第二线程堆栈数据。
在本公开的一个可能的实施例中，所述一个或者一个以上指令还包括用于进行以下操作的指令：
判断第一线程持有的互斥锁是否是第二线程所等待的互斥锁；
当第一线程持有的互斥锁是第二线程所等待的互斥锁时，确定第一线程和第二线程间构成持锁依赖关系；并确定构成持锁依赖关系的线程为互锁的线程。
当第一线程持有的互斥锁不是第二线程所等待的互斥锁时，确定第一线程和第二线程间未构成持锁依赖关系。
在本公开的另一个可能的实施例中，所述一个或者一个以上指令还包括用于进行以下操作的指令：
根据获得的线程堆栈数据中的等待互斥锁消息，构建持锁依赖关系图数据；
判断所述持锁依赖关系图数据中是否存在环路，如果所述持锁依赖关系图数据存在环路，确定由于环路上的各个线程构成持锁依赖关系。并确定构成持锁依赖关系的线程为互锁的线程。
本公开还提供一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中的存储器中所包含的计算机可读存储介质；也可以是单独存在，未装配入终端中的计算机可读存储介质。所述计算机可读存储介质存储有一个或 者一个以上指令，所述一个或者一个以上指令被一个或者一个以上的处理器用来执行图2、图3、图4、图5所示实施例所提供的***重启原因的检测方法。
本领域的技术人员可以清楚地了解到本公开实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本公开实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述的本公开实施方式，并不构成对本公开保护范围的限定。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开的保护范围之内。
Claims (11)
1.一种***重启原因的检测方法，其特征在于，包括：
获取***日志文件；
查找所述***日志文件中是否包含强制结束***进程的进程消息；
当***日志文件中包含强制结束***进程的进程消息时，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因；
当导致***死锁的原因为线程间互锁时，确定互锁的线程；
当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程；
其中，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因的步骤，采用如下方式：
获取所述进程消息中第一线程对应的第一线程堆栈数据；
查找所述第一线程堆栈数据中是否包含等待互斥锁消息，所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程；
当第一线程堆栈数据不包含等待互斥锁消息时，确定第一线程持锁时间超过预设时间导致***死锁；
当第一线程堆栈数据存在等待互斥锁消息时，获取持有第一线程所等待互斥锁的第二线程对应的第二线程堆栈数据；
查找所述第二线程堆栈数据中是否包含等待互斥锁消息；
当第二线程堆栈数据不包含等待互斥锁消息时，确定第二线程持锁时间过长导致***死锁；
当第二线程堆栈数据包含等待互斥锁消息时，判断第二线程与第一线程是否构成持锁依赖关系；
当第二线程与第一线程构成持锁依赖关系时，确定由于线程间互锁导致***死锁；
当第二线程与第一线程未构成持锁依赖关系时，将持有第二线程所等待互斥锁的线程作为新的第二线程，返回执行获取新的第二线程对应第二线程堆栈数据。
2.根据权利要求1所述的方法，其特征在于，还包括：
查找所述强制结束***进程的进程消息中是否包含线程名称，当所述强制结束***进程的进程消息中包含线程名称时，执行获取线程堆栈数据的步骤；当不包含线程名称时，确定线程持锁时间超过预设时间导致***死锁。
3.根据权利要求1所述的方法，其特征在于，判断第二线程与第一线程是否构成持锁依赖关系的步骤，采用如下方式：
判断第一线程持有的互斥锁是否是第二线程所等待的互斥锁；
当第一线程持有的互斥锁是第二线程所等待的互斥锁时，确定第一线程和第二线程间构成持锁依赖关系；
当第一线程持有的互斥锁不是第二线程所等待的互斥锁时，确定第一线程和第二线程间未构成持锁依赖关系。
4.根据权利要求1所述的方法，其特征在于，判断第二线程与第一线程是否构成持锁依赖关系的步骤，采用如下方式：
根据获得的线程堆栈数据中的等待互斥锁消息，构建持锁依赖关系图数据；
判断所述持锁依赖关系图数据中是否存在环路，如果所述持锁依赖关系图数据存在环路，确定由于环路上的各个线程构成持锁依赖关系。
5.根据权利要求3或4所述的方法，其特征在于，确定构成持锁依赖关系的线程为互锁的线程。
6.一种***重启原因的检测装置，其特征在于，包括：
第一获取单元，用于获取***日志文件；
第一查找单元，用于所述***日志文件中是否包含强制结束***进程的进程消息；
第二获取单元，用于当所述***日志文件包含强制结束***进程的进程消息时，获取线程堆栈数据，并根据获得的线程堆栈数据获取导致***死锁的原因；
第一确定单元，用于当导致***死锁的原因为线程间互锁时，确定互锁的线程；
第二确定单元，用于当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程；
其中，所述第二获取单元包括：
第一获取子单元，用于获取所述进程消息中第一线程对应的第一线程堆栈数据；
第一查找子单元，用于查找所述第一线程堆栈数据中是否包含等待互斥锁消息，所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程；
第一确定子单元，用于当第一线程堆栈数据不包含等待互斥锁消息时，确定第一线程持锁时间超过预设时间导致***死锁；
第二获取子单元，用于当第一线程堆栈数据存在等待互斥锁消息时，获取持有第一线程所等待互斥锁的第二线程对应的第二线程堆栈数据；
第二查找子单元，用于查找所述第二线程堆栈数据中是否包含等待互斥锁消息；
第二确定子单元，用于当第二线程堆栈数据不包含等待互斥锁消息时，确定第二线程持锁时间过长导致***死锁；
第一判断子单元，用于当第二线程堆栈数据包含等待互斥锁消息时，判断第二线程与第一线程是否构成持锁依赖关系；
第三确定子单元，用于当第二线程与第一线程构成持锁依赖关系时，确定由于线程间互锁导致***死锁；
线程更新单元，用于当第二线程与第一线程未构成持锁依赖关系时，将持有第二线程所等待互斥锁的线程作为新的第二线程，并触发第二获取子单元获取新的第二线程对应的第二线程堆栈数据。
7.根据权利要求6所述的***重启原因的检测装置，其特征在于，还包括：
第二查找单元，用于查找所述强制结束***进程的进程消息中是否包含线程名称，当所述强制结束***进程的进程消息中包含线程名称时，触发第二获取单元获取线程堆栈数据；当不包含线程名称时，确定线程持锁时间超过预设时间导致***死锁。
8.根据权利要求6所述的***重启原因的检测装置，其特征在于，所述第一判断子单元包括：
第二判断子单元，用于判断第一线程持有的互斥锁是否是第二线程所等待的互斥锁；
第四确定子单元，用于当第一线程持有的互斥锁是第二线程所等待的互斥锁时，确定第一线程和第二线程间构成持锁依赖关系；或者，当第一线程持有的互斥锁不是第二线程所等待的互斥锁时，确定第一线程和第二线程间未构成持锁依赖关系。
9.根据权利要求6所述的***重启原因的检测装置，其特征在于，所述第一判断子单元包括：
构建单元，用于根据获得的线程堆栈数据中的等待互斥锁消息，构建持锁依赖关系图数据；
第三判断子单元，用于判断所述持锁依赖关系图数据中是否存在环路；
第五确定子单元，用于当所述持锁依赖关系图数据存在环路时，确定环路上的各个线程构成持锁依赖关系。
10.根据权利要求8或9所述的***重启原因的检测装置，其特征在于，第一确定单元配置为确定构成持锁依赖关系的线程为互锁的线程。
11.一种终端设备，其特征在于，包括存储器，以及一个或者一个以上的指令，其中一个或者一个以上指令存储于存储器中，且经配置以由一个或者一个以上处理器执行所述一个或者一个以上指令所包含用于进行以下操作的指令：
获取***日志文件；
查找所述***日志文件中是否包含强制结束***进程的进程消息；
当***日志文件中包含强制结束***进程的进程消息时，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因；
当导致***死锁的原因为由于线程间互锁时，确定互锁的线程；
当导致***死锁的原因为线程持锁时间超过预设时间时，确定持锁时间超过预设时间的线程；
其中，获取线程堆栈数据，并根据所述线程堆栈数据获取导致***死锁的原因的步骤，采用如下方式：
获取所述进程消息中第一线程对应的第一线程堆栈数据；
查找所述第一线程堆栈数据中是否包含等待互斥锁消息，所述等待互斥锁消息包含持有第一线程所等待互斥锁的第二线程；
当第一线程堆栈数据不包含等待互斥锁消息时，确定第一线程持锁时间超过预设时间导致***死锁；
当第一线程堆栈数据存在等待互斥锁消息时，获取持有第一线程所等待互斥锁的第二线程对应的第二线程堆栈数据；
查找所述第二线程堆栈数据中是否包含等待互斥锁消息；
当第二线程堆栈数据不包含等待互斥锁消息时，确定第二线程持锁时间过长导致***死锁；
当第二线程堆栈数据包含等待互斥锁消息时，判断第二线程与第一线程是否构成持锁依赖关系；
当第二线程与第一线程构成持锁依赖关系时，确定由于线程间互锁导致***死锁；
当第二线程与第一线程未构成持锁依赖关系时，将持有第二线程所等待互斥锁的线程作为新的第二线程，返回执行获取新的第二线程对应第二线程堆栈数据。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310594935.2A CN103942113B (zh) | 2013-11-21 | 2013-11-21 | ***重启原因的检测方法、装置及终端设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310594935.2A CN103942113B (zh) | 2013-11-21 | 2013-11-21 | ***重启原因的检测方法、装置及终端设备 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103942113A CN103942113A (zh) | 2014-07-23 |
| CN103942113B true CN103942113B (zh) | 2017-03-01 |
Family
ID=51189788
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310594935.2A Active CN103942113B (zh) | 2013-11-21 | 2013-11-21 | ***重启原因的检测方法、装置及终端设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103942113B (zh) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN104794016A (zh) * | 2015-04-23 | 2015-07-22 | 惠州Tcl移动通信有限公司 | 一种移动终端死机检测处理方法及*** |
| CN105930247B (zh) * | 2016-04-14 | 2018-09-04 | 北京小米移动软件有限公司 | ***重启问题的处理方法、装置以及移动终端 |
| CN106339285A (zh) * | 2016-08-19 | 2017-01-18 | 浪潮电子信息产业股份有限公司 | 一种linux***意外重启的分析方法 |
| CN107451257A (zh) * | 2017-07-31 | 2017-12-08 | 郑州云海信息技术有限公司 | 一种基于分布式文件***的可维护性***和方法 |
| US11693701B2 (en) | 2017-09-30 | 2023-07-04 | Huawei Technologies Co., Ltd. | System service timeout processing method, and apparatus |
| CN108038038B (zh) * | 2017-11-30 | 2021-11-16 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN108012031B (zh) * | 2017-11-30 | 2021-03-26 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN108182123A (zh) * | 2017-12-28 | 2018-06-19 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN108170549B (zh) * | 2017-12-28 | 2021-11-16 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN108595311B (zh) * | 2017-12-28 | 2021-11-16 | 努比亚技术有限公司 | 基于外设接口的重启定位方法、移动终端及可读存储介质 |
| CN108108257B (zh) * | 2017-12-28 | 2022-03-18 | 努比亚技术有限公司 | 基于mdss的重启定位方法、移动终端及可读存储介质 |
| CN108182133B (zh) * | 2017-12-28 | 2022-01-14 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN108228423B (zh) * | 2017-12-28 | 2022-04-19 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN109165110A (zh) * | 2018-07-27 | 2019-01-08 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN109343996A (zh) * | 2018-10-30 | 2019-02-15 | 努比亚技术有限公司 | 移动终端重启定位方法、移动终端及计算机可读存储介质 |
| CN110087034B (zh) * | 2019-04-25 | 2020-11-10 | 山西潞安金源煤层气开发有限责任公司 | 一种煤层气远程监测*** |
| CN111090528B (zh) * | 2019-12-25 | 2023-09-26 | 北京天融信网络安全技术有限公司 | 死锁确定方法、装置及电子设备 |
| CN111159051B (zh) * | 2019-12-31 | 2023-07-04 | 北京天融信网络安全技术有限公司 | 死锁检测方法、装置、电子设备及可读存储介质 |
| CN111552618B (zh) * | 2020-05-06 | 2024-03-12 | 上海龙旗科技股份有限公司 | 一种收集日志的方法及设备 |
| CN112099960A (zh) * | 2020-09-21 | 2020-12-18 | 天津神舟通用数据技术有限公司 | 一种基于路径推进的分布式死锁检测方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103034577A (zh) * | 2011-10-08 | 2013-04-10 | 腾讯科技（深圳）有限公司 | 一种定位关机慢的方法及装置 |
| CN103399818A (zh) * | 2013-08-13 | 2013-11-20 | 中国科学技术大学苏州研究院 | 操作***中的死锁检测方法 |
-
2013
- 2013-11-21 CN CN201310594935.2A patent/CN103942113B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103034577A (zh) * | 2011-10-08 | 2013-04-10 | 腾讯科技（深圳）有限公司 | 一种定位关机慢的方法及装置 |
| CN103399818A (zh) * | 2013-08-13 | 2013-11-20 | 中国科学技术大学苏州研究院 | 操作***中的死锁检测方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN103942113A (zh) | 2014-07-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103942113B (zh) | ***重启原因的检测方法、装置及终端设备 | |
| JP6467526B2 (ja) | 通信メッセージ送信方法及びウェアラブル・デバイス | |
| CN104519485B (zh) | 一种终端之间的通信方法、装置和*** | |
| CN103389863B (zh) | 一种显示控制方法和装置 | |
| CN104902531B (zh) | 连接网络的方法、应用认证服务器、终端及路由器 | |
| CN103365419B (zh) | 一种触发闹钟控制指令的方法和装置 | |
| CN103310009B (zh) | 一种更新网页数据的方法、装置和终端设备 | |
| CN103455603A (zh) | 网页内容缓存、网页加载方法、装置及终端设备 | |
| CN104965722B (zh) | 一种显示信息的方法及装置 | |
| CN104077184B (zh) | 一种应用程序的进程控制方法及计算机*** | |
| WO2015007232A1 (en) | Method, device and mobile terminal for checking message | |
| CN106502703A (zh) | 一种函数调用方法和装置 | |
| CN105526944B (zh) | 信息提示方法及装置 | |
| CN105302452A (zh) | 一种基于手势交互的操作方法及装置 | |
| CN106550046A (zh) | 推送会员卡的方法及装置 | |
| CN103399706B (zh) | 页面交互方法、装置及终端 | |
| CN105094501A (zh) | 一种移动终端中消息的显示方法、装置和*** | |
| EP3105912B1 (en) | Application-based service providing method and system | |
| CN104901992A (zh) | 一种资源转移的方法和装置 | |
| CN103729283B (zh) | 一种***日志输出方法、装置及终端设备 | |
| CN104391629A (zh) | 定向发送消息的方法、显示消息的方法、服务器及终端 | |
| CN106681884A (zh) | 一种***调用的监控方法和装置 | |
| CN104092657A (zh) | 信息传输的方法、设备及*** | |
| CN105022621A (zh) | 收藏会话消息的方法、装置及终端 | |
| CN104346128A (zh) | 声音事件的执行方法和设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |