CN116225970B - 一种多线程程序分析方法 - Google Patents

Abstract

本发明公开了一种多线程程序分析方法，包括以下步骤：S1：构建检测工具；S2：将S1中的检测工具Attach到被测多线程程序的进程，并为每个线程注入探测程序；S3：检测工具通过探测程序实时获取各线程的互斥锁Lock/Unlock函数或者自旋锁Lock/Unlock函数的相关数据，且检测工具能够实时获取线程退出时的相关数据；S4：检测工具实时分析上述数据：分析被测多线程程序是否存在异常情况，若发现异常，检测工具分析线程死锁或线程退出未释放锁异常；若未发现异常，在被测多线程程序的进程主动退出或检测程序主动结束检测进程时，检测工具分析各线程进入临界区次数及耗时；S5：结束检测。

Description

一种多线程程序分析方法

技术领域

本发明涉及一种程序分析方法，具体涉及一种多线程程序分析方法。

背景技术

现今多核处理器已经成为主流，采用多线程技术的应用程序可以更好地利用系统资源，充分利用CPU的空闲时间片，提升应用程序运行效率，同时多线程程序的开发也会带来一些新挑战。

（1）共享资源使用不当：如进程堆栈中的关键共享数据，多线程程序在对其操作时未做好同步机制，便会造成共享数据被脏写、误读，进而对程序运行造成异常结果。

（2）线程死锁：多线程程序在互斥访问共享资源时，加解锁顺序异常造成锁环路，多个线程处于等待锁状态；线程退出时未释放持有锁，造成其他线程持续等待等，这些死锁、异常行为对应用运行造成毁灭性结果。

（3）临界区界定不准确：临界区即访问共享资源的程序片段，处于加锁和解锁中间部分的代码片段，开发者若对临界区区域界定不准确可能会造成多线程程序的性能下降。

Pthreads（POSIX threads）是POSIX的线程标准，定义了创建和操纵线程的一套API，多数被用于类UNIX系统，如Linux、FreeBSD、QNX等。在Linux操纵系统下，绝大多数应用都使用Pthreads库来实现多线程程序。

Linux操作系统下多线程程序分析方法有很多，如采用GDB、LLDB、各种Trace工具等，这些工具对排查多线程程序有一定的作用，但也存在一些缺点。

调试工具如GDB、LLDB等：通过Attach到多线程程序的进程对每个线程观察当前函数栈帧来判断当前线程是否处于wait锁状态，进而判断多个线程是否已经处于循环等待状态，这种方式实现原理是通过ptrace系统调用让被Attach的进程处于可观察状态，当被测进程被ptrace Attach后会处于等待状态，适用于开发调试环境，对于生产环境或条件有限的运行环境无法直接使用。

Trace工具如strace、valgrind、基于eBPF死锁检测工具等，使用这些工具也可以很方便的检测多线程程序的死锁，如一些基于eBPF死锁检测工具提供了一种无侵入(无需改动目标程序源代码)的检测方法，由于eBPF其原子性及安全性的特性，适用于多种复杂场景。目前这些工具功能相对比较单一，无法在检测死锁异常的同时对多线程程序进行更深入分析。

发明内容

为了完成上述目的，本发明提供了一种多线程程序分析方法，该分析方法为无侵入的检测方式，可以检测多线程死锁、检测线程退出异常、进行临界区分析。

具体的，本发明提供了一种多线程程序分析方法，包括以下步骤：

S1：构建检测工具；

S2：将S1中的检测工具Attach到被测多线程程序的进程，并为每个线程注入探测程序；

S3：检测工具通过探测程序实时获取各线程的互斥锁Lock/Unlock函数或者自旋锁Lock/Unlock函数的相关数据，且检测工具能够实时获取线程退出时的相关数据；

S4：检测工具实时分析上述数据：分析被测多线程程序是否存在异常情况，若发现异常，检测工具分析线程死锁或线程退出未释放锁异常；若未发现异常，在被测多线程程序的进程主动退出或检测程序主动结束检测进程时，检测工具分析各线程进入临界区次数及耗时；

S5：结束检测。

优选的，步骤S1中的检测工具包括注入模块和实时数据分析模块，

