多线程那些事，硬核有趣

这两句话，我相信99%的同学都知道！但是，如果想进企鹅巴巴，如果想应付P20的科学家！我就一定要自行的结合业务回答并发并行的优势！

路人S和路人B果然都露出了满意的笑容。

这回答的累死我了，不过为了能进企鹅巴巴，走向人生巅峰，一切都值了！

是...当我要脱口而出的时候，发现不对，这面试官在套路我！堂堂科学家，套路还没入职的孩子么？

1对1模型：在一对一模型中，1个ULT对应1个KLT。自己不在进程中创建线程表来管理，几行代码之后直接通过系统调用调起KLT就能实现。

多对多模型：在多对多模型中，N个ULT对应小于等于N个的KLT。这种模型结合了1对1和多对1的优点，用户创建线程没有限制，阻塞内核系统的命令不会阻塞整个进程。

最后，就拿最热门的HotSpot VM来说吧，他在Solaris上就有两种线程实现方式，可以让用户选择一对一或多对多这两种模型；而在Windows和Linux下，使用的都是一对一的多线程模型，Java的线程通过一一映射到Light Weight Process（轻量级进程，LWP）从而实现了和KLT的一一对应。

看来同学对于底层的知识理解还凑合，那你有没有看过HotSpot的源码？能不能简单说说看Java的线程是怎么运行的？

源码以前看过，只能记得一个大概。

1、在Java中，使用java.lang.Thread的构造方法来构建一个java.lang.Thread对象，此时只是对这个对象的部分字段(例如线程名，优先级等)进行初始化；

2、调用java.lang.Thread对象的start()方法，开始此线程。此时，在start()方法内部，调用start0() 本地方法来开始此线程；

3、start0()在VM中对应的是JVM_StartThread，也就是，在VM中，实际运行的是JVM_StartThread方法(宏),在这个方法中，创建了一个JavaThread对象；

4、在JavaThread对象的创建过程中，会根据运行平台创建一个对应的OSThread对象，且JavaThread保持这个OSThread对象的引用；

5、在OSThread对象的创建过程中，创建一个平台相关的底层级线程，如果这个底层级线程失败，那么就抛出异常；

6、在正常情况下，这个底层级的线程开始运行，并执行java.lang.Thread对象的run方法；

7、当java.lang.Thread生成的Object的run()方法执行完毕返回后，或者抛出异常终止后，终止native thread;

8、最后就是释放相关的资源(包括内存、锁等)

大概就是以上这么个步骤吧。

那你说说什么是上下文切换吧。

多线程编程中一般线程的个数都大于 CPU 核心的个数，而一个 CPU 核心在任意时刻只能被一个线程使用，为了让这些线程都能得到有效执行，CPU 采取的策略是为每个线程分配时间片并轮转的形式。

时间片是CPU分配给各个线程的时间，因为时间非常短，所以CPU不断通过切换线程，让我们觉得多个线程是同时执行的，时间片一般是几十毫秒。

当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。

概括来说就是：当前任务在执行完 CPU 时间片切换到另一个任务之前会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。任务从保存到再加载的过程就是一次上下文切换。

频繁切换上下文会有什么问题？

上下文切换通常是计算密集型的，每次切换时，需要保存当前的状态起来，以便能够进行恢复先前状态，而这个切换时非常损耗性能。

也就是说，它需要相当可观的处理器时间，在每秒几十上百次的切换中，每次切换都需要纳秒量级的时间。所以，上下文切换对系统来说意味着消耗大量的 CPU 时间，事实上，可能是操作系统中时间消耗最大的操作。

Linux 相比与其他操作系统（包括其他类 Unix 系统）有很多的优点，其中有一项就是，其上下文切换和模式切换的时间消耗非常少。

减少上下文切换的方式有哪些？

通常减少上下文切换的方式有：

1、无锁并发编程：可以参照concurrentHashMap锁分段的思想，不同的线程处理不同段的数据，这样在多线程竞争的条件下，可以减少上下文切换的时间。

2、CAS算法：利用Atomic下使用CAS算法来更新数据，使用了乐观锁，可以有效的减少一部分不必要的锁竞争带来的上下文切换。

3、使用最少线程：避免创建不需要的线程，比如任务很少，但是创建了很多的线程，这样会造成大量的线程都处于等待状态。

