并发编程笔记，带你降服面试官

/   今日科技快讯   /

近日，特斯拉CEO埃隆·马斯克在Twitter上表示，旗下太空探索技术公司SpaceX正在改建的两座海上发射平台“Phobos”（火卫一）和“Deimos”（火卫二），其中一座有可能会在今年年底前有限运营。

/   作者简介   /

本篇文章来自Mikael Zero同学投稿，分享了他对并发开发的相关知识的整理，相信会对大家有所帮助！同时也感谢作者贡献的精彩文章！

Mikael Zero的博客地址：

https://www.yuque.com/mikaelzero

/   开始   /

进程和线程有什么区别？

进程是系统资源分配、调度和管理的最小单位。

线程是CPU运算的最小执行单位。

比如我们使用任务管理器查看的时候显示出来的都是属于进程，一个进程会独立开辟一块独立的地址空间，进程中的所有线程都会共享这部分的内存。

对于线程，CPU运算的时候不会在意这个线程是属于哪一个进程，只要你是一个线程就可以，CPU会对不同的线程进行一个轮换运行

单核中执行三个线程，一种是穿插执行，一种是顺序执行，哪一种最快？

答案是不一定的。

以这三个线程的逻辑都是计算工作，我按顺序执行3个线程，和我每个线程执行一部分切换着来，时间应该是一样的。但是由于在切换线程的时候会涉及到上下文的切换，这部分是耗时的，所以会比按顺序处理慢。

那为什么还需要多线程？

这就涉及到另外一种情况，那就是阻塞或者IO操作(网络或者读取文件)，IO是非常耗时间的。如果自己来设计一个CPU读取硬盘数据的架构流程，你是否会先想到这样一种方案

这有什么问题呢？

由于CPU处理速度实在是太快了，如果我把CPU的资源全给去读一个文件，硬盘的读取速度和CPU无法相提并论，就太浪费CPU资源了。

因此，真实的设计是这样子的：

从上图可以看出，当cpu下达完指令后，CPU就空闲了出来，可以去执行其他的工作。再结合上面的三个线程的例子，可以画出这样的流程：

大致逻辑为，线程1处理完逻辑后，发现要去读取文件，于是交给DMA去处理，等DMA处理完告诉我就行，这个时候CPU就空闲了出来，可以去处理线程2或者3，如果线程2和3都是读取文件，那CPU空闲出来的时间就更多了，可以去处理更多的事情。

多线程一定是处理IO的最优解吗？

由于线程的创建和切换，需要下沉到内核态，调用底层的API才能完成，用户态与内核态的不断转换是耗时的

协程，是一种用户态的线程，每个协程都有自己的一个执行栈，切换都是在用户态进行处理。

协程出来较早，但并不出名，直到高并发问题越来越严重，用户态和内核态都吃不消大量的线程，内存告急，协程最出名的还属和IO多路复用结合，是一个高并发的解决方案。

与其让操作系统调度，不如我自己来，这就是协程。

PS:Android中kotlin的协程，严格意义上说，并不属于协程，只能说是一个JAVA中多线程的API封装，并且让开发者更方便地去处理多线程以及线程的切换。

一个线程的生命周期是怎样的？

如何保证线程的处理是安全的？

使用锁以及原子性、可见性、有序性

可见性

一个线程对共享变量值得修改，能够及时地被其他线程看到

可见性的两种方式，syschronized和volatile

在JAVA内存模型中有对 syschronized 的两条规定：

1. 线程解锁前，必须把共享变量的最新值更新到主内存中

2. 线程加锁时，将清空工作内存中的共享变量的值，从而在使用共享变量时就必须要从主内存重新读取最新的值

因此，这样就可以保证了可见性

原子性

即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。比如 num++，它在程序执行的时候是分成三步：

1. 读取num的值

2. 将num的值 +1

3. 写入最新的num值

所以使用 volatile 只能保证变量在读或者写的当前阶段，保证可见性，假设一个线程执行到上述的1操作，第二个线程执行到2操作，那么就会造成结果不正确。

volatile的使用场合

1. 对变量的写入操作不依赖其当前值，比如 num++，num=num+1 等

2. 该变量没有包含在具体的其他变量中的不变式中，比如有两个被volatile修饰的变量，A和B，那么  A<B 这样的操作，就不能使用 volatile

因此 volatile的使用场合和 syschronized相较而言会比较少，但是 volatile不需要加锁，更轻量级，也不会阻塞线程

JAVA中的锁有哪些处理方式？

Java中的锁机制主要分为Lock和Synchronized锁的类型可看如下，一张来自美团技术团队的图。