其中，注入模块能够采用Linux内核中的uprobe机制向被测多线程程序的进程所引用的Pthreads动态库注入探测程序；

实时数据分析模块能够利用注入模块获取的数据，实时分析被测多线程程序的进程中各线程当前的状态。

进一步优选的，注入模块能够通过Linux内核中的tracepoint跟踪机制跟踪内核函数sched_process_exit，以便获取用户线程的退出事件。

更进一步优选的，注入模块向被测多线程程序的进程注入探测程序时：

当线程的锁为互斥锁Lock函数与互斥锁Unlock函数时，探测程序注入互斥锁Unlock函数的注入点早于互斥锁Lock函数的注入点注入；

当线程的锁为自旋锁Lock函数与自旋锁Unlock函数时，探测程序注入自旋锁Unlock函数的注入点早于自旋锁Lock函数的注入点注入。

更进一步优选的，步骤S2还包括以下步骤：

S21：检测工具从被测多线程程序的进程的PID/maps文件中获取被测多线程程序的进程引用的Pthreads动态库路径；

S22：通过注入模块将基于uprobe机制的探测程序注入S21中的Pthreads动态库；

S23：通过注入模块注册Linux内核函数sched_process_exit tracepoint；

S24：检测工具Attach到被测多线程程序的进程。

更进一步优选的，步骤S3通过骤S22和S23实时获取各个线程和线程退出时的相关数据，其中：

在步骤S22中基于uprobe机制的探测程序会在互斥锁Lock函数、互斥锁Unlock函数、自旋锁Lock函数与自旋锁Unlock函数注入点执行，获取互斥锁变量值、自旋锁变量值、当前线程内核角度的PID、当前时间的时间戳、加解锁状态数据；

在步骤S23中，注入模块通过tracepoint跟踪机制跟踪内核函数sched_process_exit获取当前系统中所有退出的程序的进程并将数据传输到实时数据分析模块，实时数据分析模块通过步骤S24获取被测多线程程序的进程的PID，实时数据分析模块判断当前触发的进程退出事件是否属于当前被测多线程程序的进程。

更进一步优选的，在步骤S4中，判断死锁步骤包括以下步骤：

S411：检测工具的实时分析模块为被测多线程程序维护一个由有向图构建的锁状态数组，当有被测多线程程序的线程的互斥锁或自旋锁变量申请加锁时，遍历当前锁状态数组中其他已拥有锁，分别以申请加锁变量为头，其他已拥有锁为尾作为有向图的边进而构建有向图，并将当前锁变量录入锁状态数组；当有互斥锁或自旋锁变量解锁时删除对应锁状态数组中的对应项；

S412：实时分析模块对当前构造的有向图进行深度优先遍历判断是否存在环路，若存在代表被测多线程程序的进程中的线程已经发生了死锁，实时分析模块输出其死锁关系及对应线程PID。

更进一步优选的，在步骤S4中，判断线程退出异常步骤如下：

S421：通过tracepoint跟踪机制跟踪内核函数sched_process_exit获取的用户线程退出事件，结合检测工具的实时分析模块为每个线程维护的锁状态数组，判断退出时锁状态数组是否为空，不为空则代表发现异常。

更进一步优选的，在步骤S4中，临界区分析步骤如下：

S431：检测工具的实时分析模块维护一个加解锁记录表，表项为线程PID、锁变量值、加解锁状态、时间戳，当线程发生加解锁操作时在记录表中填充一条记录；

S432：被测多线程程序的进程退出或检测工具主动结束检测进程时，分析加解锁记录表获取对应线程不同锁变量对应临界区的进入次数及耗时；

S433：输出每个线程在不同临界区进入次数及耗时，并执行步骤S5。

本发明的有益效果为：

本发明的一种多线程程序分析方法，不仅可以满足对多线程程序以一种无侵入方式的死锁、线程退出异常排查，而且能够对多线程中的临界区性能进行分析，方便开发者在对多线程程序设计过程中，规避异常、提升多线程程序的性能。另外，本发明还能够能对多线程程序中临界区分析包含各个线程进入临界区次数、耗时等，有利用进一步分析多线程程序性能。

附图说明

下面结合附图和具体实施方式对本发明作进一步详细的说明。

