(一)JMM基础-计算机原理

 

 

Java内存模型即Java Memory Model,简称JMM。

 

JMM定义了Java 虚拟机(JVM)在计算机内存(RAM)中的工作方式。JVM是整个计算机虚拟模型,所以JMM是隶属于JVM的。Java1.5版本对其进行了重构,现在的Java仍沿用了Java1.5的版本。Jmm遇到的问题与现代计算机中遇到的问题是差不多的。

 

物理计算机中的并发问题,物理机遇到的并发问题与虚拟机中的情况有不少相似之处,物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。

根据《Jeff Dean在Google全体工程大会的报告》我们可以看到

image.png

计算机在做一些我们平时的基本操作时,需要的响应时间是不一样的。

(以下案例仅做说明,并不代表真实情况。)

 

如果从内存中读取1M的int型数据由CPU进行累加,耗时要多久?

 

做个简单的计算,1M的数据,Java里int型为32位,4个字节,共有1024*1024/4 = 262144个整数 ,则CPU 计算耗时:262144 *0.6 = 157 286 纳秒,而我们知道从内存读取1M数据需要250000纳秒,两者虽然有差距(当然这个差距并不小,十万纳秒的时间足够CPU执行将近二十万条指令了),但是还在一个数量级上。但是,没有任何缓存机制的情况下,意味着每个数都需要从内存中读取,这样加上CPU读取一次内存需要100纳秒,262144个整数从内存读取到CPU加上计算时间一共需要262144*100+250000 = 26 464 400 纳秒,这就存在着数量级上的差异了。

 

而且现实情况中绝大多数的运算任务都不可能只靠处理器“计算”就能完成,处理器至少要与内存交互,如读取运算数据、存储运算结果等,这个I/O操作是基本上是无法消除的(无法仅靠寄存器来完成所有运算任务)。早期计算机中cpu和内存的速度是差不多的,但在现代计算机中,cpu的指令速度远超内存的存取速度,由于计算机的存储设备与处理器的运算速度有几个数量级的差距,所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存(Cache)来作为内存与处理器之间的缓冲:将运算需要使用到的数据复制到缓存中,让运算能快速进行,当运算结束后再从缓存同步回内存之中,这样处理器就无须等待缓慢的内存读写了。

 

cpu在执行过程中,它的执行效率要比内存的运算速度要高的高的多.所以为了解决CPU里面的运算效率和内存运算效率之间的差异,在我们的内存和cpu之间会存在一个cpu高速缓存.

 

image.png 

在计算机系统中,寄存器划是L0级缓存,接着依次是L1,L2,L3(接下来是内存,本地磁盘,远程存储)。越往上的缓存存储空间越小,速度越快,成本也更高;越往下的存储空间越大,速度更慢,成本也更低。从上至下,每一层都可以看做是更下一层的缓存,即:L0寄存器是L1一级缓存的缓存,L1是L2的缓存,依次类推;每一层的数据都是来至它的下一层,所以每一层的数据是下一层的数据的子集。

 

 

在现代CPU上,一般来说L0, L1,L2,L3都集成在CPU内部,而L1还分为一级数据缓存(Data Cache,D-Cache,L1d)和一级指令缓存(Instruction Cache,I-Cache,L1i),分别用于存放数据和执行数据的指令解码。每个核心拥有独立的运算处理单元、控制器、寄存器、L1、L2缓存,然后一个CPU的多个核心共享最后一层CPU缓存L3

 

image.png

 

性能测试图(L1 L2 L3图)

image.png


(一)物理内存模型带来的问题

 

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾,但是也为计算机系统带来更高的复杂度,因为它引入了一个新的问题:缓存一致性(Cache Coherence)。在多处理器系统中,每个处理器都有自己的高速缓存,而它们又共享同一主内存(MainMemory)当多个处理器的运算任务都涉及同一块主内存区域时,将可能导致各自的缓存数据不一致

 

