线程的发展历史 -

aoyouzi

浏览: 1975683 次
性别:
来自: 北京

最近访客更多访客>>

dy.f

zhaoshijie

lbq136957978

juzhibest

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

线程的发展历史

博客分类：

奇文分享
技术总结
JVM

线程的发展历史

了解进程、线程模型

每次学习一个新技术，我会先去了解这个技术的背景，这个过程看似浪费时间，其实在后续的学习过程中，能够促进理解很多问题。所以对于线程这个概念，我会先从操作系统讲起。因为操作系统的发展带来了软件层面的变革。从多线程的发展来看，可以操作系统的发展分为三个历史阶段：

真空管和穿孔卡片
晶体管和批处理系统
集成电路和多道程序设计

最早的计算机只能解决简单的数学运算问题，比如正弦、余弦等。运行方式：程序员首先把程序写到纸上，然后穿孔成卡票，再把卡片盒带入到专门的输入室。输入室会有专门的操作员将卡片的程序输入到计算机上。计算机运行完当前的任务以后，把计算结果从打印机上进行输出，操作员再把打印出来的结果送入到输出室，程序员就可以从输出室取到结果。然后，操作员再继续从已经送入到输入室的卡片盒中读入另一个任务重复上述的步骤。

操作员在机房里面来回调度资源，造成计算机存在大量的空闲状态。而当时的计算机是非常昂贵的，人们为了减少这种资源的浪费。就采用了 批处理系统来解决

批处理操作系统的运行方式：在输入室收集全部的作业，然后用一台比较便宜的计算机把它们读取到磁带上。然后把磁带输入到计算机，计算机通过读取磁带的指令来进行运算，最后把结果输出磁带上。批处理操作系统的好处在于，计算机会一直处于运算状态，合理的利用了计算机资源。（运行流程如下图所示）

（注：此图来源于现代操作系统）

批处理操作系统虽然能够解决计算机的空闲问题，但是当某一个作业因为等待磁盘或者其他I/O操作而暂停，那CPU就只能阻塞直到该I/O完成，对于CPU操作密集型的程序，I/O操作相对较少，因此浪费的时间也很少。但是对于I/O操作较多的场景来说，CPU的资源是属于严重浪费的。

多道程序设计的出现解决了这个问题，就是把内存分为几个部分，每一个部分放不同的程序。当一个程序需要等待I/O操作完成时。那么CPU可以切换执行内存中的另外一个程序。如果内存中可以同时存放足够多的程序，那CPU的利用率可以接近100%。在这个时候，引入了第一个概念- 进程, 进程的本质是一个正在执行的程序，程序运行时系统会创建一个进程，并且给每个进程分配独立的内存地址空间保证每个进程地址不会相互干扰。同时，在CPU对进程做时间片的切换时，保证进程切换过程中仍然要从进程切换之前运行的位置出开始执行。所以进程通常还会包括程序计数器、堆栈指针。

有了进程以后，可以让操作系统从宏观层面实现多应用并发。而并发的实现是通过CPU时间片不端切换执行的。对于单核CPU来说，在任意一个时刻只会有一个进程在被CPU调度

有了进程以后，为什么还会出现线程呢？

在一个应用进程中，会存在多个同时执行的任务，如果其中一个任务被阻塞，将会引起不依赖该任务的任务也被阻塞。举个具体的例子来说，我们平常用word文档编辑内容的时候，都会有一个自动保存的功能，这个功能的作用是，当计算机出现故障的情况下如果用户未保存文档，则能够恢复到上一次自动保存的点。假设word的自动保存因为磁盘问题导致写入较慢，势必会影响到用户的文档编辑功能，直到磁盘写入完成用户才可编辑，这种体验是很差的。如果我们把一个进程中的多个任务通过线程的方式进行隔离，那么按照前面提到的进程演进的理论来说，在单核心CPU架构中可以通过CPU的时间片切换实现线程的调度充分利用CPU资源以达到最大的性能。

我们用了比较长的篇幅介绍了进程、线程发展的历史。总的来说是人们对于计算机的要求越来越高；对于计算机本身的资源的利用率也在不断提高。

线程的优势

前面分析了线程的发展历史，这里简单总结一下线程有的优势如下

线程可以认为是轻量级的进程，所以线程的创建、销毁要比进程更快
从性能上考虑，如果进程中存在大量的I/O处理，通过多线程能够加快应用程序的执行速度(通过CPU时间片的快速切换)。
由于线程是CPU的最小调度单元，所以在多CPU架构中能够实现真正的并行执行。每一个CPU可以调度一个线程

这里有两个概念很多人没有搞明白，就是并行和并发