图1是本发明的多线程程序分析方法具体实施例的流程示意图；

图2是本发明的检测工具的工作流程示意图；

图3是本发明的注入模块的工作流程示意图；

图4是本发明的实时分析模块的数据分析流程示意图；

图5是本发明的锁状态数组的示意图。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其他不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。

如图1所示，本发明提供了一种多线程程序分析方法，包括以下步骤：

步骤S1：构建检测工具。

如图2所示，步骤S1中的检测工具包括注入模块和实时数据分析模块，

其中，如图3所示，注入模块能够采用Linux内核中的uprobe机制向被测多线程程序的进程所引用的Pthreads动态库注入探测程序，其中，注入模块向被测多线程程序的进程注入探测程序时：当线程的锁为互斥锁Lock函数与互斥锁Unlock函数时，探测程序注入互斥锁Unlock函数的注入点早于互斥锁Lock函数的注入点注入；当线程的锁为自旋锁Lock函数与自旋锁Unlock函数时，探测程序注入自旋锁Unlock函数的注入点早于自旋锁Lock函数的注入点注入，以免逻辑异常造成误判。

另外，注入模块还能够采用Linux内核中的tracepoint跟踪机制跟踪内核函数sched_process_exit，以便获取用户线程退出事件。

实时数据分析模块能够利用注入模块获取的数据，实时分析多线程程序当前的状态。

步骤S2：将S1中的检测工具Attach到被测多线程程序的进程，并为每个线程注入探测程序；

S21：检测工具从/proc/被测多线程程序的进程的PID/maps文件中获取被检测进程引用的Pthreads动态库路径；

S22：将基于uprobe机制的探测程序注入S21中的Pthreads动态库；

S23：注册Linux内核函数sched_process_exit tracepoint；

S24：检测工具Attach到被测多线程程序的进程。

步骤S3：检测工具通过探测程序实时获取各线程的互斥锁Lock/Unlock函数或者自旋锁Lock/Unlock函数的相关数据（即图4中的加解锁信息），且检测工具能够实时获取线程退出时的相关数据（即图4中的线程退出信息）。

步骤S3基于上文的步骤S22和S23，通过如下步骤实时获取各个线程和线程退出时的相关数据，其中：

在步骤S22中基于uprobe机制的探测程序会在互斥锁Lock函数、互斥锁Unlock函数、自旋锁Lock函数与自旋锁Unlock函数注入点执行，获取互斥锁变量值、自旋锁变量值、当前线程内核角度的PID、当前时间的时间戳、加解锁状态数据。

在步骤S23中，注入模块通过内核函数tracepoint sched_process_exit 获取当前系统中所有退出的程序的进程并将数据传输到实时数据分析模块，实时数据分析模块通过步骤S24中获取被检测进程内核角度的PID，实时数据分析模块判断当前触发的用户线程退出事件是否属于当前被测用户进程。

这里因为uprobe、tracepoint工作在内核，在Linux内核中并没有区分进程与线程。在Linux内核中可以通过PID、TGID区分进程与线程，在用户角度的主进程即表示为PID等于TGID的进程，其他线程拥有与主进程一样的TGID，不同的PID。

如图1所示，步骤S4：检测工具实时分析上述数据：分析被测多线程程序是否存在异常情况，若发现异常，检测工具分析线程死锁或线程退出未释放锁异常（即图1中的“致命异常”）；若未发现异常，在被测多线程程序的进程主动退出或主动结束检测进程时，检测工具分析各线程进入临界区次数及耗时。

在步骤S4中，判断死锁步骤包括以下步骤：

S411：检测工具的实时数据分析模块为被测多线程程序维护一个锁状态数组：当有互斥锁或自旋锁变量的线程申请加锁时，遍历当前锁状态数组中其他已拥有锁，以申请加锁变量为头，其他已拥有锁为尾作为有向图的边构建有向图，并将当前锁变量（即新申请加入的互斥锁或自旋锁变量）录入锁状态数组；当有互斥锁或自旋锁变量解锁时删除对应锁状态数组中的对应项。如图5所示，被测多线程程序中的每个线程均有锁，当线程1已经拥有锁A，线程1继续申请锁B，线程2拥有锁B，因此，以锁A为头，锁B为尾构建有向图。线程2拥有锁B，线程2继续申请锁C，因此，以锁B为头，锁C为尾构建有向图。多个线程的锁相互一起构成锁状态数组。