现代的处理器使用写缓冲区临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行,它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。同时,通过以批处理的方式刷新写缓冲区,以及合并写缓冲区中对同一内存地址的多次写,减少对内存总线的占用。虽然写缓冲区有这么多好处,但每个处理器上的写缓冲区,仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响:处理器对内存的读/写操作的执行顺序,不一定与内存实际发生的读/写操作顺序一致。

image.png


image.png 


处理器A和处理器B按程序的顺序并行执行内存访问,最终可能得到x=y=0的结果。

 

处理器A和处理器B可以同时把共享变量写入自己的写缓冲区(步骤A1,B1),然后从内存中读取另一个共享变量(步骤A2,B2),最后才把自己写缓存区中保存的脏数据刷新到内存中(步骤A3,B3)。当以这种时序执行时,程序就可以得到x=y=0的结果。

 

从内存操作实际发生的顺序来看,直到处理器A执行A3来刷新自己的写缓存区,写操作A1才算真正执行了。虽然处理器A执行内存操作的顺序为:A1→A2,但内存操作实际发生的顺序却是A2→A1。

 

如果真的发生这种情况,那同步回到主内存时以谁的缓存数据为准呢?为了解决一致性的问题,需要各个处理器访问缓存时都遵循一些协议,在读写时要根据协议来进行操作,这类协议有MSI、MESI(Illinois Protocol)、MOSI、Synapse、Firefly及Dragon Protocol等。

 

image.png 

 

 

最出名的就是Intel 的MESI协议,MESI协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是:当CPU写数据时,如果发现操作的变量是共享变量,即在其他CPU中也存在该变量的副本,会发出信号通知其他CPU将该变量的缓存行置为无效状态,因此当其他CPU需要读取这个变量时,发现自己缓存中缓存该变量的缓存行是无效的,那么它就会从内存重新读取。

 

具体参考百度百科

 

https://baike.baidu.com/item/%E7%BC%93%E5%AD%98%E4%B8%80%E8%87%B4%E6%80%A7/15814005?fr=aladdin

 

 

1.伪共享

 

演示代码:zjj_parent_b69dd541-bce8-5f8b-85db-03f7d1cc1c7a

 

前面我们已经知道,CPU中有好几级高速缓存。但是CPU缓存系统中是以缓存行(cache line)为单位存储的。目前主流的CPU Cache的Cache Line(缓存行)大小都是64Bytes。

 

Cache Line可以简单的理解为CPU Cache中的最小缓存单位,今天的CPU不再是按字节访问内存,而是以64字节为单位的块(chunk)拿取,称为一个缓存行(cache line)。当你读一个特定的内存地址,个缓存行将从主存换入缓存

 

什么是伪共享

 

一个缓存行可以存储多个变量(存满当前缓存行的字节数);而CPU对缓存的修改又是以缓存行为最小单位的,在多线程情况下,如果需要修改“共享同一个缓存行的变量”,就会无意中影响彼此的性能,这就是伪共享(False Sharing)。

 

 

image.png 

x和y毫无关系,但是放在同一个缓存行里面了,这就产生了竞争情况,对性能会产生影响

 

假如一个CPU核心的线程在对x进行修改,另一个CPU核心的线程却对y进行读取,当前者修改了x时,会把x和y同时加载到前者的核心的缓存行中,更新完x后其它所有包含x的缓存行都将失效,因为其它缓存中的x已经不是最新的值了

而当后者读取y的时候,发现缓存行已经失效了,需要重写从主内存中重写加载.

 

我们的缓存都是以缓存行作为一个单位来处理的,所以失效x的缓存的同时,也会把y失效,反之亦然.这就出现了一个问题,y和x完全不相干,每次却因为x的更新需要重新从主内存读取.它被缓存未命中给拖慢了,这就是伪共享.

 

 

解决伪共享

 

为了避免伪共享,我们可以使用数据填充的方式来避免,即单个数据填充满一个CacheLine。这本质是一种空间换时间的做法。但是这种方式在Java7以后可能失效。

 

Java8中已经提供了官方的解决方案,Java8中新增了一个注解@sun.misc.Contended。

 

比如JDK的ConcurrentHashMap中就有使用

