JUC面试指南，并发编程+ThreadLocal

写在前面：
先声明下，这个面试专题，主要是写给自己的，用来在挤公交的时候学习下，顺便做个分享。。。 我就是个小菜鸡。

](JUC并发编程)

JUC

JMM(Java内存模型)

为了解决CPU的高速运算和内存的读取效率的差异，在CPU中加入了高速缓存。且这些缓存具有缓存一致性。
描述的一种规则或规范，通过这组规范定义了程序中各个变量的访问方式；

有关于同步的规定：
线程解锁前，必须把共享变量的值刷新回主内存；
线程加锁前，必须读取主内存的最新值到自己的工作内存；
加锁解锁是同一把锁；

1.程序以及数据被加载到主内存
2.指令和数据被加载到CPU的高速缓存
3.CPU执行指令，把结果写到高速缓存
4.高速缓存中的数据写回主内存

Volatile

作用：保证了可见性和有序性，但是不保证原子性；
所谓原子性：即不可分割，完整性，当某个线程正在做业务时，不可以加塞或者分割。表现形式：当多线程被volatile锁定的i被 执行i++共1000次时，结果不一定为1000；可能会变小；

流程
在生成汇编代码时会在volatile修饰的共享变量进行写操作的时候会多出Lock前缀的指令

1. 将当前处理器缓存行的数据写回系统内存；
2. 这个写回内存的操作会使得其他CPU里缓存了该内存地址的数据无效
3. 当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。

保证有序性：通过内存屏障来保证的，它保证了特定操作的执行顺序，保证了某些变量内存有序性。

内存屏障的种类：（偏，字节考过。。。）

1. LoadLoad 屏障
   序列：Load1,Loadload,Load2
   确保Load1所要读入的数据能够在被Load2和后续的load指令访问前读入。通常能执行预加载指令或/和支持乱序处理的处理器中需要显式声明Loadload屏障，因为在这些处理器中正在等待的加载指令能够绕过正在等待存储的指令。 而对于总是能保证处理顺序的处理器上，设置该屏障相当于无操作。

2. StoreStore 屏障
   序列：Store1，StoreStore，Store2
   确保Store1的数据在Store2以及后续Store指令操作相关数据之前对其它处理器可见（例如向主存刷新数据）。通常情况下，如果处理器不能保证从写缓冲或/和缓存向其它处理器和主存中按顺序刷新数据，那么它需要使用StoreStore屏障。

3. LoadStore 屏障
   序列： Load1; LoadStore; Store2
   确保Load1的数据在Store2和后续Store指令被刷新之前读取。在等待Store指令可以越过loads指令的乱序处理器上需要使用LoadStore屏障。

4. StoreLoad Barriers
   序列: Store1; StoreLoad; Load2
   确保Store1的数据在被Load2和后续的Load指令读取之前对其他处理器可见。StoreLoad屏障可以防止一个后续的load指令 不正确的使用了Store1的数据，而不是另一个处理器在相同内存位置写入一个新数据。正因为如此，所以在下面所讨论的处理器为了在屏障前读取同样内存位置存过的数据，必须使用一个StoreLoad屏障将存储指令和后续的加载指令分开。Storeload屏障在几乎所有的现代多处理器中都需要使用，但通常它的开销也是最昂贵的。它们昂贵的部分原因是它们必须关闭通常的略过缓存直接从写缓冲区读取数据的机制。这可能通过让一个缓冲区进行充分刷新（flush）,以及其他延迟的方式来实现。

Synchronized

主要是利用了一个monitor的监视器来实现的。
任意线程对Object的访问，首先要获得Object的监视器，如果获取失败，该线程就进入同步状态，线程状态变为BLOCKED，当Object的监视器占有者释放后，在同步队列中的线程就会有机会重新获取该监视器。
使用Synchronized进行同步，其关键就是必须要对对象的监视器monitor进行获取，当线程获取monitor后才能继续往下执行，否则就只能等待。而这个获取的过程是互斥的，即同一时刻只有一个线程能够获取到monitor。