S412：实时数据分析模块对当前构造的有向图进行深度优先遍历判断是否存在环路，若存在代表被测多线程程序的进程中已经发生了死锁，实时数据分析模块输出其死锁关系及对应线程PID。

在步骤S4中，判断线程退出异常步骤如下：

S421：通过tracepoint跟踪机制跟踪内核函数 sched_process_exit获取以便线程退出事件，结合检测工具的实时数据分析模块为每个线程维护的锁状态数组，判断退出时锁状态数组是否为空，不为空则代表发现异常，代表线程已退出但已持有锁变量未释放。其中，tracepoint是Linux内核中的一种trace技术，在内核源代码中包含很多trace点，sched_process_exit就是其中一个，在进程（线程）退出时内核会触发此函数，利用这个函数trace点就能判断应用进程中的线程退出。

在步骤S4中，临界区分析步骤如下：

S431：检测工具的实时分析模块维护一个加解锁记录表，表项为线程PID、锁变量值、加解锁状态、时间戳，当线程发生加解锁操作时在记录表中填充一条记录；

S432：被测多线程程序的进程退出或主动结束检测进程时，分析加解锁记录表获取对应线程不同锁变量对应临界区的进入次数及耗时；

S433：输出每个线程在不同临界区进入次数及耗时，执行步骤S5。

S5：结束检测。

为使本发明的目的、技术方案和优点更加清楚明了，下面以在x86平台Kylin V10SP1桌面版操作系统上对多线程程序分析方法为实施例，对本发明进一步详细说明。

本实施例的一种多线程程序分析方法包括以下步骤：

S1：构建基于eBPF检测工具；

S2：将S1中检测工具Attach到被测的多线程程序，并为每个线程注入探测程序；

S3：检测工具通过探测程序实时获取各线程的互斥锁Lock/Unlock函数或者自旋锁Lock/Unlock函数的相关数据（即图4中的加解锁信息），且检测工具能够实时获取线程退出时的相关数据（即图4中的线程退出信息）；

S4：检测工具实时分析上述数据：分析被测多线程程序是否存在异常，若发现异常，检测工具分析线程死锁关系或线程退出未释放锁异常；若未发现异常，直到被检测进程退出或主动结束检测进程，检测工具分析各线程进入临界区次数及耗时；

S5：结束检测。

本实施例中，步骤S1中“构建基于eBPF检测工具”具体包括：采用eBPF技术实现，分为内核态程序和用户态程序并通过map机制通信，一般情况下内核态程序负责在每个注入点获取关心的数据；用户态程序负责分析和组织这些数据。

注入模块为eBPF的内核态程序，最终被编译为BPF字节码被注入内核，实时数据分析模块为对应用户态程序，最终被编译为二进制可执行文件。

其中，注入模块的具体实现步骤为：1.使用eBPF uprobe实现的内核态程序为Pthreads动态库中pthread_mutex_lock、pthread_mutex_unlock、pthread_spin_lock、pthread_spin_unlock函数实现Hook功能。Hook的程序会在这些函数被执行的时候调用，以获取互斥锁变量值、自旋锁变量值、当前线程PID、当前时间的时间戳、加解锁状态，其中在eBPF内核态程序中维护两个map，map1存储有向图的边信息包含线程PID、已拥有锁的变量、申请锁变量，map2存储每个线程的加解锁信息包含线程PID、加解锁状态、锁变量、时间戳。这里的时间戳主要有两个作用：1.对捕获到的所有申请锁，释放锁进行排序，因为在多核架构中，申请释放不同的锁可能在不同的核上发生，获取时间戳将它们排序获取加解锁的前后逻辑关系；2.获取加解锁时间戳从而获取临界区耗时。

使用eBPF 定义sched_process_exit tracepoint内核态程序，并维护一个map3，用来保存退出的已退出线程PID。

实时数据分析模块的具体实现步骤为：eBPF用户态程序将内核态程序注入到内核，并根据以上注入模块定义的三个map实时获取数据，分析多线程程序当前状态。