image.png 

加上这个注解的类会自动补齐缓存行,需要注意的是此注解默认是无效的,需要在jvm启动时设置-XX:-RestrictContended才会生效

 

一个类中,只有一个long类型的变量:

image.png 

定义一个VolatileLong类型的数组,然后让多个线程同时并发访问这个数组,这时可以想到,在多个线程同时处理数据时,数组中的多个VolatileLong对象可能存在同一个缓存行中

image.png 

运行后,可以得到运行时间

image.png 

花费了39秒多。

我们改用进行了缓存行填充的变量

image.png 

花费了8.1秒,如果任意注释上下填充行的任何一行,时间表现不稳定,从8秒到20秒都有,但是还是比不填充要快。具体原因目前未知。

再次改用注解标识的变量,同时加入参数-XX:-RestrictContended

image.pngimage.png 

花费了7.7秒。

由上述的实验结果表明,伪共享确实会影响应用的性能。

  

(一)Java内存模型带来的问题

 

1.Java内存模型概述

从抽象的角度来看,JMM定义了线程和主内存之间的抽象关系:线程之间的共享变量存储在主内存(Main Memory)中,每个线程都有一个私有的本地内存(Local Memory),我们称之为工作内存,本地内存(工作内存)中存储了该线程以读/写共享变量的副本。

 

每个线程在对某个值进行操作的时候,它不是直接读写主内存里面的这个值,而是把主内存的这个值拿出来读取到工作内存里面,每个线程内部工作内存这个值副本,这个工作内存每个线程自己看到,它们是线程隔离的,也就是说线程A的工作内存不能访问线程B的工作内存.

 

本地内存(工作内存)是JMM的一个抽象概念,并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。

image.pngimage.png 

1.可见性问题

 image.png 

线程2在对count进行操作了.在自己的工作内存给count改成了2, 此时线程1看不到count改成了2(线程1看不到线程2的工作内存的内容),只要线程2没有把内容(count = 2)更新到主内存里面,此时线程1读取的永远是旧的值(就是count为1),这就是所谓的可见性问题.

 

 

在多线程的环境下,假如两个线程都是一次运行,此时工作内存里面是没有count变量的,如果某个线程首次读取共享变量(count变量),则首先到主内存中获取该变量,然后存入自己的工作内存中,以后只需要在工作内存中读取该变量即可,在后面的运算过程中,它发现它的工作内存中已经有了这个count共享变量的时候,它就很有可能不会在主内存中读取这个变量了.

 

同样如果对该变量执行了修改的操作,则先将新值写入自己的工作内存中,然后再刷新至主内存中。但是工作内存什么时候最新的值会被刷新至主内存中是不太确定,一般来说会很快,但具体时间不知。

 

要解决共享对象可见性这个问题,我们可以使用volatile关键字或者是加锁,CAS操作也行

 

总结:

 

当多个线程访问同一个变量时,一个线程修改了这个变量的值,其他线程能够立即看得到修改的值,这就是可见性.

 

若两个线程在不同的cpu,那么线程1改变了i的值还没刷新到主存,线程2又使用了i,那么这个i值肯定还是之前的,线程1对变量的修改线程没看到这就是可见性问题。 



 

1.原子性问题(竞争问题)

 

线程A和线程B共享一个对象obj。假设线程A从主存读取Obj.count变量到自己的CPU缓存,同时,线程B也读取了Obj.count变量到它的CPU缓存,并且这两个线程都对Obj.count做了加1操作。此时,Obj.count加1操作被执行了两次,不过都在不同的CPU缓存中。




image.png


如果这两个加1操作是串行执行的,那么Obj.count变量便会在原始值上加2,最终主存中的Obj.count的值会是3。

 

然而图中两个加1操作是并行的,不管是线程A还是线程B先flush计算结果到主存,最终主存中的Obj.count只会增加1次,结果是count=2,尽管一共有两次加1操作,但是有的一个操作丢失了,这就是所谓的竞争问题。 要解决上面的问题我们可以使用java synchronized代码块(逼迫两个并行的操作变成串行操作).

 