Lock

内部主要是AQS的队列同步器
有一个state标志位：1代表有线程占用；
里面有同步队列，用来存放其他线程；当需要特定条件时会进入等待队列；当满足了条件后就回到同步队列

synchronized 和 ReentrantLock 都提供了锁的功能，具备互斥性和不可见性。在 JDK 1.5 中 synchronized 的性能远远低于 ReentrantLock，但在 JDK 1.6 之后 synchronized 的性能略低于 ReentrantLock，

它的区别如下：
synchronized 是 JVM 隐式实现的，而 ReentrantLock 是 Java 语言提供的 API；
ReentrantLock 可设置为公平锁，而 synchronized 却不行；
ReentrantLock 只能修饰代码块，而 synchronized 可以用于修饰方法、修饰代码块等；
ReentrantLock 需要手动加锁和释放锁，如果忘记释放锁，则会造成资源被永久占用，而 synchronized 无需手动释放锁；
ReentrantLock 可以知道是否成功获得了锁，而 synchronized 却不行。

等待-通知机制

wait，notify和notifyAll都是Object类里面的；
sleep是Thread类中的。

Thread的生命周期

线程的状态以枚举的方式被定义在 Thread 的源码中

BLOCKED 和 WAITING 的区别

但二者有着本质的区别，首先它们状态形成的调用方法不同，blocked（Synchronized），waiting（Object.wait() 或 Thread.join() 方法）；
其次 BLOCKED 可以理解为当前线程还处于活跃状态，只是在阻塞等待其他线程使用完某个锁资源；而 WAITING 则是因为自身调用了 Object.wait() 或着是 Thread.join() 又或者是 LockSupport.park() 而进入等待状态，只能等待其他线程执行某个特定的动作才能被继续唤醒，比如当线程因为调用了 Object.wait() 而进入 WAITING 状态之后，则需要等待另一个线程执行 Object.notify() 或 Object.notifyAll() 才能被唤醒。

start() 和 run() 的区别

首先从 Thread 源码来看，start() 方法属于 Thread 自身的方法，并且使用了 synchronized 来保证线程安全，
从执行的效果来说，start() 方法可以开启多线程，让线程从 NEW 状态转换成 RUNNABLE 状态，而 run() 方法只是一个普通的方法。

其次，它们可调用的次数不同，start() 方法不能被多次调用，否则会抛出 java.lang.IllegalStateException；而 run() 方法可以进行多次调用，因为它只是一个普通的方法而已。

线程的数量

• CPU密集型（都是计算，不需要读取数据，例如一个计算圆周率至小数点一千位以下的程序，在执行的过程当中绝大部份时间用在三角函数和开根号的计算，便是属于CPU bound的程序）
  线程数量 = CPU核数 + 1
  不需要切换线程，+1是为了防止超频
• IO密集型
  最佳线程数 =CPU 核数 * [ 1 +（I/O 耗时 / CPU 耗时）]
  实际使用：CPU* 2或者3 ，进行压力测试

线程的常用方法

（1）join()
在一个线程中调用 other.join() ，这时候当前线程会让出执行权给 other 线程，直到 other 线程执行完或者过了超时时间之后再继续执行当前线程， join() 方法底层还是通过 wait() 方法来实现的

（2）yield()
看 Thread 的源码可以知道 yield() 为本地方法，也就是说 yield() 是由 C 或 C++ 实现的。yield() 方法表示给线程调度器一个当前线程愿意出让 CPU 使用权的暗示，但是线程调度器可能会忽略这个暗示。 yield() 执行非常不稳定，线程调度器不一定会采纳 yield() 出让 CPU 使用权的建议。

线程优先级

在 Thread 源码中和线程优先级相关的属性有 3 个：

// 线程可以拥有的最小优先级
public final static int MIN_PRIORITY = 1;