悲观锁和乐观锁的区别什么

乐观锁与悲观锁是一种广义上的概念，体现了看待线程同步的不同角度。

悲观锁认为自己在使用数据的时候一定有别的线程来修改数据，因此在获取数据的时候会先加锁，确保数据不会被别的线程修改。Java中，synchronized关键字和Lock的实现类都是悲观锁。

而乐观锁认为自己在使用数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作（例如报错或者自动重试）。

乐观锁在Java中是通过使用无锁编程来实现，最常采用的是CAS算法，Java原子类中的递增操作就通过CAS自旋实现的。

• 悲观锁适合写操作多的场景，先加锁可以保证写操作时数据正确。

• 乐观锁适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升。

自旋是怎么回事？

阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态转换需要耗费处理器时间。如果同步代码块中的内容过于简单，状态转换消耗的时间有可能比用户代码执行的时间还要长。

因此如果A线程中的同步代码块就简单的几行逻辑代码，那么当B线程去获取A线程的锁的时候，我们将B线程进行自旋，如果在自旋完成后A线程锁定同步资源的线程已经释放了锁，那么B线程就可以不必阻塞而是直接获取同步资源，从而避免切换线程的开销。这就是自旋锁。

自旋有什么缺点？

自旋等待虽然避免了线程切换的开销，但它要占用处理器时间。如果锁被占用的时间很短，自旋等待的效果就会非常好。反之，如果锁被占用的时间很长，那么自旋的线程只会白浪费处理器资源。所以，自旋等待的时间必须要有一定的限度，如果自旋超过了限定次数（默认是10次，可以使用-XX:PreBlockSpin来更改）没有成功获得锁，就应当挂起线程。

自旋锁在JDK1.4.2中引入，使用-XX:+UseSpinning来开启。JDK 6中变为默认开启，并且引入了自适应的自旋锁（适应性自旋锁）。

所谓适应性自旋锁就是内部逻辑判断这个锁是否需要自旋，自旋次数应该是多少。

能说说对synchronized的理解吗？

synchronized在代码层面是一个关键字，jvm通过该关键字进行一个同步锁，锁信息存放在对象头中，属于悲观锁。

针对于synchronized存在着四种锁，无锁，偏向锁，轻量级锁，重量级锁。

只能升级锁，无法降级锁。

只有重量级锁涉及到内核态。

对象头如何存储锁信息的？

以Hotspot虚拟机为例，Hotspot的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。

Mark Word：默认存储对象的HashCode，分代年龄和锁标志位信息。这些信息都是与对象自身定义无关的数据，所以Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。

Klass Point：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

其中，hashCode是惰性的，第一次默认是0，使用hashCode()函数的时候会生成并赋值，后续直接使用。age存储的是之前博客中GC相关的分代年龄。

关于对Java象头，可以使用JOL工具（jol-core）类直接打印对象头。

为什么synchronized可以实现线程同步？

这里需要了解另外一个知识点，Monitor。PS，这里针对的是重量级锁的原理。

monitor属于编程语言的范畴，C语言不支持monitor，而java支持monitor机制，主要是利用内核中的mutex ，即互斥量，它的封装都是c++层的pthread 类中。

monitor的重要特点是，同一个时刻，只有一个进程/线程能进入monitor中定义的临界区，这使得monitor能够达到互斥的效果。但仅仅有互斥的作用是不够的，无法进入monitor临界区的 进程/线程，它们应该被阻塞，并且在必要的时候会被唤醒。

monitor的基本元素：

• 临界区

• monitor对象和锁

• 条件变量以及定义在monitor对象上的wait，signal操作

使用monitor主要是为了互斥进入临界区，为了能够阻塞无法进入临界区的进程，线程，需要一个monitor object来协助，这个object内部会有相应的数据结构，例如列表，用来保存被阻塞的线程；同时由于monitor机制本质是基于mutex原语的，所以object必须维护一个基于mutex的锁。

java中的临界区

在java中，被 synchronized 关键字修饰的方法、代码块，就是 monitor 机制的临界区。

java中的monitor对象

synchronized 关键字在使用的时候，往往需要指定一个对象与之关联，例如 synchronized(this)，或者 synchronized(ANOTHER_LOCK)，synchronized 如果修饰的是实例方法，那么其关联的对象实际上是 this，如果修饰的是类方法，那么其关联的对象是 this.class。总之，synchronzied 需要关联一个对象，而这个对象就是 monitor object。

java中的条件变量

