线程的基本使用

1.synchronized之错误的加锁和原因分析

锁一定要加在一个不变的对象上
volatile 关键字，最轻量的同步机制
volatile 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
可以保证可见，但是不能保证原子
volatile 最适用的场景：一个线程写，多个线程读。

2.ThreadLocal辨析

ThreadLocal 为每个线程都提供了变量的副本，使得每个线程在某一时间訪问到的并非同一个对象，这样就隔离了多个线程对数据的数据共享

void set(Object value) 设置当前线程的线程局部变量的值。
public Object get() 该方法返回当前线程所对应的线程局部变量。
public void remove() 将当前线程局部变量的值删除，目的是为了减少内存的占用。
protected Object initialValue()返回该线程局部变量的初始值，该方法是一个 protected 的方法，显然是为了让子类覆盖而设计的。

ThreadLocal辨析

每个线程独有的 ThreadLocalMap 然后再用 ThreadLocal 的当前实例，拿到 Map 中的相应的 Entry，然后就可以拿到相应的值返回出去。当然，如果 Map 为空，还会先进行map 的创建，初始化等工作。

ThreadLocal可能会产生内存泄漏

图中的虚线表示弱引用。
这样，当把 threadlocal 变量置为 null 以后，没有任何强引用指向 threadlocal 实例，所以 threadlocal 将会被 gc 回收。这样一来，ThreadLocalMap 中就会出现 key 为 null 的 Entry，就没有办法访问这些 key 为 null 的 Entry 的 value，如果当前线程再迟迟不结束的话，这些 key 为 null 的 Entry 的 value 就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value，而这块 value 永远不会被访问到了，所以存在着内存泄露。

ThreadLocal 内存泄漏的根源是：由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果没有手动删除对应 key 就会导致内存泄漏，而不是因为弱引用。总结 JVM 利用设置 ThreadLocalMap 的 Key 为弱引用，来避免内存泄露。 JVM 利用调用 remove、get、set 方法的时候，回收弱引用。当 ThreadLocal 存储很多 Key 为 null 的 Entry 的时候，而不再去调用 remove、 get、set 方法，那么将导致内存泄漏。使用线程池+ ThreadLocal 时要小心，因为这种情况下，线程是一直在不断的重复运行的，从而也就造成了 value 可能造成累积的情况。

ThreadLocal线程不安全的情况
每个线程中的 ThreadLocal 都应该持有一个新的 Number 对象。

3.线程之间的协作

等待和通知
wait():调用该方法的线程进入 WAITING 状态,只有等待另外线程的通知或被中断才会返回.需要注意,调用 wait()方法后,会释放对象的锁
notify/notifyAll
通知一个在对象上等待的线程,使其从 wait 方法返回,而返回的前提是该线程获取到了对象的锁，没有获得锁的线程重新进入 WAITING 状态。
等待和通知的标准范式
等待方遵循如下原则。
1）获取对象的锁。
2）如果条件不满足，那么调用对象的 wait()方法，被通知后仍要检查条件。
3）条件满足则执行对应的逻辑。

通知方遵循如下原则。
1）获得对象的锁。
2）改变条件。
3）通知所有等待在对象上的线程。
notify 和 notifyAll 应该用谁尽可能用 notifyall()，谨慎使用 notify()，因为 notify()只会唤醒一个线程，我们无法确保被唤醒的这个线程一定就是我们需要唤醒的线程
调用 yield() 、sleep()、wait()、notify()等方法对锁有何影响？
yield() 、sleep()被调用后，都不会释放当前线程所持有的锁。调用 wait()方法后，会释放当前线程持有的锁，而且当前被唤醒后，会重新去竞争锁，锁竞争到后才会执行 wait 方法后面的代码。调用 notify()系列方法后，对锁无影响，线程只有在 syn 同步代码执行完后才会自然而然的释放锁，所以 notify()系列方法一般都是 syn 同步代码的最后一行。

4.线程的并发工具类

Fork-Join（分而治之的算法）

Fork-Join原理
工作密取
当前线程的 Task 已经全被执行完毕，则自动取到其他线程的 Task 池中取出 Task 继续执行。

工作密取
Fork/Join 使用的标准范式

Fork/Join 使用的标准范式
CountDownLatch(闭锁)
闭锁，CountDownLatch 这个类能够使一个线程等待其他线程完成各自的工作后再执行。例如，应用程序的主线程希望在负责启动框架服务的线程已经启动所有的框架服务之后再执行。
CountDownLatch 是通过一个计数器来实现的，计数器的初始值为初始任务的数量。每当完成了一个任务后，计数器的值就会减 1 （CountDownLatch.countDown()方法）。当计数器值到达 0 时，它表示所有的已经完成了任务，然后在闭锁上等待 CountDownLatch.await()方法的线程就可以恢复执行任务。
CyclicBarrier
会让所有线程都等待完成后才会继续下一步行动
Semaphore
Semaphore 通常我们叫它信号量，可以用来控制同时访问特定资源的线程数量，通过协调各个线程，以保证合理的使用资源。
Exchange
Exchange位于java.util.concurrent包下面，主要是用于线程之间数据交换的工具类，经常用于管道设计和遗传算法中

6.线程的状态

初始（new）
运行中（running）
就绪（ready）
等待（waiting）
等待超时（timed_waiting）
终止（terminated）
阻塞（blocked）

线程的状态

死锁
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。

产生条件：
1.多个操作者争夺多个资源
2.争夺资源的顺序不对
3.拿到资源不放手
学术说法：
1.互斥条件
2.请求和保持
3.不剥夺
4.环路等待

活锁
两个线程在尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生同一个线程总是拿到同一把锁，在尝试拿另一把锁时因为拿不到，而将本来已经持有的锁释放的过程。
解决办法：每个线程休眠随机数，错开拿锁的时间。
线程饥饿
低优先级的线程，总是拿不到执行时间

7.CAS（Compare And Swap）

什么是原子操作？如何实现原子操作？
假定有两个操作A和B(A和B可能都很复杂)，如果从执行A的线程来看，当另一个线程执行B时，要么将B全部执行完，要么完全不执行B，那么A和B对彼此来说是原子的。
synchronized关键字是基于阻塞的锁机制，也就是说当一个线程拥有锁的时候，访问同一资源的其它线程需要等待，直到该线程释放锁
CAS原理
基本思路就是，如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。循环CAS就是在一个循环里不断的做cas操作，直到成功为止。

synchronized  悲观锁 
CAS 乐观锁

CAS的问题
1.ABA问题
因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。
ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A。
2.循环时间长开销大。
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
3.只能保证一个共享变量的原子操作。
Jdk中相关原子操作类的使用
更新基本类型类：AtomicBoolean，AtomicInteger，AtomicLong
更新数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
更新引用类型：AtomicReference，AtomicMarkableReference，AtomicStampedReference