// 线程默认优先级
public final static int NORM_PRIORITY = 5;

// 线程可以拥有的最大优先级
public final static int MAX_PRIORITY = 10

线程的优先级可以理解为线程抢占 CPU 时间片的概率，优先级越高的线程优先执行的概率就越大，但并不能保证优先级高的线程一定先执行。
在程序中我们可以通过 Thread.setPriority() 来设置优先级.

线程池

线程池的参数：

核心线程数，缓冲（阻塞）队列，最大线程数，工厂方法，空闲时间，时间单位，拒绝策略

系统会先启动指定核心线程数的线程，然后开始工作，当核心线程数不够时，将任务放入缓冲队列，当缓冲队列满时，新建线程，直道达到最大线程数后，采取相应的拒绝策略； 工厂方法是用来生成线程的方法，一般默认； 当线程空闲一段时间后，会消失。

缓冲队列有：ArrayBlockQueue（有界），LinkedBlockQueue（无界），SynchronousQueue（同步队列）
拒绝策略：抛出异常；提交任务的线程直接执行任务；丢弃当前任务；丢弃最早的任务

自定义拒绝策略
自定义拒绝策略只需要新建一个 RejectedExecutionHandler 对象，然后重写它的 rejectedExecution() 方法即可

线程池的种类：

主要是4类：

1. newFixedThreadPool:固定线程数，采用LInkedBlockingQueue，适用于任务数量不均匀的场景；
2. newCachedThreadPool：利用SynchronousQueue，适用于低延迟的短期任务，缓冲队列的大小为1；
3. newSingleThreadPool：单个固定的线程池，适用于保证异步执行顺序的场景
4. newScheduledThreadPool：适用于定期执行任务的场景

execute() VS submit()

execute() 和 submit() 都是用来执行线程池任务的，它们最主要的区别是，submit() 方法可以接收线程池执行的返回值，而 execute() 不能接收返回值；
submit() 方法可以配合 Futrue 来接收线程执行的返回值。它们的另一个区别是 execute() 方法属于 Executor 接口的方法，而 submit() 方法则是属于 ExecutorService 接口的方法，

ThreadPoolExecutor 扩展

ThreadPoolExecutor 的扩展主要是通过重写它的 beforeExecute() 和 afterExecute() 方法实现的，我们可以在扩展方法中添加日志或者实现数据统计，比如统计线程的执行时间.

各种锁

乐观锁和悲观锁

乐观锁与悲观锁是一种广义上的概念，体现了看待线程同步的不同角度。在Java和数据库中都有此概念对应的实际应用。

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

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

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

CAS实现原理

（CAS，全称是 Compare And Swap，即“比较并交换”）。CAS 指令包含 3 个参数：共享变量的内存地址 A、用于比较的值 B 和共享变量的新值 C；并且只有当内存中地址 A 处的值等于 B时，才能将内存中地址 A 处的值更新为新值C
原子意味着尝试更改相同AtomicReference的多个线程（例如，使用比较和交换操作）不会使AtomicReference最终达到不一致的状态。

存在ABA问题，即A值经过了其他线程的调用后，值仍旧没变，类似于+1后又-1；就不能保证同步性了
解决：通过添加时间（AtomicLong）或者版本号（AtomicStampedReference）等原子操作来实现

可重入锁 ReentrantLock

线程可以重复获取同一把锁，当一个线程执行到某个Synchronized方法时，比如说method1，而在method1中会调用另外一个Synchronized方法method2，此时线程不必重新区申请锁，而是直接执行方法method2（Synchronized也是可重入锁）

共享锁和独占锁

只能被单线程持有的锁叫独占锁，可以被多线程持有的锁叫共享锁。
独占锁指的是在任何时候最多只能有一个线程持有该锁，比如 synchronized 就是独占锁，而 ReadWriteLock 读写锁允许同一时间内有多个线程进行读操作，它就属于共享锁。
独占锁可以理解为悲观锁，当每次访问资源时都要加上互斥锁，而共享锁可以理解为乐观锁，它放宽了加锁的条件，允许多线程同时访问该资源。