本实施例中，步骤S2“将S1中检测工具Attach到被测的多线程程序”具体步骤如下：

S21：检测工具从/proc/(被检测进程PID)/maps文件中获取被检测进程引用的Pthreads动态库路径；

S22：构建S21所获取Pthreads动态库中的pthread_mutex_lock、pthread_mutex_unlock、pthread_spin_lock、pthread_spin_unlock uprobe函数及包含两个map结构的eBPF程序，将其编译为BPF字节码后由检测工具注入内核；

S23：构建sched_process_exit tracepoint并包含一个map结构的eBPF程序，将其编译为 BPF字节码后由检测工具注入内核；

S24：检测工具Attach到被测多线程程序的进程，通过系统调用将eBPF程序与被测进程的绑定。

本实施例中，步骤S3具体实现步骤如下：

通过步骤S22，所构建的uprobe eBPF程序会在加解锁函数被执行的时候调用，以获取互斥锁变量值、自旋锁变量值、当前线程PID、当前时间的时间戳、加解锁状态，其中在eBPF内核态程序中维护两个map，map1存储有向图的边信息包含线程PID、已拥有锁的变量、申请锁变量，map2存储每个线程的加解锁信息包含线程PID、加解锁状态、锁变量、时间戳。

通过步骤S23，所构建的tracepoint eBPF程序会在线程退出时调用，将已退出线程PID保存至map结构map3。

由以上map结构的数据对多线程进程实时分析。

本实施例中，步骤S4“分析被测多线程程序是否存在异常，若发现异常，检测工具分析线程死锁关系或线程退出未释放锁异常，若未发现异常，直到被检测进程退出或主动结束出检测进程，检测工具分析各线程进入临界区次数及耗时。”具体实现步骤如下：

其中，步骤S4中“判断是否存在死锁”的实现步骤如下：

S411：在eBPF内核态程序中为每个线程维护一个锁状态数组，当有互斥锁或自旋锁变量申请加锁时，遍历当前锁状态数组中其他已拥有锁，分别以申请加锁变量为头，其他已拥有锁的变量（申请锁时，其他已拥有锁的变量为尾构建有向图的边后，会将此申请锁放入锁状态数组，这个锁状态数组就是所有已拥有锁变量）为尾构建有向图的边将其放入map1，并将当前锁变量录入数组；当有互斥锁或自旋锁变量时解锁删除对应锁状态数组中的对应项。

S412：eBPF用户态程序不断对当前构造的有向图进行深度优先遍历判断是否存在环路，若存在代表被测检测已经发生了死锁，并输出其死锁关系及对应线程PID。

步骤S4中“判断线程是否存在退出异常”的实现步骤如下：

S421：检测工具中eBPF内核态tracepoint程序被触发时，判断当前退出线程的锁状态数组是否为空，不为空则将线程PID计入map3，代表线程退出但已持有锁未释放。

步骤S4中“对临界区进行分析”的实现步骤如下

S431：由检测工具中eBPF内核态程序维护的加解锁记录表map2，用于记录线程PID、锁变量值、加解锁状态、时间戳，当线程加解锁时则在记录表中填充一条记录。

S432：被检测进程退出或主动结束检测进程时，eBPF用户态程序分析加解锁记录表，对应同一个线程汇总不同锁变量对应临界区(加锁和解锁之间的区域)的进入次数及耗时。

S433：输出每个线程在不同临界区进入次数及耗时，结束检测。

本实施例中采用eBPF技术实现检测工具，包含内核态观测程序及用户态数据分析程序，通过内核uprobe机制对Pthreads动态库加解锁函数注入Hook程序；内核tracepoint获取线程退出状态，并将核心数据存储到map与用户态程序通信，实时分析数据获取多线程程序的进程中各线程是否发生了异常、分析每个线程在临界区的性能指标。

显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

Claims (4)

1.一种多线程程序分析方法，其特征在于，包括以下步骤：

S1：构建检测工具；

步骤S1中的检测工具包括注入模块和实时数据分析模块，

其中，所述注入模块能够采用Linux内核中的uprobe机制向被测多线程程序的进程所引用的Pthreads动态库注入探测程序；

所述实时数据分析模块能够利用注入模块获取的数据，实时分析被测多线程程序的进程中各线程当前的状态；