并行：同时执行多个任务，在多核心CPU架构中，一个CPU核心运行一个线程，那么4核心CPU，可以同时执行4个线程

并发：同处理多个任务的能力,通常我们会通过TPS或者QPS来表示某某系统支持的并发数是多少。

总的来说，并行是并发的子集。也就是说我们可以写一个拥有多线程并行的程序，如果在没有多核心CPU来执行这些线程，那就不能以并行的方式来运行程序中的多个线程。所以并发程序可以是并行的，也可以不是。Erlang之父Joe Armstrong通过一张图型的方式来解释并发和并行的区别，图片如下

线程的生命周期

线程是存在生命周期的，从线程的创建到销毁，可能会经历6种不同的状态，但是在一个时刻线程只能处于其中一种状态

NEW：初始状态，线程被创建时候的状态，还没有调用start方法
RUNNABLE：运行状态，运行状态包含就绪和运行两种状态，因为线程启动以后，并不是立即执行，而是需要通过调度去分配CPU时间片
BLOCKED：阻塞状态，当线程去访问一个加锁的方法时，如果已经有其他线程获得锁，那么当前线程会处于阻塞状态
WAITING：等待状态，设置线程进入等待状态等待其他线程做一些特定的动作进行触发
TIME_WAITING：超时等待状态，和WAITING状态的区别在于超时以后自动返回
TERMINATED：终止状态，线程执行完毕

下图整理了线程的状态变更过程及变更的操作，每一个具体的操作原理，我会在后续的文章中进行详细分析。

这里有一个问题大家可能搞不明白，BLOCKED和WAITING这两个阻塞有什么区别？

BLOCKED状态是指当前线程在等待一个获取锁的操作时的状态。
WAITING是通过Object.wait或者Thread.join、LockSupport.park等操作实现的
BLOCKED是被动的标记，而WAITING是主动操作
如果说得再深入一点，处于WAITING状态的线程，被唤醒以后，需要进入同步队列去竞争锁操作，而在同步队列中，如果已经有其他线程持有锁，则线程会处于BLOCKED状态。所以可以说BLOCKED状态是处于WAITING状态的线程重新唤醒的必经的状态

线程的应用场景

线程的出现，在多核心CPU架构下实现了真正意义上的并行执行。也就是说，一个进程内多个任务可以通过多线程并行执行来提高程序运行的性能。那线程的使用场景有哪些呢？

执行后台任务，在很多场景中，可能会有一些定时的批量任务，比如定时发送短信、定时生成批量文件。在这些场景中可以通过多线程的来执行
异步处理，比如在用户注册成功以后给用户发送优惠券或者短信，可以通过异步的方式来执行，一方面提升主程序的执行性能；另一方面可以解耦核心功能，防止非核心功能对核心功能造成影响
分布式处理，比如fork/join，将一个任务拆分成多个子任务分别执行
BIO模型中的线程任务分发，也是一种比较常见的使用场景，一个请求对应一个线程

合理的利用多线程，可以提升程序的吞吐量。同时，还可以通过增加CPU的核心数来提升程序的性能，这就体现了伸缩性的特点

并发编程的挑战

引入多线程的目的在第一篇提到过，就是为了充分利用CPU是的程序运行得更快，当然并不是说启动的线程越多越好。在实际使用多线程的时候，会面临非常多的挑战

线程安全问题

线程安全问题值的是当多个线程访问同一个对象时，如果不考虑这些运行时环境采用的调度方式或者这些线程将如何交替执行，并且在代码中不需要任何同步操作的情况下，这个类都能够表现出正确的行为，那么这个类就是线程安全的比如下面的代码是一个单例模式，在代码的注释出，如果多个线程并发访问，则会出现多个实例。导致无法实现单例的效果

publicclassSingletonDemo{
privatestaticSingletonDemo singletonDemo=null;
privateSingletonDemo(){}
publicstaticSingletonDemo getInstance(){
if(singletonDemo==null){/***线程安全问题***/
singletonDemo=newSingletonDemo();
}
return singletonDemo;
}
}

通常来说，我们把多线程编程中的线程安全问题归类成如下三个，至于每一个问题的本质，在后续的文章中我们会单独讲解

原子性
可见性
有序性

上下文切换问题

在单核心CPU架构中，对于多线程的运行是基于CPU时间片切换来实现的伪并行。由于时间片非常短导致用户以为是多个线程并行执行。而一次上下文切换，实际就是当前线程执行一个时间片之后切换到另外一个线程，并且保存当前线程执行的状态这个过程。上下文切换会影响到线程的执行速度，对于系统来说意味着会消耗大量的CPU时间。

减少上下文切换的方式