公平锁与非公平锁

ReentrantLock 这个类有两个构造函数，一个是无参
构造函数，一个是传入 fair 参数的构造函数。fair 参数代表的是锁的公平策略，如果传入 true
就表示需要构造一个公平锁，反之则表示要构造一个非公平锁。

JDK 1.6 锁优化

1. 自适应自旋锁

JDK 1.6 引入了自适应式自旋锁意味着自旋的时间不再是固定的时间了，比如在同一个锁对象上，如果通过自旋等待成功获取了锁，那么虚拟机就会认为，它下一次很有可能也会成功 (通过自旋获取到锁)，因此允许自旋等待的时间会相对的比较长，而当某个锁通过自旋很少成功获得过锁，那么以后在获取该锁时，可能会直接忽略掉自旋的过程，以避免浪费 CPU 的资源，这就是自适应自旋锁的功能。

在许多场景中，同步资源的锁定时间很短，为了这一小段时间去切换线程，线程挂起和恢复现场的花费可能会让系统得不偿失。如果物理机器有多个处理器，能够让两个或以上的线程同时并行执行，我们就可以让后面那个请求锁的线程不放弃CPU的执行时间，看看持有锁的线程是否很快就会释放锁。

适应性自旋锁：
自适应意味着自旋的时间（次数）不再固定，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也是很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。如果对于某个锁，自旋很少成功获得过，那在以后尝试获取这个锁时将可能省略掉自旋过程，直接阻塞线程，避免浪费处理器资源。

2. 锁升级

锁升级其实就是从偏向锁到轻量级锁再到重量级锁升级的过程，也称之为锁膨胀。

偏向锁是指在无竞争的情况下设置的一种锁状态。偏向锁的意思是它会偏向于第一个获取它的线程，当锁对象第一次被获取到之后，会在此对象头中设置标示为“01”，表示偏向锁的模式，并且在对象头中记录此线程的 ID，这种情况下，如果是持有偏向锁的线程每次在进入的话，不再进行任何同步操作，如 Locking、Unlocking 等，直到另一个线程尝试获取此锁的时候，偏向锁模式才会结束，偏向锁可以提高带有同步但无竞争的程序性能。但如果在多数锁总会被不同的线程访问时，偏向锁模式就比较多余了，此时可以通过 -XX:-UseBiasedLocking 来禁用偏向锁以提高性能。

在 JDK 1.6 之前，synchronized 是通过操作系统的互斥量（mutex lock）来实现的，这种实现方式需要在用户态和核心态之间做转换，有很大的性能消耗，这种传统实现锁的方式被称之为重量锁。

轻量锁是通过比较并交换（CAS，Compare and Swap）来实现的，它对比的是线程和对象的 Mark Word（对象头中的一个区域），如果更新成功则表示当前线程成功拥有此锁；如果失败，虚拟机会先检查对象的 Mark Word 是否指向当前线程的栈帧，如果是，则说明当前线程已经拥有此锁，否则，则说明此锁已经被其他线程占用了。当两个以上的线程争抢此锁时，轻量级锁就膨胀为重量级锁，这就是锁升级的过程，

读写锁

适用于非常普遍的并发场景：读多写少场景

读写锁基本原则：

1. 允许多个线程同时读共享变量；
2. 只允许一个线程写共享变量；
3. 如果一个写线程正在执行写操作，此时禁止读线程读共享变量

还可以看一下happens-before规则，太多了，我是记不住，要是面试，就大概讲解下吧。。。类似于内存屏障的功能。

ThreadLocal