原子性其实就是保证数据一致、线程安全一部分.

 

保证原子性: Synchronized , AtomicInteger , Lock

 

1.重排序

 

一般来说处理器为了提高程序运行效率,提高性能,可能会对输入代码进行优化,它不保证程序中各个语句的执行先后顺序同代码中的顺序一致,但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。如下:

 

int a = 10;    //语句1

int r = 2;    //语句2

a = a + 3;    //语句3

r = a*a;     //语句4

 

则因为重排序,他还可能执行顺序为 2-1-3-41-3-2-4


但绝不可能 2-1-4-3,因为这打破了依赖关系。
显然重排序对单线程运行是不会有任何问题,而多线程就不一定了,所以我们在多线程编程时就得考虑这个问题了。

 

我们写的代码,编译器会把语句执行顺序进行调整, cpu不是按顺序执行的,会对指令进行重排序,会把多个指令重叠执行,甚至会提前执行,这就是重排序.

 

多线程重排序问题:

 

文档:[和笔记对接]深入理解Java内存模型—重...

链接:http://note.youdao.com/noteshare?id=7ffec6df578f5ad10e23138be32eaf47&sub=2D856F77F2924A0496B1961211A6C2BE

 

 

 

重排序类型

 

除了共享内存和工作内存带来的问题,还存在重排序的问题:在执行程序时,为了提高性能,编译器和处理器常常会对指令做重排序。重排序分3种类型。

 

1)编译器优化的重排序。编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。

 

2)指令级并行的重排序。现代处理器采用了指令级并行技术(Instruction-LevelParallelism,ILP)来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。

 

3)内存系统的重排序。由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。

 

数据依赖性

 

如果两个操作访问同一个变量,且这两个操作中有一个为写操作,此时这两个操作之间就存在数据依赖性。数据依赖分为下列3种类型,上面3种情况,只要重排序两个操作的执行顺序,程序的执行结果就会被改变。


image.png



例如:

image.png


很明显,A和C存在数据依赖,B和C也存在数据依赖,而A和B之间不存在数据依赖,如果重排序了A和C或者B和C的执行顺序,程序的执行结果就会被改变。

很明显,不管如何重排序,都必须保证代码在单线程下的运行正确,连单线程下都无法正确,更不用讨论多线程并发的情况,所以就提出了一个as-if-serial的概念。

as-if-serial

as-if-serial语义的意思是:不管怎么重排序(编译器和处理器为了提高并行度),(单线程)程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

 

为了遵守as-if-serial语义,编译器和处理器不会对存在数据依赖关系的操作做重排序,因为这种重排序会改变执行结果。(强调一下,这里所说的数据依赖性仅针对单个处理器中执行的指令序列和单个线程中执行的操作,不同处理器之间和不同线程之间的数据依赖性不被编译器和处理器考虑。)但是,如果操作之间不存在数据依赖关系,这些操作依然可能被编译器和处理器重排序。

 

A和C之间存在数据依赖关系,同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中,C不能被重排序到A和B的前面(C排到A和B的前面,程序的结果将会被改变)。但A和B之间没有数据依赖关系,编译器和处理器可以重排序A和B之间的执行顺序。

 

image.pngimage.png


as-if-serial语义把单线程程序保护了起来,遵守as-if-serial语义的编译器、runtime和处理器可以让我们感觉到:单线程程序看起来是按程序的顺序来执行的。asif-serial语义使单线程程序员无需担心重排序会干扰他们,也无需担心内存可见性问题。

 

控制依赖性  


image.png



上述代码中,flag变量是个标记,用来标识变量a是否已被写入,在use方法中变量i的赋值依赖if (flag)的判断,这里就叫控制依赖,如果发生了重排序,结果就不对了。

考察代码,我们可以看见,

 

操作1和操作2没有数据依赖关系,编译器和处理器可以对这两个操作重排序;同样,操作3和操作4没有数据依赖关系,编译器和处理器也可以对这两个操作重排序。操作3和操作4则存在所谓控制依赖关系

 