为了在适当的时候能够阻塞和唤醒 进程/线程，还需要引入一个条件变量(条件变量通常被一个线程用于使自己等待，直到一个涉及共享数据的条件表达式到达特定的状态。当另外的协作线程指示共享数据的状态已发生变化，调度器就唤醒在该条件变量上挂起的线程。于是新唤醒的线程重新对它的条件表达式进行求值，如果共享数据已到达合适状态，就恢复处理)

这个条件变量用来决定什么时候是“适当的时候”，这个条件可以来自程序代码的逻辑，也可以是在 monitor object 的内部，总而言之，程序员对条件变量的定义有很大的自主性。不过，由于 monitor object 内部采用了数据结构来保存被阻塞的队列，因此它也必须对外提供两个 API 来让线程进入阻塞状态以及之后被唤醒，分别是 wait 和 notify。

这些方法的具体实现，依赖于一个叫 ObjectMonitor 模式的实现，这是 JVM 内部基于 C++ 实现的一套机制，基本原理如下所示：

当一个线程需要获取 Object 的锁时，会被放入 EntrySet 中进行等待，如果该线程获取到了锁，成为当前锁的 owner。如果根据程序逻辑，一个已经获得了锁的线程缺少某些外部条件，而无法继续进行下去（例如生产者发现队列已满或者消费者发现队列为空），那么该线程可以通过调用 wait 方法将锁释放，进入 wait set 中阻塞进行等待，其它线程在这个时候有机会获得锁，去干其它的事情，从而使得之前不成立的外部条件成立，这样先前被阻塞的线程就可以重新进入 EntrySet 去竞争锁。这个外部条件在 monitor 机制中称为条件变量。

synchronized不同的修饰有什么区别？

主要分为 synchronized(this|object) {} 对象锁、 synchronized(类.class) {} 类锁

• 对于静态方法，由于此时对象还未生成，所以只能采用类锁；

• 只要采用类锁，无所谓是哪个类，按顺序访问。

• 对于对象锁（this），如果是同一个实例，就会按顺序访问，但是如果是不同实例，就可以同时访问。

• 如果对象锁跟访问的对象没有关系，那么就会都同时访问。

synchronized为什么需要分成四种锁？

也就是无锁 、偏向锁 、 轻量级锁 、 重量级锁，前面说到这些信息是存在对象头里的，为什么需要区分呢，需要先从重量级说起。

首先重量级锁需要进入内核态，通过内核来实现互斥，同时会出现阻塞和唤醒操作，消耗性能，有些场景并不一定需要重量级锁，于是轻量级锁通过用CAS操作和自旋来解决加锁问题。

在轻量级锁的情况下，可能在大多数的情况下，锁总是由同一个线程多次获得，不存在多线程竞争，那么轻量级锁的CAS操作就显得消耗性能，所以出现了偏向锁。其目标就是在只有一个线程执行同步代码块时能够提高性能。

无锁没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。无锁的特点就是修改操作在循环内进行，线程会不断的尝试修改共享资源。如果没有冲突就修改成功并退出，否则就会继续循环尝试。CAS算法的实现就是一种无锁。

无锁其实在synchronized中只存在于概念，因为在JD6之后默认是偏向锁，可以使用JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，关闭之后程序默认会进入轻量级锁状态。

	CAS	自旋锁
JDK1.4.2	1.5版本之前存在ABA问题	开始引入，使用-XX:+UseSpinning来开启
JDK1.5	提供了AtomicReference类来保证引用对象之间的原子性
JDK 6		默认开启，并且引入了自适应的自旋锁（适应性自旋锁）

这里简单说下四种锁的原理，再结合下图理解。无锁，即类似CAS算法。

偏向锁， 当一个线程访问同步代码块并获取锁时，会在Mark Word里存储锁偏向的线程ID。在线程进入和退出同步块时不再通过CAS操作来加锁和解锁，而是检测Mark Word里是否存储着指向当前线程的偏向锁。

因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可。

偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程不会主动释放偏向锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有字节码正在执行），它会首先暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态。撤销偏向锁后恢复到无锁（标志位为“01”）或轻量级锁（标志位为“00”）的状态。

轻量级锁，在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为“01”状态，是否为偏向锁为“0”），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝，然后拷贝对象头中的Mark Word复制到锁记录中。

拷贝成功后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针，并将Lock Record里的owner指针指向对象的Mark Word。

如果这个更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位设置为“00”，表示此对象处于轻量级锁定状态。

如果轻量级锁的更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明多个线程竞争锁。

若当前只有一个等待线程，则该线程通过自旋进行等待。但是当自旋超过一定的次数，或者一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。

可以简单区分下偏向锁和轻量级锁，偏向锁释放锁后其他线程无法获取锁，轻量级锁释放锁后其他线程可以获取锁。