无锁并发编程，在多线程竞争锁时，会导致大量的上下文切换。避免使用锁去解决并发问题可以减少上下文切换
CAS算法，CAS是一种乐观锁机制，不需要加锁
使用与硬件资源匹配合适的线程数

死锁

在解决线程安全问题的场景中，我们会比较多的考虑使用锁，因为它使用比较简单。但是锁的使用如果不恰当，则会引发死锁的可能性，一旦产生死锁，就会造成比较严重的问题：产生死锁的线程会一直占用锁资源，导致其他尝试获取锁的线程也发生死锁，造成系统崩溃以下是死锁的简单案例

publicclassDeadLockDemo{
//定义锁对象
privatefinalObject lockA =newObject();
privatefinalObject lockB =newObject();
privatevoid deadLock(){
newThread(()->{
synchronized(lockA){
try{
Thread.sleep(4000);
}catch(InterruptedException e){
e.printStackTrace();
}
synchronized(lockB){
System.out.println("Lock B");
}
}
}).start();
newThread(()->{
synchronized(lockB){
synchronized(lockA){
System.out.println("Lock A");
}
}
}).start();
}
publicstaticvoid main(String[] args){
newDeadLockDemo().deadLock();
}
}

通过jstack分析死锁

1. 首先通过jps获取当前运行的进程的pid

16628Jps
17588RemoteMavenServer
19220Launcher
19004DeadLockDemo

2. jstack打印堆栈信息,输入 jstack19004, 会打印如下日志，可以很明显看到死锁的信息提示

Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x000000001d461e68(object0x000000076b310df8, a java.lang.Object),
which is held by"Thread-0"
"Thread-0":
waiting to lock monitor 0x000000001d463258(object0x000000076b310e08, a java.lang.Object),
which is held by"Thread-1"

解决死锁的手段

保证多个线程按照相同的顺序获取锁

设置获取锁的超时时间，超过设定时间以后自动释放

死锁检测

资源限制

资源限制主要指的是硬件资源和软件资源，在开发多线程应用时，程序的执行速度受限于这两个资源。硬件的资源限制无非就是磁盘、CPU、内存、网络；软件资源的限制有很多，比如数据库连接数、计算机能够支持的最大连接数等资源限制导致的问题最直观的体现就是前面说的上下文切换，也就是CPU资源和线程资源的严重不均衡导致频繁上下文切换，反而会造成程序的运行速度下降

资源限制的主要解决方案，就是缺啥补啥。CPU不够用，可以增加CPU核心数；一台机器的资源有限，则增加多台机器来做集群。

线程在Java中的使用

在Java中实现多线程的方式比较简单，因为Java中提供了非常方便的API来实现多线程。

继承Thread类实现多线程
实现Runnable接口
实现Callable接口通过Future包装器来创建Thread线程，这种是带返回值的线程
使用线程池ExecutorService

继承Thread类

继承Thread类，然后重写run方法，在run方法中编写当前线程需要执行的逻辑。最后通过线程实例的start方法来启动一个线程

publicclassThreadDemoextendsThread{
@Override
publicvoid run(){
//重写run方法，提供当前线程执行的逻辑
System.out.println("Hello world");
}
publicstaticvoid main(String[] args){
ThreadDemo threadDemo=newThreadDemo();
threadDemo.start();
}
}

Thread类其实是实现了Runnable接口，因此Thread自己也是一个线程实例，但是我们不能直接用 newThread().start()去启动一个线程，原因很简单，Thread类中的run方法是没有实际意义的，只是一个调用通过构造函数传递寄来的另一个Runnable实现类的run方法，这块的具体演示会在Runnable接口的代码中看到