在程序中,当代码中存在控制依赖性时,会影响指令序列执行的并行度。为此,编译器和处理器会采用猜测(Speculation)执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例,执行线程B的处理器可以提前读取并计算a*a,然后把计算结果临时保存到一个名为重排序缓冲(Reorder Buffer,ROB)的硬件缓存中。当操作3的条件判断为真时,就把该计算结果写入变量i中。猜测执行实质上对操作3和4做了重排序,问题在于这时候,a的值还没被线程A赋值

 

在单线程程序中,对存在控制依赖的操作重排序,不会改变执行结果(这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因)。

 

但是对多线程来说就完全不同了:这里假设有两个线程A和B,A首先执行init ()方法,随后B线程接着执行use ()方法。线程B在执行操作4时,能否看到线程A在操作1对共享变量a的写入呢?答案是:不一定能看到。

 

让我们先来看看,当操作1和操作2重排序,操作3和操作4重排序时,可能会产生什么效果?操作1和操作2做了重排序。程序执行时,线程A首先写标记变量flag,随后线程B读这个变量。由于条件判断为真,线程B将读取变量a。此时,变量a还没有被线程A写入,这时就会发生错误!

所以在多线程程序中,对存在控制依赖的操作重排序,可能会改变程序的执行结果。

 

 

1.内存屏障

 

Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序,从而让程序按我们预想的流程去执行。

 

1、保证特定操作的执行顺序。

2、影响某些数据(或则是某条指令的执行结果)的内存可见性。

 

编译器和CPU能够重排序指令,保证最终相同的结果,尝试优化性能。插入一条Memory Barrier会告诉编译器和CPU:不管什么指令都不能和这条Memory Barrier指令重排序。

 

Memory Barrier所做的另外一件事是强制刷出各种CPU cache,如一个Write-Barrier(写入屏障)将刷出所有在Barrier之前写入 cache 的数据,因此,任何CPU上的线程都能读取到这些数据的最新版本。

 

JMM把内存屏障指令分为4类:


屏障类型

指令示例

说明

LoadLoad Barriers

Load1;LoadLoad;Load2

确保Load1的数据的装载先于Load2及所有后续装载指令的装载

StoreStoreBarriers

Store1;StoreStore;Store2

确保Store1数据对其他处理器可见(刷新到内存)先于Store2及所有后续存储指令的存储

LoadStore Barriers

Load1;LoadStore;Store2

确保Load1的数据的装载先于Store2及所有后续存储指令的存储

StoreLoad Barriers

Store1;StoreLoad;Load2

确保Store1的数据对其他处理器可见(刷新到内存)先 于Load2及所有后续的装载指令的装载.StoreLoad Barriers会使该屏障之前的所有内存访问指令(存储和装载指令)完成之后,才执行该屏障之后的内存访问指令

LoadLoad屏障:

 

抽象场景:Load1; LoadLoad; Load2

 

Load1 和 Load2 代表两条读取指令。在Load2要读取的数据被访问前,保证Load1要读取的数据被读取完毕。

 

StoreStore屏障:

 

抽象场景:Store1; StoreStore; Store2

 

Store1 和 Store2代表两条写入指令。在Store2写入执行前,保证Store1的写入操作对其它处理器可见

 

LoadStore屏障:

 

抽象场景:Load1; LoadStore; Store2

 

在Store2被写入前,保证Load1要读取的数据被读取完毕。

 

StoreLoad屏障:

 

抽象场景:Store1; StoreLoad; Load2

 

在Load2读取操作执行前,保证Store1的写入对所有处理器可见。StoreLoad屏障的开销是四种屏障中最大的。

 

StoreLoad Barriers是一个“全能型”的屏障,它同时具有其他3个屏障的效果。现代的多处理器大多支持该屏障(其他类型的屏障不一定被所有处理器支持)。

 

1.临界区

 

临界区就是锁, 获取锁就是代码进入了临界区,释放锁就是退出了临界区.

 

image.png

 