下图是关于对象头和不同的锁之间的转换：

图中有个问题，暂时没搞明白，如果有懂的大佬还望指教。

1. 暂停和唤醒原有的偏向锁线程是通过内核来处理的还是用户态进行处理？

Lock和Synchronized有什么区别？

• synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；

• Lock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去，不能够响应中断；

• 通过Lock可以知道有没有成功获取锁，而synchronized却无法办到。

• Lock可以提高多个线程进行读操作的效率。（可以通过ReadWriteLock实现读写分离）

• 性能上来说，在资源竞争不激烈的情形下，Lock性能稍微比synchronized差点（编译程序通常会尽可能的进行优化synchronized）。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。

• 到了JDK1.6，对synchronize加入了很多优化措施，有自适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在JDK1.6上synchronized的性能并不比Lock差。官方也表示，他们也更支持synchronized，在未来的版本中还有优化余地，所以还是提倡在synchronized能实现需求的情况下，优先考虑使用synchronized来进行同步。

• 个人认为，synchronized的可控性没有lock好，只能说慎用。

Lock可以衍生出哪些锁？

• 公平锁，非公平锁

• 可重入锁，非可重入锁

• 独享锁，共享锁

• 可中断锁（ReentrantLock提供了lockInterruptibly（）的功能，可以中断争夺锁的操作，抢锁的时候会check是否被中断，中断直接抛出异常，退出抢锁。而Synchronized只有抢锁的过程，不可干预，直到抢到锁以后，才可以编码控制锁的释放）

• 快速反馈锁（ReentrantLock提供了trylock（） 和 trylock（tryTimes）的功能，不等待或者限定时间等待获取锁，更灵活。可以避免死锁的发生）

• 读写锁（ReentrantReadWriteLock类实现了读写锁的功能，类似于Mysql，锁自身维护一个计数器，读锁可以并发的获取，写锁只能独占。而synchronized全是独占锁）

公平锁、非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁，线程直接进入队列中排队，队列中的第一个线程才能获得锁。

非公平锁是多个线程加锁时直接尝试获取锁，获取不到才会到等待队列的队尾等待。但如果此时锁刚好可用，那么这个线程可以无需阻塞直接获取到锁。

公平锁演示图：

非公平锁演示图：

插队成功的情况是，在插队的时候，刚好队列头刚刚释放锁。

ReentrantLock中的公平锁、非公平锁

在ReentrantLock里面有一个内部类Sync，Sync继承AQS（AbstractQueuedSynchronizer），添加锁和释放锁的大部分操作实际上都是在Sync中实现的。它有公平锁FairSync和非公平锁NonfairSync两个子类。ReentrantLock默认使用非公平锁，也可以通过构造器来显示的指定使用公平锁。

hasQueuedPredecessors() 主要是判断当前线程是否位于同步队列中的第一个。如果是则返回true，否则返回false。

可重入锁 VS 非可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。

比如锁代码如下：

public class Widget {
    public synchronized void doSomething() {
        System.out.println("方法1执行...");
        doOthers();
    }

    public synchronized void doOthers() {
        System.out.println("方法2执行...");
    }
}

类中的两个方法都是被内置锁synchronized修饰的，doSomething()方法中调用doOthers()方法。因为内置锁是可重入的，所以同一个线程在调用doOthers()时可以直接获得当前对象的锁，进入doOthers()进行操作。

如果是一个不可重入锁，那么当前线程在调用doOthers()之前需要将执行doSomething()时获取当前对象的锁释放掉，实际上该对象锁已被当前线程所持有，且无法释放。所以此时会出现死锁。

如果是不可重入锁：

独享锁、共享锁

独享锁也叫排他锁，是指该锁一次只能被一个线程所持有。如果线程T对数据A加上排它锁后，则其他线程不能再对A加任何类型的锁。获得排他锁的线程即能读数据又能修改数据。JDK中的synchronized和JUC中Lock的实现类就是互斥锁。

共享锁是指该锁可被多个线程所持有。如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排它锁。获得共享锁的线程只能读数据，不能修改数据。

独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。主要为 ReentrantReadWriteLock

/   总结   /

JAVA对锁的封装已经简单易用，了解原理只是为了能够开发者在不同的业务场景下使用不同的锁。

而在Android的业务下，锁的使用确实相较于后端会比较少。

推荐阅读：

我的新书，《第一行代码 第3版》已出版！

正则表达式，你还记得么？

事件是如何到达Activity的？

欢迎关注我的公众号

学习技术或投稿

长按上图，识别图中二维码即可关注