public
classThreadimplementsRunnable{
/* What will be run. */
privateRunnable target;
...
@Override
publicvoid run(){
if(target !=null){
target.run();
}
}
...

实现Runnable接口

如果需要使用线程的类已经继承了其他的类，那么按照Java的单一继承原则，无法再继承Thread类来实现线程，所以可以通过实现Runnable接口来实现多线程

publicclassRunnableDemoimplementsRunnable{
@Override
publicvoid run(){
//重写run方法，提供当前线程执行的逻辑
System.out.println("Hello world");
}
publicstaticvoid main(String[] args){
RunnableDemo runnableDemo=newRunnableDemo();
newThread(runnableDemo).start();
}
}

上面的代码中，实现了Runnable接口，重写了run方法；接着为了能够启动RunnableDemo这个线程，必须要实例化一个Thread类，通过构造方法传递一个Runnable接口实现类去启动，Thread的run方法就会调用target.run来运行当前线程,代码在上面.

实现Callable接口

在有些多线程使用的场景中，我们有时候需要获取异步线程执行完毕以后的反馈结果，也许是主线程需要拿到子线程的执行结果来处理其他业务逻辑，也许是需要知道线程执行的状态。那么Callable接口可以很好的实现这个功能

publicclassCallableDemoimplementsCallable<String>{
@Override
publicString call()throwsException{
return"hello world";
}
publicstaticvoid main(String[] args)throwsExecutionException,InterruptedException{
Callable<String> callable=newCallableDemo();
FutureTask<String> task=newFutureTask<>(callable);
newThread(task).start();
System.out.println(task.get());//获取线程的返回值
}
}

在上面代码案例中的最后一行 task.get()就是获取线程的返回值，这个过程是阻塞的，当子线程还没有执行完的时候，主线程会一直阻塞直到结果返回

使用线程池

为了减少频繁创建线程和销毁线程带来的性能开销，在实际使用的时候我们会采用线程池来创建线程，在这里我不打算展开多线程的好处和原理，我会在后续的文章中单独说明。

publicclassExecutorServiceDemo{
publicstaticvoid main(String[] args)throwsExecutionException,InterruptedException{
//创建一个固定线程数的线程池
ExecutorService pool =Executors.newFixedThreadPool(1);
Future future=pool.submit(newCallableDemo());
System.out.println(future.get());
}
}

pool.submit有几个重载方法，可以传递带返回值的线程实例，也可以传递不带返回值的线程实例，源代码如下

/*01*/Future<?> submit(Runnable task);
/*02*/<T>Future<T> submit(Runnable task, T result);
/*03*/<T>Future<T> submit(Callable<T> task);

线程的启动原理

前面我们简单分析过了线程的使用，通过调用线程的start方法来启动线程，线程启动后会调用run方法执行业务逻辑，run方法执行完毕后，线程的生命周期也就终止了。很多同学最早学习线程的时候会比较疑惑，启动一个线程为什么是调用start方法，而不是run方法，这做一个简单的分析，先简单看一下start方法的定义

publicclassThreadimplementsRunnable{
...
publicsynchronizedvoid start(){
/**
* This method is not invoked for the main method thread or "system"
* group threads created/set up by the VM. Any new functionality added
* to this method in the future may have to also be added to the VM.
*
* A zero status value corresponds to state "NEW".
*/
if(threadStatus !=0)
thrownewIllegalThreadStateException();
/* Notify the group that this thread is about to be started
* so that it can be added to the group's list of threads
* and the group's unstarted count can be decremented. */
group.add(this);
boolean started =false;
try{
start0();//注意这里
started =true;
}finally{
try{
if(!started){
group.threadStartFailed(this);
}
}catch(Throwable ignore){
/* do nothing. If start0 threw a Throwable then
it will be passed up the call stack */
}
}
}
privatenativevoid start0();//注意这里
...

我们看到调用start方法实际上是调用一个native方法start0()来启动一个线程，首先start0()这个方法是在Thread的静态块中来注册的，代码如下

publicclassThreadimplementsRunnable{
/* Make sure registerNatives is the first thing <clinit> does. */
privatestaticnativevoid registerNatives();
static{
registerNatives();
}

这个registerNatives的作用是注册一些本地方法提供给Thread类来使用，比如start0()、isAlive()、currentThread()、sleep()；这些都是大家很熟悉的方法。 registerNatives的本地方法的定义在文件 Thread.cThread.c定义了各个操作系统平台要用的关于线程的公共数据和操作，以下是Thread.c的全部内容

staticJNINativeMethod methods[]={
{"start0", "()V", (void*)&JVM_StartThread},
{"stop0", "(" OBJ ")V",(void*)&JVM_StopThread},
{"isAlive", "()Z", (void*)&JVM_IsThreadAlive},
{"suspend0", "()V", (void*)&JVM_SuspendThread},
{"resume0", "()V", (void*)&JVM_ResumeThread},
{"setPriority0", "(I)V", (void*)&JVM_SetThreadPriority},
{"yield", "()V", (void*)&JVM_Yield},
{"sleep", "(J)V", (void*)&JVM_Sleep},
{"currentThread", "()" THD, (void*)&JVM_CurrentThread},
{"countStackFrames","()I", (void*)&JVM_CountStackFrames},
{"interrupt0", "()V", (void*)&JVM_Interrupt},
{"isInterrupted", "(Z)Z", (void*)&JVM_IsInterrupted},
{"holdsLock", "(" OBJ ")Z",(void*)&JVM_HoldsLock},
{"getThreads", "()[" THD, (void*)&JVM_GetAllThreads},
{"dumpThreads", "([" THD ")[[" STE,(void*)&JVM_DumpThreads},
{"setNativeName", "(" STR ")V",(void*)&JVM_SetNativeThreadName},
};
#undef THD
#undef OBJ
#undef STE
#undef STR
JNIEXPORT void JNICALL
Java_java_lang_Thread_registerNatives(JNIEnv*env, jclass cls)
{
(*env)->RegisterNatives(env, cls, methods, ARRAY_LENGTH(methods));
}

从这段代码可以看出，start0()，实际会执行 JVM_StartThread方法，这个方法是干嘛的呢？从名字上来看，似乎是在JVM层面去启动一个线程，如果真的是这样，那么在JVM层面，一定会调用Java中定义的run方法。那接下来继续去找找答案。我们找到 jvm.cpp这个文件；这个文件需要下载hotspot的源码才能找到.

JVM_ENTRY(void, JVM_StartThread(JNIEnv* env, jobject jthread))
JVMWrapper("JVM_StartThread");
...
native_thread =newJavaThread(&thread_entry, sz);
...

JVM_ENTRY是用来定义 JVM_StartThread函数的，在这个函数里面创建了一个真正和平台有关的本地线程. 本着打破砂锅查到底的原则，继续看看 newJavaThread做了什么事情,继续寻找JavaThread的定义在hotspot的源码中 thread.cpp文件中1558行的位置可以找到如下代码

JavaThread::JavaThread(ThreadFunction entry_point,size_t stack_sz):
Thread()
#if INCLUDE_ALL_GCS
, _satb_mark_queue(&_satb_mark_queue_set),
_dirty_card_queue(&_dirty_card_queue_set)
#endif// INCLUDE_ALL_GCS
{
if(TraceThreadEvents){
tty->print_cr("creating thread %p",this);
}
initialize();
_jni_attach_state = _not_attaching_via_jni;
set_entry_point(entry_point);
// Create the native thread itself.
// %note runtime_23
os::ThreadType thr_type = os::java_thread;
thr_type = entry_point ==&compiler_thread_entry ? os::compiler_thread :
os::java_thread;
os::create_thread(this, thr_type, stack_sz);
_safepoint_visible =false;
// The _osthread may be NULL here because we ran out of memory (too many threads active).
// We need to throw and OutOfMemoryError - however we cannot do this here because the caller
// may hold a lock and all locks must be unlocked before throwing the exception (throwing
// the exception consists of creating the exception object & initializing it, initialization
// will leave the VM via a JavaCall and then all locks must be unlocked).
//
// The thread is still suspended when we reach here. Thread must be explicit started
// by creator! Furthermore, the thread must also explicitly be added to the Threads list
// by calling Threads:add. The reason why this is not done here, is because the thread
// object must be fully initialized (take a look at JVM_Start)
}

这个方法有两个参数，第一个是函数名称，线程创建成功之后会根据这个函数名称调用对应的函数；第二个是当前进程内已经有的线程数量。最后我们重点关注与一下 os::create_thread,实际就是调用平台创建线程的方法来创建线程。接下来就是线程的启动，会调用Thread.cpp文件中的Thread::start(Thread* thread)方法，代码如下

voidThread::start(Thread* thread){
trace("start", thread);
// Start is different from resume in that its safety is guaranteed by context or
// being called from a Java method synchronized on the Thread object.
if(!DisableStartThread){
if(thread->is_Java_thread()){
// Initialize the thread state to RUNNABLE before starting this thread.
// Can not set it after the thread started because we do not know the
// exact thread state at that time. It could be in MONITOR_WAIT or
// in SLEEPING or some other state.
java_lang_Thread::set_thread_status(((JavaThread*)thread)->threadObj(),
java_lang_Thread::RUNNABLE);
}
os::start_thread(thread);
}
}

start方法中有一个函数调用： os::start_thread(thread);，调用平台启动线程的方法，最终会调用Thread.cpp文件中的JavaThread::run()方法

// The first routine called by a new Java thread
voidJavaThread::run(){
// initialize thread-local alloc buffer related fields
this->initialize_tlab();
// used to test validitity of stack trace backs
this->record_base_of_stack_pointer();
// Record real stack base and size.
this->record_stack_base_and_size();
// Initialize thread local storage; set before calling MutexLocker
this->initialize_thread_local_storage();
this->create_stack_guard_pages();
this->cache_global_variables();
// Thread is now sufficient initialized to be handled by the safepoint code as being
// in the VM. Change thread state from _thread_new to _thread_in_vm
ThreadStateTransition::transition_and_fence(this, _thread_new, _thread_in_vm);
assert(JavaThread::current()==this,"sanity check");
assert(!Thread::current()->owns_locks(),"sanity check");
DTRACE_THREAD_PROBE(start,this);
// This operation might block. We call that after all safepoint checks for a new thread has
// been completed.
this->set_active_handles(JNIHandleBlock::allocate_block());
if(JvmtiExport::should_post_thread_life()){
JvmtiExport::post_thread_start(this);
}
EventThreadStartevent;
if(event.should_commit()){
event.set_javalangthread(java_lang_Thread::thread_id(this->threadObj()));
event.commit();
}
// We call another function to do the rest so we are sure that the stack addresses used
// from there will be lower than the stack base just computed
thread_main_inner();
// Note, thread is no longer valid at this point!
}

这个方法中主要是做一系列的初始化操作，最后有一个方法 thread_main_inner, 接下来看看这个方法的逻辑是什么样的

voidJavaThread::thread_main_inner(){
assert(JavaThread::current()==this,"sanity check");
assert(this->threadObj()!= NULL,"just checking");
// Execute thread entry point unless this thread has a pending exception
// or has been stopped before starting.
// Note: Due to JVM_StopThread we can have pending exceptions already!
if(!this->has_pending_exception()&&
!java_lang_Thread::is_stillborn(this->threadObj())){
{
ResourceMark rm(this);
this->set_native_thread_name(this->get_thread_name());
}
HandleMark hm(this);
this->entry_point()(this,this);
}
DTRACE_THREAD_PROBE(stop,this);
this->exit(false);
deletethis;
}

和主流程无关的代码咱们先不去看，直接找到最核心的代码块 this->entry_point()(this,this);, 这个entrypoint应该比较熟悉了，因为我们在前面提到了，在::JavaThread这个方法中传递的第一个参数，代表函数名称，线程启动的时候会调用这个函数。如果大家还没有晕车的话，应该记得我们在jvm.cpp文件中看到的代码，在创建 native_thread=newJavaThread(&thread_entry,sz); 的时候传递了一个threadentry函数，所以我们在jvm.cpp中找到这个函数的定义如下

staticvoid thread_entry(JavaThread* thread, TRAPS){
HandleMark hm(THREAD);
Handle obj(THREAD, thread->threadObj());
JavaValue result(T_VOID);
JavaCalls::call_virtual(&result,
obj,
KlassHandle(THREAD,SystemDictionary::Thread_klass()),
vmSymbols::run_method_name(),//注意这里
vmSymbols::void_method_signature(),
THREAD);
}

可以看到 vmSymbols::run_method_name()这个调用，其实就是通过回调方法调用Java线程中定义的run方法， run_method_name是一个宏定义，在vmSymbols.hpp文件中可以找到如下代码

#define VM_SYMBOLS_DO(template, do_alias)
...
template(run_method_name,"run")
...

所以结论就是，Java里面创建线程之后必须要调用start方法才能真正的创建一个线程，该方法会调用虚拟机启动一个本地线程，本地线程的创建会调用当前系统创建线程的方法进行创建，并且线程被执行的时候会回调 run方法进行业务逻辑的处理

线程的终止方法及原理

线程的终止有主动和被动之分，被动表示线程出现异常退出或者run方法执行完毕，线程会自动终止。主动的方式是 Thread.stop()来实现线程的终止，但是stop()方法是一个过期的方法，官方是不建议使用，理由很简单，stop()方法在中介一个线程时不会保证线程的资源正常释放，也就是不会给线程完成资源释放工作的机会，相当于我们在linux上通过kill -9强制结束一个进程。

那么如何安全的终止一个线程呢?

我们先看一下下面的代码，代码演示了一个正确终止线程的方法，至于它的实现原理，稍后我们再分析

publicclassInterruptedDemoimplementsRunnable{
@Override
publicvoid run(){
long i=0l;
while(!Thread.currentThread().isInterrupted()){//notice here
i++;
}
System.out.println("result:"+i);
}
publicstaticvoid main(String[] args)throwsInterruptedException{
InterruptedDemo interruptedDemo=newInterruptedDemo();
Thread thread=newThread(interruptedDemo);
thread.start();
Thread.sleep(1000);//睡眠一秒
thread.interrupt();//notice here
}
}

代码中有两处需要注意，在main线程中，调用了线程的interrupt()方法、在run方法中，while循环中通过 Thread.currentThread().isInterrupted()来判断线程中断的标识。所以我们在这里猜想一下，应该是在线程中维护了一个中断标识，通过 thread.interrupt()方法去改变了中断标识的值使得run方法中while循环的判断不成立而跳出循环，因此run方法执行完毕以后线程就终止了。

线程中断的原理分析

我们来看一下 thread.interrupt()方法做了什么事情

publicclassThreadimplementsRunnable{
...
publicvoid interrupt(){
if(this!=Thread.currentThread())
checkAccess();
synchronized(blockerLock){
Interruptible b = blocker;
if(b !=null){
interrupt0(); // Just to set the interrupt flag
b.interrupt(this);
return;
}
}
interrupt0();
}
...

这个方法里面，调用了interrupt0()，这个方法在前面分析start方法的时候见过，是一个native方法，这里就不再重复贴代码了，同样，我们找到jvm.cpp文件，找到JVM_Interrupt的定义

JVM_ENTRY(void, JVM_Interrupt(JNIEnv* env, jobject jthread))
JVMWrapper("JVM_Interrupt");
// Ensure that the C++ Thread and OSThread structures aren't freed before we operate
oop java_thread =JNIHandles::resolve_non_null(jthread);
MutexLockerEx ml(thread->threadObj()== java_thread ? NULL :Threads_lock);
// We need to re-resolve the java_thread, since a GC might have happened during the
// acquire of the lock
JavaThread* thr = java_lang_Thread::thread(JNIHandles::resolve_non_null(jthread));
if(thr != NULL){
Thread::interrupt(thr);
}
JVM_END

这个方法比较简单，直接调用了 Thread::interrupt(thr)这个方法，这个方法的定义在Thread.cpp文件中，代码如下

voidThread::interrupt(Thread* thread){
trace("interrupt", thread);
debug_only(check_for_dangling_thread_pointer(thread);)
os::interrupt(thread);
}

Thread::interrupt方法调用了os::interrupt方法，这个是调用平台的interrupt方法，这个方法的实现是在 os_*.cpp文件中，其中星号代表的是不同平台，因为jvm是跨平台的，所以对于不同的操作平台，线程的调度方式都是不一样的。我们以os_linux.cpp文件为例

void os::interrupt(Thread* thread){
assert(Thread::current()== thread ||Threads_lock->owned_by_self(),
"possibility of dangling Thread pointer");
//获取本地线程对象
OSThread* osthread = thread->osthread();
if(!osthread->interrupted()){//判断本地线程对象是否为中断
osthread->set_interrupted(true);//设置中断状态为true
// More than one thread can get here with the same value of osthread,
// resulting in multiple notifications. We do, however, want the store
// to interrupted() to be visible to other threads before we execute unpark().
//这里是内存屏障，这块在后续的文章中会剖析；内存屏障的目的是使得interrupted状态对其他线程立即可见
OrderAccess::fence();
//_SleepEvent相当于Thread.sleep，表示如果线程调用了sleep方法，则通过unpark唤醒
ParkEvent*const slp = thread->_SleepEvent;
if(slp != NULL) slp->unpark();
}
// For JSR166. Unpark even if interrupt status already was set
if(thread->is_Java_thread())
((JavaThread*)thread)->parker()->unpark();
//_ParkEvent用于synchronized同步块和Object.wait()，这里相当于也是通过unpark进行唤醒
ParkEvent* ev = thread->_ParkEvent;
if(ev != NULL) ev->unpark();
}

通过上面的代码分析可以知道，thread.interrupt()方法实际就是设置一个interrupted状态标识为true、并且通过ParkEvent的unpark方法来唤醒线程。

对于synchronized阻塞的线程，被唤醒以后会继续尝试获取锁，如果失败仍然可能被park
在调用ParkEvent的park方法之前，会先判断线程的中断状态，如果为true，会清除当前线程的中断标识
Object.wait、Thread.sleep、Thread.join会抛出InterruptedException

这里给大家普及一个知识点，为什么Object.wait、Thread.sleep和Thread.join都会抛出InterruptedException?首先，这个异常的意思是表示一个阻塞被其他线程中断了。然后，由于线程调用了interrupt()中断方法，那么Object.wait、Thread.sleep等被阻塞的线程被唤醒以后会通过is_interrupted方法判断中断标识的状态变化，如果发现中断标识为true，则先清除中断标识，然后抛出InterruptedException

需要注意的是，InterruptedException异常的抛出并不意味着线程必须终止，而是提醒当前线程有中断的操作发生，至于接下来怎么处理取决于线程本身，比如

直接捕获异常不做任何处理
将异常往外抛出
停止当前线程，并打印异常信息

为了让大家能够更好的理解上面这段话，我们以Thread.sleep为例直接从jdk的源码中找到中断标识的清除以及异常抛出的方法代码

找到 is_interrupted()方法，linux平台中的实现在os_linux.cpp文件中，代码如下

bool os::is_interrupted(Thread* thread,bool clear_interrupted){
assert(Thread::current()== thread ||Threads_lock->owned_by_self(),
"possibility of dangling Thread pointer");
OSThread* osthread = thread->osthread();
bool interrupted = osthread->interrupted();//获取线程的中断标识
if(interrupted && clear_interrupted){//如果中断标识为true
osthread->set_interrupted(false);//设置中断标识为false
// consider thread->_SleepEvent->reset() ... optional optimization
}
return interrupted;
}

找到Thread.sleep这个操作在jdk中的源码体现，怎么找?相信如果前面大家有认真看的话，应该能很快找到，代码在jvm.cpp文件中

JVM_ENTRY(void, JVM_Sleep(JNIEnv* env, jclass threadClass, jlong millis))
JVMWrapper("JVM_Sleep");
if(millis <0){
THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(),"timeout value is negative");
}
//判断并清除线程中断状态，如果中断状态为true,抛出中断异常
if(Thread::is_interrupted (THREAD,true)&&!HAS_PENDING_EXCEPTION){
THROW_MSG(vmSymbols::java_lang_InterruptedException(),"sleep interrupted");
}
// Save current thread state and restore it at the end of this block.
// And set new thread state to SLEEPING.
JavaThreadSleepState jtss(thread);
...

注意上面加了中文注释的地方的代码，先判断is_interrupted的状态，然后抛出一个InterruptedException异常。到此为止，我们就已经分析清楚了中断的整个流程。

Java线程的中断标识判断

了解了thread.interrupt方法的作用以后，再回过头来看Java中 Thread.currentThread().isInterrupted()这段代码，就很好理解了。由于前者先设置了一个中断标识为true，所以 isInterrupted()这个方法的返回值为true，故而不满足while循环的判断条件导致退出循环。这里有必要再提一句，就是这个线程中断标识有两种方式复位，第一种是前面提到过的InterruptedException；另一种是通过Thread.interrupted()对当前线程的中断标识进行复位。

from

https://mp.weixin.qq.com/s?__biz=MzUxNDA1NDI3OA==&mid=2247484980&idx=1&sn=1c5fba57f79a696bd467e5d5d3aa12e7&chksm=f94a87ddce3d0ecb4e58066607d64ab7f3be36db398a79b3828449a4cc0185384815cfa4274d&mpshare=1&scene=1&srcid=1204qe1gtGwG3PRoAqMFBcfn#rd

https://mp.weixin.qq.com/s?__biz=MzUxNDA1NDI3OA==&mid=2247484980&idx=2&sn=f53f02c719130ceb2ea776f28356f9d3&chksm=f94a87ddce3d0ecbd4e3155e4430a1d972017ff06c480eb30da21b02d3b753ce09c48df34ba2&mpshare=1&scene=1&srcid=1205rkjB8HNDe9by1EGZm8ee#rd

https://mp.weixin.qq.com/s?__biz=MzUxNDA1NDI3OA==&mid=2247484980&idx=3&sn=2826ad9b3481ae18ee311cbcee195ca7&chksm=f94a87ddce3d0ecb988997d6ea64722fe386e749077bdd0712833c899514cbc81a0b63240a5f&mpshare=1&scene=1&srcid=1205KnclzuczOcT03pAYcq0G#rd

分享到：

为什么阿里巴巴禁止工程师直接使用日志系统 ... | 分布式事务原理及解决方案

2018-12-05 11:07
浏览 1247
评论(0)
分类:编程语言
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

线程的发展历史

线程安全问题

上下文切换问题

通过jstack分析死锁

资源限制

继承Thread类

实现Runnable接口

实现Callable接口

线程中断的原理分析

Java线程的中断标识判断

评论

发表评论

相关推荐

最近访客 更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论

线程的发展历史

线程安全问题

上下文切换问题

通过jstack分析死锁

资源限制

继承Thread类

实现Runnable接口

实现Callable接口

线程中断的原理分析

Java线程的中断标识判断

评论

发表评论

相关推荐

诸神之黄昏：2021年以后的互联网及新兴行业

万字总结Java 9~15新特性

从 Web 图标演进历史看最佳实践

架构制图：工具与方法论

性能优化

【冬察冬见】FFmpeg系列学习笔记

有关创新的一些思考

浅谈面试官的培养

冬察冬见·全视角再议晋升

冬察冬见·晋升-晋升的那些事儿1

物联网MQTT实战

大小公司都适用的架构选型工具箱（涵盖上百个组件）

读书与成长

2020年教育行业OMO模式转型现状研究报告

百度的71个非常厉害的开源项目

最好的励志书

心智成长

研发路上的一些总结与思考

MQTT协议为什么这么轻量级

高效沟通

最近访客更多访客>>