JMM会在退出临界区和进入临界区这两个关键时间点做一些特别处理,使得多线程在这两个时间点按某种顺序执行。

 

临界区内的代码则可以重排序(但JMM不允许临界区内的代码逃脱出临界区范围,那样会破坏监视器的语义)。

 

虽然线程A在临界区内做了重排序,但由于监视器互斥执行的特性,这里的线程B根本无法“观察”到线程A在临界区内的重排序。这种重排序既提高了执行效率,又没有改变程序的执行结果。

 

回想一下,为啥线程安全的单例模式中一般的双重检查不能保证真正的线程安全?

因为临界区内进行了重排序的操作.



 

 

(一)happens-before

 

在Java 规范提案中为让大家理解内存可见性的这个概念,提出了happens-before的概念来阐述操作之间的内存可见性。对应Java程序员来说,理解happens-before是理解JMM的关键。

 

JMM这么做的原因是:程序员对于这两个操作是否真的被重排序并不关心,程序员关心的是程序执行时的语义不能被改变(即执行结果不能被改变)。因此,happens-before关系本质上和as-if-serial语义是一回事。as-if-serial语义保证单线程内程序的执行结果不被改变,happens-before关系保证正确同步的多线程程序的执行结果不被改变。

定义

 

用happens-before的概念来阐述操作之间的内存可见性。在JMM中,如果一个操作执行的结果需要对另一个操作可见,那么这两个操作之间必须要存在happens-before关系 。

 

两个操作之间具有happens-before关系,并不意味着前一个操作必须要在后一个操作之前执行!happens-before仅仅要求前一个操作(执行的结果)对后一个操作可见,且前一个操作按顺序排在第二个操作之前(the first is visible to and ordered before the second).

 

加深理解

 

上面的定义看起来很矛盾,其实它是站在不同的角度来说的。

1)站在Java程序员的角度来说:JMM保证,如果一个操作happens-before另一个操作,那么第一个操作的执行结果将对第二个操作可见,而且第一个操作的执行顺序排在第二个操作之前。

 

2)站在编译器和处理器的角度来说:JMM允许,两个操作之间存在happens-before关系,不要求Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果,与按happens-before关系来执行的结果一致,那么这种重排序是允许的。

 

回顾我们前面存在数据依赖性的代码:

image.png


站在我们Java程序员的角度:

image.png



但是仔细考察,2、3是必需的,而1并不是必需的,因此JMM对这三个happens-before关系的处理就分为两类:

 

1.会改变程序执行结果的重排序

2.不会改变程序执行结果的重排序

 

JMM对这两种不同性质的重排序,采用了不同的策略,如下:

 

1.对于会改变程序执行结果的重排序,JMM要求编译器和处理器必须禁止这种重排序

2.对于不会改变程序执行结果的重排序,JMM对编译器和处理器不做要求

 

于是,站在我们程序员的角度,看起来这个三个操作满足了happens-before关系,而站在编译器和处理器的角度,进行了重排序,而排序后的执行结果,也是满足happens-before关系的。


image.png


Happens-Before规则

 

JMM为我们提供了以下的Happens-Before规则:

 

1)程序顺序规则:一个线程中的每个操作,happens-before于该线程中的任意后续操作。

 

2)监视器锁规则:对一个锁的解锁,happens-before于随后对这个锁的加锁(进入synchronized后加锁,出去之后释放锁,一定是先加锁再释放锁,顺序必须是这样的)

 

3)volatile变量规则:对一个volatile域的写,happens-before于任意后续对这个volatile域的读。

 

4)传递性:如果A happens-before B,且B happens-before C,那么A一定是 happens-before C。

 

5)start()规则:如果线程A执行操作ThreadB.start()(启动线程B),那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。

 

6)join()规则:如果线程A执行操作ThreadB.join()并成功返回,那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

 

7 )线程中断规则:对线程interrupt方法的调用happens-before于被中断线程的代码检测到中断事件的发生。(只有对调用了线程的interrupt方法,我被中断的线程中才能感知到我对这个线程进行了中断.)