所述注入模块能够通过Linux内核中的tracepoint跟踪机制跟踪内核函数sched_process_exit，以便获取用户线程的退出事件；

所述注入模块向被测多线程程序的进程注入探测程序时：

当线程的锁为互斥锁Lock函数与互斥锁Unlock函数时，探测程序注入互斥锁Unlock函数的注入点早于互斥锁Lock函数的注入点注入；

当线程的锁为自旋锁Lock函数与自旋锁Unlock函数时，探测程序注入自旋锁Unlock函数的注入点早于自旋锁Lock函数的注入点注入；

S2：将S1中的检测工具Attach到被测多线程程序的进程，并为每个线程注入探测程序；

步骤S2还包括以下步骤：

S21：所述检测工具从被测多线程程序的进程的PID/maps文件中获取被测多线程程序的进程引用的Pthreads动态库路径；

S22：通过所述注入模块将基于uprobe机制的探测程序注入S21中的Pthreads动态库；

S23：通过所述注入模块注册Linux内核函数sched_process_exit tracepoint；

S24：所述检测工具Attach到被测多线程程序的进程；

S3：检测工具通过探测程序实时获取各线程的互斥锁Lock/Unlock函数或者自旋锁Lock/Unlock函数的相关数据，且检测工具能够实时获取线程退出时的相关数据；

步骤S3通过骤S22和S23实时获取各个线程和线程退出时的相关数据，其中：

在步骤S22中基于uprobe机制的探测程序会在互斥锁Lock/Unlock函数、自旋锁Lock/Unlock函数注入点执行，获取互斥锁变量值、自旋锁变量值、当前线程内核角度的PID、当前时间的时间戳、加解锁状态数据；

在步骤S23中，注入模块通过tracepoint跟踪机制跟踪内核函数sched_process_exit获取当前系统中所有退出的程序的进程并将数据传输到实时数据分析模块，实时数据分析模块通过步骤S24获取被测多线程程序的进程的PID，实时数据分析模块判断当前触发的进程退出事件是否属于当前被测多线程程序的进程；

S4：检测工具实时分析上述数据：分析被测多线程程序是否存在异常情况，若发现异常，检测工具分析线程死锁或线程退出未释放锁异常；若未发现异常，在被测多线程程序的进程主动退出或检测程序主动结束检测进程时，检测工具分析各线程进入临界区次数及耗时；

S5：结束检测。

2.根据权利要求1所述的一种多线程程序分析方法，其特征在于，在步骤S4中，判断死锁步骤包括以下步骤：

S411：检测工具的实时分析模块为被测多线程程序维护一个由有向图构建的锁状态数组，当有被测多线程程序的线程的互斥锁或自旋锁变量申请加锁时，遍历当前锁状态数组中其他已拥有锁，分别以申请加锁变量为头，其他已拥有锁为尾作为有向图的边进而构建有向图，并将当前锁变量录入锁状态数组；当有互斥锁或自旋锁变量解锁时删除对应锁状态数组中的对应项；

S412：实时分析模块对当前构造的有向图进行深度优先遍历判断是否存在环路，若存在代表被测多线程程序的进程中的线程已经发生了死锁，实时分析模块输出其死锁关系及对应线程PID。

3.根据权利要求2所述的一种多线程程序分析方法，其特征在于，在步骤S4中，判断线程退出异常步骤如下：

S421：通过tracepoint跟踪机制跟踪内核函数sched_process_exit获取的用户线程退出事件，结合检测工具的实时分析模块为每个线程维护的锁状态数组，判断退出时锁状态数组是否为空，不为空则代表发现异常。

4.根据权利要求3所述的一种多线程程序分析方法，其特征在于，在步骤S4中，临界区分析步骤如下：

S431：检测工具的实时分析模块维护一个加解锁记录表，表项为线程PID、锁变量值、加解锁状态、时间戳，当线程发生加解锁操作时在记录表中填充一条记录；

S432：被测多线程程序的进程退出或检测工具主动结束检测进程时，分析加解锁记录表获取对应线程不同锁变量对应临界区的进入次数及耗时；

S433：输出每个线程在不同临界区进入次数及耗时，并执行步骤S5。