ThreadLocal 提供了线程本地变量，它可以保证访问到的变量属于当前线程，每个线程都保存有一个变量副本，每个线程的变量都不同。ThreadLocal 相当于提供了一种线程隔离，将变量与线程相绑定。
ThreadLocal的作用和原理。
作用：要编写一个多线程安全(Thread-safe)的程序是困难的，为了让线程共享资源，必须小心地对共享资源进行同步，同步带来一定的效能延迟，而另一方面，在处理同步的时候，又要注意对象的锁定与释放，避免产生死结，种种因素都使得编写多线程程序变得困难。

尝试从另一个角度来思考多线程共享资源的问题，既然共享资源这么困难，那么就干脆不要共享，何不为每个线程创造一个资源的复本。将每一个线程存取数据的行为加以隔离，实现的方法就是给予每个线程一个特定空间来保管该线程所独享的资源。

ThreadLocal的原理:

每个Thread对象中都持有一个ThreadLocalMap的成员变量。每个ThreadLocalMap内部又维护了N个Entry节点，也就是Entry数组，每个Entry代表一个完整的对象，key是ThreadLocal本身，value是ThreadLocal的泛型值。

和Synchronized的区别

同步机制保证的是多线程同时操作共享变量并且能正确的输出结果。ThreadLocal不行啊，他把共享变量变成线程私有了，每个线程都有独立的一个变量。举个通俗易懂的案例：网站计数器，你给变量count++的时候带上synchronized即可解决。ThreadLocal的话做不到啊，他没发统计，他只能说能统计每个线程登录了多少次。

存储在jvm的哪个区域

还是在堆的。ThreadLocal对象也是对象，对象就在堆。只是JVM通过一些技巧将其可见性变成了线程可见。

真的只是当前线程可见吗

不是，貌似通过InheritableThreadLocal类可以实现多个线程访问ThreadLocal的值，但是我没研究过，知道这码事就行了。

会导致内存泄漏么

先看继承关系，发现是继承了弱引用，而且key直接是交给了父类处理super(key)，父类是个弱引用，所以key完全不存在内存泄漏问题，因为他不是强引用，它可以被GC回收的。

弱引用的特点：如果这个对象只被弱引用关联，没有任何强引用关联，那么这个对象就可以被GC回收掉。弱引用不会阻止GC回收。这是jvm知识。
再看value，发现value是个强引用，但是想了下也没问题的呀，因为线程终止了，我管你强引用还是弱引用，都会被GC掉的，因为引用链断了（jvm用的可达性分析法，线程终止了，根节点就断了，下面的都会被回收）。

这么分析一点毛病都没有，但是忘了一个主要的角色，那就是线程池，线程池的存在核心线程是不会销毁的，只要创建出来他会反复利用，生命周期不会结束掉，但是key是弱引用会被GC回收掉，value强引用不会回收，所以形成了如下场面：
Thread->ThreadLocalMap->Entry(key为null)->value
由于value和Thread还存在链路关系，还是可达的，所以不会被回收，这样越来越多的垃圾对象产生却无法回收，早晨内存泄漏，时间久了必定OOM。
解决方案ThreadLocal已经为我们想好了，提供了remove()方法，这个方法是将value移出去的。所以用完后记得remove()。

为什么用Entry数组而不是Entry对象

因为你业务代码能new好多个ThreadLocal对象，各司其职。
但是在一次请求里，也就是一个线程里，ThreadLocalMap是同一个，而不是多个，不管你new几次ThreadLocal，ThreadLocalMap在一个线程里就一个，因为ThreadLocalMap的引用是在Thread里的，所以它里面的Entry数组存放的是一个线程里你new出来的多个ThreadLocal对象。

开源框架哪些用到了ThreadLocal

Spring框架：
DateTimeContextHolder
RequestContextHolder

ThreadLocal里的对象一定是线程安全的吗

未必，如果在每个线程中ThreadLocal.set()进去的东西本来就是多线程共享的同一个对象，比如static对象，那么多个线程的ThreadLocal.get()获取的还是这个共享对象本身，还是有并发访问线程不安全问题。

还可以看一下happens-before规则，太多了，我是记不住，要是面试，就大概讲解下吧。。。类似于内存屏障的功能。