原文：JavaGuide
2.3 多线程
1. 什么是线程和进程
进程
进程是程序的一次执行过程，是系统运行程序的基本单位。进程是动态的，系统运行一个程序，即是一个进程从创建、运行到消亡的过程。
Java中，启动main函数就是启动一个JVM进程，main函数所在的线程就是这个进程中的一个线程，也称主线程。
线程
线程与进程类似，但线程是一个比进程更小的执行单位。一个进程在其执行过程中可以产生多个线程。
与进程不同的是，同个进程的多个线程共享进程的堆和方法区资源。每个线程有自己的程序计数器、虚拟机栈和本地方法栈。
所以系统在产生一个线程、或者在各个线程之间切换时，负担比进程要小。
线程也称为轻量级进程。
2. 进程与线程的关系和区别
JVM中进程和线程的区别
从上面可以看出，一个进程中可以有多个线程，多个线程共享进程的堆和方法区（JDK1.8之后的元空间）资源。但每个线程有自己的程序计数器、虚拟机栈和本地方法栈。
总结： 线程是进程划分为更小的运行单位。各进程是独立的，但一个进程中的各个线程，是共享部分资源的。
- 进程：执行开销大、但利于资源的管理和保护；
- 线程：执行开销小、但不利于资源的管理和保护，
为什么程序计数器是私有的：
- 1.字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如顺序执行、选择、循环、异常处理等。
- 2.多线程情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来后的时候能够知道上次运行的位置。
注意：如果执行的是native方法，程序计数器记录的是undefined 地址，只有执行的是Java代码时，程序计数器记录的才是下一条指令的地址。
所以，程序计数器私有主要是为了线程切换后能恢复到正确的执行位置。
为什么虚拟机栈和本地方法栈是私有的
- 虚拟机栈：每个Java方法在执行的同时会创建一个栈帧用于存储局部变量、操作数栈、常量池引用等信息。从方法调用直至执行完成的过程，就对应着一个栈帧在 Java 虚拟机栈中 入栈和出栈的过程。
- 本地方法栈：和虚拟机栈所发挥的作用非常相似。区别是虚拟机栈是为执行Java方法服务，而本地方法栈则为使用Native方法服务， HotSpot 虚拟机中这两个是合二为一的。
所以，为了保证线程中的变量不被别的线程访问，虚拟机栈和本地方法栈是线程私有的。
一句话了解堆和方法区
堆和方法区是所有线程共享的资源。
- 堆：进程中最大的一块内存，主要用于存放新创建的对象（所有对象都在这里分配内存）
- 方法区：主要是用于存放已被加载的类信息、常量、静态变量和即时编译器编译后的代码等数据。
3. 并发 VS 并行
- 并发：同一时间段、多个任务都在执行（单位时间内不一定同时执行）
- 并行：单位时间内，多个任务同时执行。
4. 为什么使用多线程
总体原因：
- 1.计算机底层方面，线程可以看做是一种轻量级的进程，是程序执行的最小单位，线程间的切换和调度成本是远远小于进程的。另外多核CPU允许多个线程可以并行执行，这也减少了线程上下文切换的开销。
- 2.从互联网发展趋势，现代系统要求百万级甚至千万级的并发量，而多线程并发编程正是高并发系统的基础，利用好多线程机制可以大大提高系统整体的并发能力以及性能。
- 3.单核时代，利用多线程主要是为了提高CPU和IO设备的综合利用率。当一个线程执行CPU计算时，另外一个线程可以执行IO操作。
- 4.多核时代，利用多线程主要是为了提高CPU利用率。
5. 多线程可能带来的问题
并发编程的目的是为了提高程序的执行效率，提高运行速度，但并发编程并不总是能达到目的的，还会遇到很多问题，例如：内存泄漏、上下文切换、死锁以及受限于硬件和软件资源闲置的问题。
6.线程的生命周期和状态
Java线程在运行的生命周期中的指定时刻只能处于下面6中不同状态的其中一个状态：
| 状态名称 | 说明 |
|---|---|
| new | 初始状态，线程被构建，但是还没有调用start()方法 |
| runnable | 运行状态，Java线程将操作系统中的就绪和运行两种状态统称为“运行中” |
| blocked | 阻塞状态，表示线程阻塞于锁 |
| wating | 等待状态，表示线程进入等待状态，进入该状态表示当前线程需要等待其他线程做出一些特定动作（通知或中断） |
| time_wating | 超时等待状态，该状态不同于waiting，他是可以在指定时间内自行返回的。 |
| terminated | 终止状态，表示当前线程已经执行完毕 |
7. 上下文切换
多线程编程中一般线程的个数都大于CPU的核心数，而一个CPU核心在任意时刻都是能被一个线程使用，为了让这些线程都能得到有效的执行，CPU采用的策略是为每个线程分配时间片并轮转的形式。当一个线程的时间片用完的时候就会重新处于就绪状态让给其他线程使用，这个过程就属于一次上下文切换。
概括来说就是：当前任务在执行完CPU时间片切换到另一个任务之前，会先保存自己的状态，以便下次再切换回这个任务时，可以再加载这个任务的状态。
因此，上下文切换对系统来说就是意味着消耗大量的CPU时间，事实上，可能是操作系统中时间消耗最大的操作。
Linux 相对其他操作系统（包括其他类Unix系统）的一个优点就是其上下文切换和模式切换的时间耗时非常少。
8. 线程死锁
认识线程死锁
多个线程同时被阻塞，他们中的一个或者全部都在等待某个资源被释放。由于线程被无限期的阻塞，因此程序不能正常终止。
发生死锁的4个条件
- 1.互斥条件，该资源任意时刻只能由一个线程占用。
- 2.请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
- 3.不剥夺条件：线程已获得资源在未使用完毕之前不能被其他线程剥夺，只有自己使用结束才能释放资源。
- 循环等待条件：若干线程之间形成一种首尾相接的循环等待资源关系。
解决死锁问题
只要破坏产生死锁的4个条件之一即可。
9. sleep() VS wait()
- 1.sleep() 和 wait() 最大的区别就是：
- sleep() 方法没有释放锁；
- wait() 方法释放了锁。
- 2.sleep() 和 wait() 都可以暂停线程的执行
- 3.wait() 通常被用于线程间的交互/通信，sleep() 通常用于暂停执行。
- 4.wait() 方法被调用后，线程不会自动苏醒，需要别的线程调用同一个对象上的notify() 或者notifyAll() 方法。 sleep() 方法执行完成后，线程会自动苏醒。 或者可以使用wait(long timeout) 超时后线程会自动苏醒。
10. start() VS run()
正常启动一个线程，首先需要new一个Thread，然后线程进入新建状态，调用 start() 后，会启动线程并使线程进入就绪状态，当分配到时间片后就可以执行了。start()会执行线程的相应准备工作，然后自动执行run() 方法，这才是真正的多线程工作。
如果直接执行run() 方法，相当于把run() 方法当做main线程下的普通方法去执行，并不会在某个线程中执行它。
总结：
调用start() 方法可以启动线程并使线程进入就绪状态。而run()方法只是thread 的一个普通方法调用。
10. synchronized 关键字
synchronized 关键字解决的是多个线程之间访问资源的同步性，synchronized 关键字可以保证它被修饰的方法或者代码块在任意时刻只能有一个线程执行。
早期Java 版本中，synchronized 属于重量级锁，效率低下，因为synchronized 采用的监视器锁（monitor）是依赖于底层操作系统的Mutex Lock实现，所有要挂起或唤醒一个线程，都需要操作系统来帮忙完成，而操作系统实现线程之间的切换时需要从用户态转换到内核态，需要消耗较长的时间。
Java 6之后，Java 官方从JVM层面对synchronized进行了较大的优化，现在锁效率已经很不错了。
JDK1.6 对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。
synchronized 的三种用法
- 1.修饰实例方法：作用于当前对象实例加锁，进入同步代码前要获得当前对象实例的锁。
- 2.修饰静态方法：也就是给当前类加锁，会作用于类的所有对象实例。
- 3.修饰代码块：指定加锁对象，对给定对象加锁，进入同步代码块前需要获得给定对象的锁。
总结：synchronized 关键字加到static 静态方法和synchronized(class) 代码块 都是给class 类加锁。
synchronized 关键字加到实例方法上是给对象实例加锁。
尽量不要使用 synchronized(String a), 因为在JVM中，字符串常具有缓存功能。
双重校验锁实现对象单例（线程安全）
public class Singleton{
private volatile static Singleton uniqueInstance;
private Singleton() {}
public static Singleton getUniqueInstance() {
// 判断对象是否已经实例化过，没有实例化才进入加锁代码
if(uniqueInstance == null) {
// 类对象加锁
synchronized(Singleton.class) {
if(uniqueInstance == null) {
uniqueInstance = new Singleton();
}
}
}
return uniqueInstace;
}
}
其中注意uniqueInstance 需要 volatile 关键字修饰。因为 uniqueInstance = new Singleton() 这句代码是分为三步执行的：
- 1.为uniqueInstance 分配内存空间
- 2.初始化uniqueInstance
- 3.将uniqueInstance 指向分配的内存地址
JVM具有指令重排的特性，执行顺序有可能变成 1 => 3 => 2.
如果thread1 执行了1和3， thread2 刚好执行了getUniqueInstance() 后发现uniqueInstance 不为空，直接返回还未被初始化的uniqueInstance，导致出问题。
指令重排在单线程不会出现问题，但多线程会导致一个线程获得还没有初始化的实例。使用volatile可以禁止JVM的指令重排，保证在多线程环境下也能正常运行。
synchronized 关键字底层原理
synchronized 同步语句块
public class SynchronizedDemo {
public void method() {
synchronized(this) {
System.out.println("synchronized 代码块");
}
}
}
synchronized 同步语句块，在底层是通过JVM来实现的，具体是通过monitorenter 和 monitorexit指令。当执行monitorenter指令时，线程试图获取锁，也就是获取每个Java对象的对象头中的monitor对象。这也是Java中的任意对象能作为锁的原因。
当monitor的计数器为0时，说明可以成功获取，获取后将其+1，执行完成后，在 monitorexit 指令中将锁计数设为0，将锁释放。
如果获取monitor对象锁失败，那么当前线程就要阻塞等待，直到锁被另外一个线程释放为止。
synchronized 修饰方法
public class SynchronizedDemo2 {
public synchronized void method() {
System.out.println("synchronized 方法");
}
}
synchronized 修饰的方法并没有使用 monitorenter 和 monitorexit 指令，而是采用ACC_SYNCHRONIZED 标识，其表明该方法是一个同步方法，JVM 通过该ACC_SYNCHRONIZED 访问标志来辨别一个方法是否是同步方法，从而执行相应的同步调用。
锁主要存在4种状态：
- 1.无锁状态
- 2.偏向锁状态
- 3.轻量级锁状态
- 4.重量级锁状态
JDK1.6 对synchronized 的优化
引入了大量的优化，如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减少锁操作的开销。
偏向锁
在没有多线程竞争的前提下，为了减少传统的重量级锁（使用操作系统互斥量）产生的性能消耗，偏向锁会在无竞争情况下就把整个同步都消除掉。偏向锁会偏向第一个获取它的线程，如果接下来的执行中，如果该锁没有被其他线程获取，那么持有偏向锁的线程就不需要进行同步。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样的场合极有可能每次申请锁的线程都是不相同的，所有这种情况下不应该使用偏向锁。不过，偏向锁失败后，不会直接膨胀为重量级锁，而是先升级为轻量级锁。
轻量级锁
在没有多线程竞争的前提下，为了减少传统的重量级锁（使用操作系统互斥量）产生的性能消耗，轻量级所会在无竞争的情况下使用CAS操作去代替使用互斥量。但如果存在锁竞争，除了互斥量开销外，还会额外产生CAS操作，性能更慢。如果锁竞争激烈，那么轻量级锁将很快膨胀为重量级锁。
自旋锁和自适应自旋锁
一般线程持有锁的时间都不是太长，所以仅仅为了这一点点时间去挂起/恢复线程是得不偿失的。所以JVM尝试让后面来请求锁的线程等待一会而不被挂起，看看持有锁的线程是否很快就释放锁。为了让一个线程等待，我们只需要让一个线程执行一个忙循环（自旋），这种操作就成为自旋锁。JDK1.6 引入的是自适应自旋锁，它自旋的时间不在固定，而是和前一次同一个锁上的自旋时间以及锁的拥有者的状态来决定等待时间。
锁消除
JVM在编译时，检测到不存在竞争的共享数据，就执行锁消除操作，从而节省毫无意义的请求锁的时间
锁粗化
原则上，在编写代码的时候将同步块的作用范围限制得尽量小：在共享数据的实际作用域才进行同步，这样使得需要同步的操作数量尽可能变小。
不过，上面是适合大部分情况的，但如果一系列的连续操作都是对同一个对象反复加锁和解锁，那么会带来很多不必要的性能消耗，这时就会执行锁粗化操作。
synchronized 和 ReenTrantLock 对比
- 两者都是可重入锁：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象的锁还没有释放，当其再次想要获取这个对象的锁的时候，还是可以获取的，锁的计数器+1，所以要等到锁的计数器下降为0才可以释放锁。如果不可锁重入的话，会造成死锁。
- synchronized 依赖于JVM（monitorenter&monitorexit 和 ACC_SYNCHRONIZED标识），ReenTrantLock 依赖于API（lock() & unlock() 配合 try/finally 语句块来实现）
- ReenTrantLock 比 synchronized 增加了一些高级功能：
- 等待可中断：lock.lockInterruptibly()
- 可实现非公平锁或者公平锁：先等待的线程先获得锁。
- 可实现选择性通知
- ReenTrantLock 比 synchronized 增加了一些高级功能：
- 4.JDK1.6 之后，synchronized 和 ReenTrantLock的性能差不多。