4、协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。

协程的英文单词是Coroutine，这是一个程序组件，它既不是线程也不是进程。它的执行过程更类似于一个方法，或者说不带返回值的函数调用。

我看到过stack overflow和很多博客里，都认为这两者是一个东西。但是，在我的理解中，这两者还是有区别的。

不可否认的是，协程和ULT做的是同一个事情。所以从某种角度上讲，他们确实是等价的！

但是，ULT这个概念被提出的时候，其背后的思想本质是讲ULT是个本机线程，也就是使用了OS的用户空间内提供的库类直接创建的线程。这个时候，你不需要在OS上面添加一些其他第三方的库类。

而协程这个概念是康威定律的提出者Melvin Edward Conway在1958年提出的一个概念，其背后的思想是不直接使用OS本身的库类，自己做一些库类去实现并发。在那个年代，OS上面的第三方库类并不像现在这么流行，OS本身的库类和其他第三方库类的结合也并不像今天这么容易。所以协程并不是本机线程，他是需要借助一些其他不属于OS的第三方库类调用OS用户空间的库类来实现达到ULT的效果。

当然，这个概念在今天来看，就会显得很让人混淆了。因为到底哪些库类算是OS本机的库类，哪些算是第三方库类？这和1960年的时候已经有绝大的区别了！所以大家认为这两者是一个东西，其实也不能说他说的不对，只能说可能对这个思想本身背后代表的东西不明白。

那你知道fiber么？这个和上面两个名词有什么区别？

fiber也是一种本机线程，其本质是一种特殊的ULT，即更轻量级的ULT。说白了就是这种ULT的线程表一定存于进程之中。

而我们在构建一对一多线程模型的时候，ULT的线程表其实还是交给内核了！这是两者之间最直接的差别。所以我们经常称fiber就是协同调度的ULT，在win32中可以调用fiber来构建多对多的多线程模型。

其实，fiber、coroutine和ULT在用户层面能看到的效果是基本等价的。

其中ULT是描述OS库本身提供的功能；fiber描述的是OS提供的协同调度的ULT；coroutine描述的是第三方实现的并发并行功能。

这些名词很多都是历史原因的问题，同时也是深入研究需要了解的事情，我们普通程序员在使用的时候，更多的关心的是应用层方面的东西。而这些名词的理解已经深入到源码层了。

还是讲讲看在 Java 程序中怎么保证多线程的运行安全吧。

Java的线程安全在三个方面体现：

原子性：提供互斥访问，同一时刻只能有一个线程对数据进行操作，在Java中使用了atomic和synchronized这两个关键字来确保原子性；

可见性：一个线程对主内存的修改可以及时地被其他线程看到，在Java中使用了synchronized和volatile这两个关键字确保可见性；

有序性：一个线程观察其他线程中的指令执行顺序，由于指令重排序，该观察结果一般杂乱无序，在Java中使用了happens-before原则来确保有序性。

你刚才讲了有序性，那你说说代码为什么会重排序？

在执行程序时，为了提高性能，处理器和编译器常常会对指令进行重排序。

当然不是！不能随意重排序，不是你想怎么排序就怎么排序，它需要满足以下两个条件：

1、在单线程环境下不能改变程序运行的结果；

2、存在数据依赖关系的不允许重排序。

所以重排序不会对单线程有影响，只会破坏多线程的执行语义。

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

这就是as-if-serial语义。

那你说说看你刚才讲的happens-before原则吧。

happens-before说白了就是谁在谁前面发生的一个关系。

HB规则是Java内存模型（JMM）向程序员提供的跨线程内存可见性保证。

说的直白一点，就是如果A线程的写操作a与B线程的读操作b之间存在happens-before关系，尽管a操作和b操作在不同的线程中执行，但JMM向程序员保证a操作将对b操作可见。

具体的定义为：

1、如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。

2、两个操作之间存在happens-before关系，并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果，与按happens-before关系来执行的结果一致，那么这种重排序并不非法。

具体的规则有8条：

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

2、监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。

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、程序中断规则：对线程interrupted()方法的调用先行于被中断线程的代码检测到中断时间的发生。

8、对象finalize规则：一个对象的初始化完成（构造函数执行结束）先行于发生它的finalize()方法的开始。