并发基础知识

本文包含以下几个内容：

• 锁：点这里 锁升级
• volatile关键字：点这里
• ThreadLocal
• Lock-Condition
• 线程
• 线程池

ThreadLocal

Java的Thread对象维护有着一个ThreadLocalMap对象（是一个Entry数组）。ThreadLocal.set(v)方法就是根据这个ThreadLocal对象计算出数组下标，然后把v注入对应Entry的value字段。

所以ThreadLocal其实是提供了保持对象的方法和避免参数传递的方便的对象访问方式，而不是用来解决对象共享访问问题的。

ThreadLocalMap中的废弃项目的回收依赖于显式地触发，否则就要等待线程结束，进而回收相应ThreadLocalMap! 这就是很多 OOM 的来源，所以通常都会建议，应用一定要自己负责remove，并且不要和线程池配合，因为worker线程往往是不会退出的。

参考：点这里

Lock-Condition

Condition = new ReentrantLock().newCondition;

Condition的作用简单来说是可以互相唤醒(signal)指定Condition.await的线程。

线程

生命周期和状态

Java 线程在运行的生命周期中的指定时刻只可能处于下面 6 种不同状态的其中一个状态

线程在生命周期中并不是固定处于某一个状态而是随着代码的执行在不同状态之间切换。Java 线程状态变迁如下图所示
由上图可以看出：线程创建之后它将处于 NEW（新建） 状态，调用 start() 方法后开始运行，线程这时候处于 READY（可运行） 状态。可运行状态的线程获得了 CPU 时间片（timeslice）后就处于 RUNNING（运行） 状态。

当线程执行 wait()方法之后，线程进入 WAITING（等待）状态。进入等待状态的线程需要依靠其他线程的通知才能够返回到运行状态，而 TIME_WAITING(超时等待) 状态相当于在等待状态的基础上增加了超时限制，比如通过 sleep（long millis）方法或 wait（long millis）方法可以将 Java 线程置于 TIMED WAITING 状态。当超时时间到达后 Java 线程将会返回到 RUNNABLE 状态。当线程调用同步方法时，在没有获取到锁的情况下，线程将会进入到 BLOCKED（阻塞） 状态。线程在执行 Runnable 的run()方法之后将会进入到 TERMINATED（终止） 状态。

一个线程运行时发生异常会怎样？

简单的说，如果异常没有被捕获该线程将会停止执行。Thread.UncaughtExceptionHandler是用于处理未捕获异常造成线程突然中断情况的一个内嵌接口。当一个未捕获异常将造成线程中断的时候JVM会使用Thread.getUncaughtExceptionHandler()来查询线程的UncaughtExceptionHandler并将线程和异常作为参数传递给handler的uncaughtException()方法进行处理。

Thread和Runnable区别

• Runnable的实现方式是实现其接口即可
• Thread的实现方式是继承其类
• Runnable接口支持多继承，但基本上用不到
• Thread实现了Runnable接口并进行了扩展，而Thread和Runnable的实质是实现的关系，不是同类东西，所以Runnable或Thread本身没有可比性。

CyclicBarrier和CountDownLatch的区别

两者本身作用都是设置栅栏，卡住线程。

CountDownLatch c = new CountDownLatch(3);
Thread里，c.await();
c.countDown()，到0的时候就可以执行了； 

CyclicBarrier c = new CyclicBarrier(3, Runnable);
Thread里，c.await();
c.await到个数了，就一起通过了，最后一个到的Thread会执行Runnable。

CountDownLatch： 一个或者多个线程，等待其他线程完成某件事情之后，等待其他多个线程完成某件事情之后才能执行；

CyclicBarrier： 多个线程互相等待，直到到达同一个同步点，再继续一起执行；

对于CountDownLatch来说，重点是一个线程（多个线程）等待”,而其他的N个线程在完成”某件事情“之后，可以终止，也可以等待，而对于CyclicBarrier，重点是多个线程，在任意一个线程没有完成，所有的线程都必须等待；

CountDownLatch是计数器，线程完成一个记录一个，只不过计数不是递增而是递减，而CyclicBarrier更像是一个阀门，需要所有线程都要到达，阀门才能打开，然后继续执行；

线程池

线程池的优势

• 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
• 提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
• 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

线程池的工作原理

4个参数的设计:

• 核心线程数(corePoolSize)
  核心线程数的设计需要依据任务的处理时间和每秒产生的任务数量来确定,例如:执行一个任务需要0.1秒,系统百分之80的时间每秒都会产生100个任务,那么要想在1秒内处理完这100个任务,就需要10个线程,此时我们就可以设计核心线程数为10;当然实际情况不可能这么平均,所以我们一般按照8020原则设计即可,既按照百分之80的情况设计核心线程数,剩下的百分之20可以利用最大线程数处理;
• 任务队列长度(workQueue)
  任务队列长度一般设计为:核心线程数/单个任务执行时间*2即可;例如上面的场景中,核心线程数设计为10,单个任务执行时间为0.1秒,则队列长度可以设计为200;
• 最大线程数(maximumPoolSize)
  最大线程数的设计除了需要参照核心线程数的条件外,还需要参照系统每秒产生的最大任务数决定:例如:上述环境中,如果系统每秒最大产生的任务是1000个,那么,最大线程数=(最大任务数-任务队列长度)*单个任务执行时间;既: 最大线程数=(1000-200)*0.1=80个;
• 最大空闲时间(keepAliveTime)
  这个参数的设计完全参考系统运行环境和硬件压力设定,没有固定的参考值,用户可以根据经验和系统产生任务的时间间隔合理设置一个值即可;

拒绝策略（handler）

当线程池的线程数达到最大线程数时，需要执行拒绝策略。拒绝策略需要实现RejectedExecutionHandler 接口，并实现 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法。不过 Executors 框架已经为我们实现了 4 种拒绝策略：

• AbortPolicy（默认）：丢弃任务并抛出 RejectedExecutionException 异常。
• CallerRunsPolicy：由调用线程处理该任务。
• DiscardPolicy：丢弃任务，但是不抛出异常。可以配合这种模式进行自定义的处理方式。
• DiscardOldestPolicy：丢弃队列最早的未处理任务，然后重新尝试执行任务。

功能线程池

其实Executors已经为我们封装好了 4 种常见的功能线程池，如下：

• 定长线程池（FixedThreadPool）
• 定时线程池（ScheduledThreadPool ）
• 可缓存线程池（CachedThreadPool）
• 单线程化线程池（SingleThreadExecutor）

弊端如下：

FixedThreadPool和SingleThreadExecutor：主要问题是堆积的请求处理队列均采用 LinkedBlockingQueue，可能会耗费非常大的内存，甚至 OOM。
CachedThreadPool和ScheduledThreadPool：主要问题是线程数最大数是 Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至 OOM。

---

间隙锁，点这里