1 线程基础、线程之间的共享和协作
1.1 基础概念
CPU核心数和线程数的关系
核心数:线程数=1:1 ;使用了超线程技术后---> 1:2
CPU时间片轮转机制
又称RR调度，会导致上下文切换
什么是进程和线程
进程：程序运行资源分配的最小单位，进程内部有多个线程，会共享这个进程的资源
线程：CPU调度的最小单位，必须依赖进程而存在。
澄清并行和并发
并行：同一时刻，可以同时处理事情的能力
并发：与单位时间相关，在单位时间内可以处理事情的能力
高并发编程的意义、好处和注意事项
好处：充分利用cpu的资源、加快用户响应的时间，程序模块化，异步化
问题：
线程共享资源，存在冲突；
容易导致死锁；
启用太多的线程，就有搞垮机器的可能
1.2 认识Java里的线程
新启线程的方式
三种
怎么样才能让Java里的线程安全停止工作呢
线程自然终止：自然执行完或抛出未处理异常
stop()，resume(),suspend()已不建议使用，stop()会导致线程不会正确释放资源，suspend()容易导致死锁。
java线程是协作式，而非抢占式
调用一个线程的interrupt() 方法中断一个线程，并不是强行关闭这个线程，只是跟这个线程打个招呼，将线程的中断标志位置为true，线程是否中断，由线程本身决定。
isInterrupted() 判定当前线程是否处于中断状态。
static方法interrupted() 判定当前线程是否处于中断状态，同时中断标志位改为false。
方法里如果抛出InterruptedException，线程的中断标志位会被复位成false，如果确实是需要中断线程，要求我们自己在catch语句块里再次调用interrupt()。
1.3 对Java里的线程再多一点点认识
线程常用方法和线程的状态
线程只有5种状态。整个生命周期就是这几种状态的切换。
run()和start() ：run方法就是普通对象的普通方法，只有调用了start()后，Java才会将线程对象和操作系统中实际的线程进行映射，再来执行run方法。
yield() ：让出cpu的执行权，将线程从运行转到可运行状态，但是下个时间片，该线程依然有可能被再次选中运行。
线程的优先级
取值为1~10，缺省为5，但线程的优先级不可靠，不建议作为线程开发时候的手段
守护线程
和主线程共死，finally不能保证一定执行
1.4 线程间的共享
synchronized内置锁
对象锁，锁的是类的对象实例。
类锁 ，锁的是每个类的的Class对象，每个类的的Class对象在一个虚拟机中只有一个，所以类锁也只有一个。
volatile关键字
适合于只有一个线程写，多个线程读的场景，因为它只能确保可见性。
ThreadLocal
线程变量。可以理解为是个map，类型 Map<Thread,Integer>
1.5 线程间协作
轮询：难以保证及时性，资源开销很大，
等待和通知
wait() 对象上的方法
notify/notifyAll 对象上的方法
等待和通知的标准范式
等待方：
1、 获取对象的锁；
2、 循环里判断条件是否满足，不满足调用wait方法，
3、 条件满足执行业务逻辑
通知方来说
1、 获取对象的锁；
2、 改变条件
3、 通知所有等待在对象的线程
notify和notifyAll应该用谁？
应该尽量使用notifyAll，使用notify因为有可能发生信号丢失的的情况
等待超时模式实现一个连接池
假设 等待时间时长为T，当前时间now+T以后超时
long overtime = now+T;
long remain = T;//等待的持续时间
while(result不满足条件&& remain>0){
wait(remain);
remain = overtime – now;//等待剩下的持续时间
}
return result;
join()方法
面试点
线程A，执行了线程B的join方法，线程A必须要等待B执行完成了以后，线程A才能继续自己的工作
调用yield() 、sleep()、wait()、notify()等方法对锁有何影响？
面试点
线程在执行yield()以后，持有的锁是不释放的
sleep()方法被调用以后，持有的锁是不释放的
调动方法之前，必须要持有锁。调用了wait()方法以后，锁就会被释放，当wait方法返回的时候，线程会重新持有锁
调动方法之前，必须要持有锁，调用notify()方法本身不会释放锁的
2 线程的并发工具类
2.1 Fork-Join
什么是分而治之？
规模为N的问题，N<阈值，直接解决，N>阈值，将N分解为K个小规模子问题，子问题互相对立，与原问题形式相同，将子问题的解合并得到原问题的解
动态规范
工作密取
workStealing
Fork/Join使用的标准范式
- RecursiveAction 是 ForkJoinTask 的一个子类，不需要返回值
- RecursiveTask: 是 ForkJoinTask 的一个子类，需要返回值
2.2 常用的并发工具类
CountDownLatch:
作用：是一组线程等待其他的线程完成工作以后在执行，加强版join
await用来等待，countDown负责计数器的减一
CyclicBarrier
让一组线程达到某个屏障，被阻塞，一直到组内最后一个线程达到屏障时，屏障开放，所有被阻塞的线程会继续运行CyclicBarrier(int parties)
CyclicBarrier(int parties, Runnable barrierAction)，屏障开放，barrierAction定义的任务会执行
CyclicBarrier有两个构造函数
public CyclicBarrier(int parties)
public CyclicBarrier(int parties, Runnable barrierAction)
第一个参数，表示那个一起执行的线程个数。
第二个参数，表示线程都处于barrier时，一起执行之前，先执行的一个线程。
让线程处于barrier状态的方法await()
public int await()
public int await(long timeout, TimeUnit unit)
第一个默认方法，表示要等到所有的线程都处于barrier状态，才一起执行
第二个方法，指定了等待的时间，当所有线程没有都处于barrier状态，又到了指定的时间，所在的线程就继续执行了。
CountDownLatch和CyclicBarrier辨析
1、countdownlatch放行由第三者控制，CyclicBarrier放行由一组线程本身控制
2、countdownlatch放行条件》=线程数，CyclicBarrier放行条件=线程数
Semaphore
控制同时访问某个特定资源的线程数量，用在流量控制
Semaphore 是 synchronized 的加强版，作用是控制线程的并发数量。
1. Semaphore semaphore = new Semaphore(1);// 同步关键类，构造方法传入的数字是多少，则同一个时刻，只运行多少个进程同时运行制定代码
2. semaphore.acquire()(获取一个许可数量)
3. semaphore.release()(释放一个许可数量)
4. 在 semaphore.acquire()和 semaphore.release()之间的代码，同一时刻只允许制定个数的线程进入，
Exchange
两个线程间的数据交换，
Callable、Future和FutureTask
isDone，结束，正常还是异常结束，或者自己取消，返回true；
isCancelled 任务完成前被取消，返回true；
cancel（boolean）：
1、 任务还没开始，返回false
2、 任务已经启动，cancel（true），中断正在运行的任务，中断成功，返回true，cancel（false），不会去中断已经运行的任务
3、 任务已经结束，返回false
包含图片和文字的文档的处理：图片（云上），可以用future去取图片，主线程继续解析文字。
3 原子操作CAS (Compare And Swap)
3.1 什么是CAS？
CAS：Compare and Swap，即比较再交换。
jdk5增加了并发包java.util.concurrent.*,其下面的类使用CAS算法实现了区别于synchronouse同步锁的一种乐观锁。JDK 5之前Java语言是靠synchronized关键字保证同步的，这是一种独占锁，也是是悲观锁。
3.2 什么是原子操作？如何实现原子操作？
syn基于阻塞的锁的机制，1、被阻塞的线程优先级很高，2、拿到锁的线程一直不释放锁怎么办？3、大量的竞争，消耗cpu，同时带来死锁或者其他安全。
CAS的原理
CAS(Compare And Swap)，指令级别保证这是一个原子操作
三个运算符： 一个内存地址V，一个期望的值A，一个新值B
基本思路：如果地址V上的值和期望的值A相等，就给地址V赋给新值B，如果不是，不做任何操作。
循环（死循环，自旋）里不断的进行CAS操作
CAS的问题
A---》B----》A，版本号: A1àB2-àA3
CAS操作长期不成功，cpu不断的循环，
3.3 Jdk中相关原子操作类的使用
AtomicMarkableReference，boolean 有没有动过
AtomicStampedReference 动过几次
Jdk中相关(13个)原子操作类的使用
- 1. 更新基本类型类：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference
- 2. 更新数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
- 3. 更新引用类型：AtomicReference，AtomicMarkableReference，AtomicStampedReference
- 4. 原子更新字段类：AtomicReferenceFieldUpdater，AtomicIntegerFieldUpdater，AtomicLongFieldUpdater
4 显式锁(Lock)
4.1 显式锁Lock
- 1. Lock 是 一个接口，提供了无条件的、可轮询的、定时的、可中断的的锁获取操作，所有加锁和解锁的方法都是显式的
- 2. Lock接口和核心方法
l lock()
l unlock()
l tryLock()
- 3. 实现类：
ReentrantLock(可重入锁) ,
ReentrantReadWriteLock((可重入读写锁[读多写少的情况下使用])
ReentrantReadWriteLock.ReadLock (可重入读锁),
ReentrantReadWriteLock.WriteLock (可重入写锁)
(WriteLock和ReadLock 类也分别实现了Lock接口)
注意：如需要互斥，则需要使用同一个ReentrantLock。不能将锁独立。
private final ReentrantLock lock = new ReentrantLock(); // 全局
- 4. Lock接口和synchronized的比较
（1）Lock 比较灵活，获取锁可以被中断，超时获取锁，尝试获取锁，但是必须有释放锁的动作配合。
（2）Lock必须手动开启锁和释放锁，而synchronized 不需要手动开启和释放锁。
（3）Lock只适用于代码块锁，而synchronized 对象之间的互斥关系。
（4）synchronized 代码简洁。
- 5. 常用方法及作用
1) getHoldCount() 查询当前线程保持锁定的个数，也就是调用lock()方法的次数。
2) getQueueLength() 返回正等待获取锁定的线程估计数。比如有5个线程，1个线程首先执行await()方法，那么在调用方法后返回值是4，说明有4个线程同时在等待lock的释放。
3) getWaitQueueLength(Condition con) 返回等待与此锁定相关的给定条件Condition的线程估计数。比如有5个线程，每个线程都执行了同一个Condition对象的await()方法，则调用此方法的返回值是。
4) hasQueuedThread(Thread thread) 查询指定的线程是否在等待获取此锁定。
5) hasQueuedThreads() 查询是否有线程正在等待获取此锁定。
6) hasWaiters(Condition con) 查询是否有线程正在等待与当前锁定有关的condition条件。
7) isFair() 判断是否是公平锁。
8) isHeldByCurrentThread() 查询当前线程是否保持此锁定
9) isLocked() 查询此锁定是否由任意线程保持。
10) lockInterruptibly() 如果当前线程未被中断，则获取锁定。如果已经中断则出现异常。
11) tryLock() 仅在调用时锁定未被另一个线程保持的情况下，才获取该锁定。
12) tryLock(long timout,TimeUnit unit) 如果锁定在给定等待时间内没有被另一个线程保持，且当前线程未被中断，则获取该锁定
- 6. 公平锁非公平锁概念
如果在时间上，先对锁进行获取的请求，一定先被满足，这个锁就是公平的，不满足，就是非公平的
非公平的效率一般来讲更高
ReadWriteLock接口和读写锁ReentrantReadWriteLock
ReentrantLock和Syn关键字，都是排他锁，
读写锁：同一时刻允许多个读线程同时访问，但是写线程访问的时候，所有的读和写都被阻塞，最适宜与读多写少的情况
- 7. Condition接口
a) Condition中的await()方法相当于Object的wait()方法，Condition中的signal()方法相当于Object的notify()方法，Condition中的signalAll()相当于Object的notifyAll()方法。不同的是，Object中的这些方法是和同步锁捆绑使用的；而Condition是需要与互斥锁/共享锁捆绑使用的。
b) Condition它更强大的地方在于：能够更加精细的控制多线程的休眠与唤醒。对于同一个锁，我们可以创建多个Condition，在不同的情况下使用不同的Condition。
4.2 了解LockSupport工具
park开头的方法
unpark(Thread thread)方法
5 AbstractQueuedSynchronizer深入分析
Java并发包（JUC）中提供了很多并发工具，这其中，很多我们耳熟能详的并发工具，譬如ReentrangLock、Semaphore，它们的实现都用到了一个共同的基类--AbstractQueuedSynchronizer,简称AQS。AQS是一个用来构建锁和同步器的框架，使用AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。当然，我们自己也能利用AQS非常轻松容易地构造出符合我们自己需求的同步器。
5.1 基本实现原理
AQS使用一个int成员变量来表示同步状态，通过内置的FIFO队列来完成获取资源线程的排队工作。
private volatile int state;//共享变量，使用volatile修饰保证线程可见性
当state = 1时表示已经获取了锁，
当state = 0时表示释放了锁。
状态信息通过procted类型的getState，setState，compareAndSetState进行操作
AQS支持两种同步方式：
1.独占式
2.共享式
独占式如ReentrantLock，共享式如Semaphore，CountDownLatch，组合式的如ReentrantReadWriteLock。总之，AQS为使用提供了底层支撑，如何组装实现，使用者可以自由发挥。
同步器的设计是基于模板方法模式的，一般的使用方式是这样：
1.使用者继承AbstractQueuedSynchronizer并重写指定的方法。（这些重写方法很简单，无非是对于共享资源state的获取和释放）
2.将AQS组合在自定义同步组件的实现中，并调用其模板方法，而这些模板方法会调用使用者重写的方法。
这其实是模板方法模式的一个很经典的应用。
我们来看看AQS定义的这些可重写的方法：
1) protected boolean tryAcquire(int arg) : 独占式获取同步状态，试着获取，成功返回true，反之为false
2) protected boolean tryRelease(int arg) ：独占式释放同步状态，等待中的其他线程此时将有机会获取到同步状态；
3) protected int tryAcquireShared(int arg) ：共享式获取同步状态，返回值大于等于0，代表获取成功；反之获取失败；
4) protected boolean tryReleaseShared(int arg) ：共享式释放同步状态，成功为true，失败为false
5) protected boolean isHeldExclusively() ： 是否在独占模式下被线程占用。
5.2 如何使用
首先，我们需要去继承AbstractQueuedSynchronizer这个类，然后我们根据我们的需求去重写相应的方法，比如要实现一个独占锁，那就去重写tryAcquire，tryRelease方法，要实现共享锁，就去重写tryAcquireShared，tryReleaseShared；最后，在我们的组件中调用AQS中的模板方法就可以了，而这些模板方法是会调用到我们之前重写的那些方法的。也就是说，我们只需要很小的工作量就可以实现自己的同步组件，重写的那些方法，仅仅是一些简单的对于共享资源state的获取和释放操作，至于像是获取资源失败，线程需要阻塞之类的操作，自然是AQS帮我们完成了。
5.3 原理分析
AQS的基本实现，AQS维护一个共享资源state，通过内置的FIFO（( First Input First Output)简单说就是指先进先出）来完成获取资源线程的排队工作。（这个内置的同步队列称为"CLH"队列）。该队列由一个一个的Node结点组成，每个Node结点维护一个prev引用和next引用，分别指向自己的前驱和后继结点。AQS维护两个指针，分别指向队列头部head和尾部tail。
其实就是个双端双向链表。
当线程获取资源失败（比如tryAcquire时试图设置state状态失败），会被构造成一个结点加入CLH队列中，同时当前线程会被阻塞在队列中（通过LockSupport.park实现，其实是等待态）。当持有同步状态的线程释放同步状态时，会唤醒后继结点，然后此结点线程继续加入到对同步状态的争夺中。
5.4 独占方式
获取同步状态--acquire()
来看看acquire方法，lock方法一般会直接代理到acquire上
- A. 首先，调用使用者重写的tryAcquire方法，若返回true，意味着获取同步状态成功，后面的逻辑不再执行；若返回false，也就是获取同步状态失败，进入b步骤；
- B. 此时，获取同步状态失败，构造独占式同步结点，通过addWatiter将此结点添加到同步队列的尾部（此时可能会有多个线程结点试图加入同步队列尾部，需要以线程安全的方 式添加）；
- C. 该结点以在队列中尝试获取同步状态，若获取不到，则阻塞结点线程，直到被前驱结点唤醒或者被中断。
addWaiter
为获取同步状态失败的线程，构造成一个Node结点，添加到同步队列尾部
先cas快速设置，若失败，进入enq方法
将结点添加到同步队列尾部这个操作，同时可能会有多个线程尝试添加到尾部，是非线程安全的操作。
以上代码可以看出，使用了compareAndSetTail这个cas操作保证安全添加尾结点。
enq方法
enq内部是个死循环，通过CAS设置尾结点，不成功就一直重试。很经典的CAS自旋的用法。这是一种乐观的并发策略。
最后，看下acquireQueued方法
acquireQueued
acquireQueued内部也是一个死循环，只有前驱结点是头结点的结点，也就是老二结点，才有机会去tryAcquire；若tryAcquire成功，表示获取同步状态成功，将此结点设置为头结点；若是非老二结点，或者tryAcquire失败，则进入shouldParkAfterFailedAcquire去判断判断当前线程是否应该阻塞，若可以，调用parkAndCheckInterrupt阻塞当前线程，直到被中断或者被前驱结点唤醒。若还不能休息，继续循环。
shouldParkAfterFailedAcquire
shouldParkAfterFailedAcquire用来判断当前结点线程是否能休息
若shouldParkAfterFailedAcquire返回true，也就是当前结点的前驱结点为SIGNAL状态，则意味着当前结点可以放心休息，进入parking状态了。parkAncCheckInterrupt阻塞线程并处理中断。
至此，关于acquire的方法源码已经分析完毕，我们来简单总结下
a.首先tryAcquire获取同步状态，成功则直接返回；否则，进入下一环节；
b.线程获取同步状态失败，就构造一个结点，加入同步队列中，这个过程要保证线程安全；
c.加入队列中的结点线程进入自旋状态，若是老二结点（即前驱结点为头结点），才有机会尝试去获取同步状态；否则，当其前驱结点的状态为SIGNAL，线程便可安心休息，进入阻塞状态，直到被中断或者被前驱结点唤醒。
释放同步状态--release()
当前线程执行完自己的逻辑之后，需要释放同步状态，来看看release方法的逻辑
unparkSuccessor:唤醒后继结点
release的同步状态相对简单，需要找到头结点的后继结点进行唤醒，若后继结点为空或处于CANCEL状态，从后向前遍历找寻一个正常的结点，唤醒其对应线程。
5.5 共享式
共享式：共享式地获取同步状态。对于独占式同步组件来讲，同一时刻只有一个线程能获取到同步状态，其他线程都得去排队等待，其待重写的尝试获取同步状态的方法tryAcquire返回值为boolean，这很容易理解；对于共享式同步组件来讲，同一时刻可以有多个线程同时获取到同步状态，这也是“共享”的意义所在。其待重写的尝试获取同步状态的方法tryAcquireShared返回值为int。
1.当返回值大于0时，表示获取同步状态成功，同时还有剩余同步状态可供其他线程获取；
2.当返回值等于0时，表示获取同步状态成功，但没有可用同步状态了；
3.当返回值小于0时，表示获取同步状态失败。
5.6 LockSupport了解
park开头的方法阻塞线程(aqs中阻塞用的就是这些方法)
unpark(Thread thread)方法,将线程恢复
5.7 Condition分析
使用方法:
所用方法必须先获取到锁才可以使用
keCond.await(); 添加到等待队列中等待,释放锁
keCond.signalAll(); 通知该队列上所有线程的阻塞方法
keCond.signal(); 通知该队列上一个线程阻塞方法
流程总结:
6 并发容器(ConcurrentHashMap)
6.1 线程不安全的HashMap
因为多线程环境下，使用Hashmap进行put操作会引起死循环，导致CPU利用率接近100%，所以在并发情况下不能使用HashMap。
6.2 效率低下的HashTable容器
HashTable容器使用synchronized来保证线程安全,共享同一个锁, 如线程1使用put进行添加元素，线程2不但不能使用put方法添加元素，并且也不能使用get方法来获取元素，所以竞争越激烈效率越低。
6.3 JDK 1.7 时的ConcurrentHashMap
6.3.1 锁分段技术
ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁。这里“按顺序”是很重要的，否则极有可能出现死锁，在ConcurrentHashMap内部，段数组是final的，并且其成员变量实际上也是final的，但是，仅仅是将数组声明为final的并不保证数组成员也是final的，这需要实现上的保证。这可以确保不会出现死锁，因为获得锁的顺序是固定的。
6.3.2 初始化做了什么事？
初始化有三个参数
initialCapacity：初始容量大小 ，默认16。
loadFactor, 扩容因子，默认0.75，当一个Segment存储的元素数量大于initialCapacity* loadFactor时，该Segment会进行一次扩容。
concurrencyLevel 并发度，默认16。并发度可以理解为程序运行时能够同时更新ConccurentHashMap且不产生锁竞争的最大线程数，实际上就是ConcurrentHashMap中的分段锁个数，即Segment[]的数组长度。如果并发度设置的过小，会带来严重的锁竞争问题；如果并发度设置的过大，原本位于同一个Segment内的访问会扩散到不同的Segment中，CPU cache命中率会下降，从而引起程序性能下降。
构造方法中部分代码解惑：
1、
保证Segment数组的大小，一定为2的幂，例如用户设置并发度为17，则实际Segment数组大小则为32
2、
保证每个Segment中tabel数组的大小，一定为2的幂，初始化的三个参数取默认值时，table数组大小为2
3、
初始化Segment数组，并实际只填充Segment数组的第0个元素。
4、
用于定位元素所在segment。segmentShift表示偏移位数，通过前面的int类型的位的描述我们可以得知，int类型的数字在变大的过程中，低位总是比高位先填满的，为保证元素在segment级别分布的尽量均匀，计算元素所在segment时，总是取hash值的高位进行计算。segmentMask作用就是为了利用位运算中取模的操作： a % (Math.pow(2,n)) 等价于 a&( Math.pow(2,n)-1)
6.4 JDK1.7ConcurrentHashMap
6.4.1 在get和put操作中，是如何快速定位元素放在哪个位置的？
对于某个元素而言，一定是放在某个segment元素的某个table元素中的，所以在定位上，
定位segment：取得key的hashcode值进行一次再散列（通过Wang/Jenkins算法），拿到再散列值后，以再散列值的高位进行取模得到当前元素在哪个segment上。
定位table：同样是取得key的再散列值以后，用再散列值的全部和table的长度进行取模，得到当前元素在table的哪个元素上。
6.4.2 get（）方法
定位segment和定位table后，依次扫描这个table元素下的的链表，要么找到元素，要么返回null。
在高并发下的情况下如何保证取得的元素是最新的？
答：用于存储键值对数据的HashEntry，在设计上它的成员变量value等都是volatile类型的，这样就保证别的线程对value值的修改，get方法可以马上看到。
6.4.3 put()方法
1、首先定位segment，当这个segment在map初始化后，还为null，由ensureSegment方法负责填充这个segment。
1、 对Segment 加锁
3、定位所在的table元素，并扫描table下的链表，找到时：
没有找到时：
6.4.4 扩容操作
Segment 不扩容，扩容下面的table数组，每次都是将数组翻倍
带来的好处
假设原来table长度为4，那么元素在table中的分布是这样的：
|
Hash值 |
15 |
23 |
34 |
56 |
77 |
|
在table中下标 |
3 = 15%4 |
3 = 23 % 4 |
2 = 34%4 |
0 = 56%4 |
1 = 77 % 4 |
扩容后table长度变为8，那么元素在table中的分布变成：
|
Hash值 |
56 |
34 |
77 |
15,23 |
||||
|
下标 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
可以看见 hash值为34和56的下标保持不变，而15,23,77的下标都是在原来下标的基础上+4即可，可以快速定位和减少重排次数。
Concurrenthashmap和hashmap扩容
- old），如果超过阀值，数组进行扩容。值得一提的是，Segment的扩容判断比HashMap更恰当，因为HashMap是在插入元素后判断元素是否已经到达容量的，如果到达了就进行扩容，但是很有可能扩容之后没有新元素插入，这时HashMap就进行了一次无效的扩容。
- Concurrenthashmap如何扩容。扩容的时候首先会创建一个两倍于原容量的数组，然后将原数组里的元素进行再hash后插入到新的数组里。为了高效ConcurrentHashMap不会对整个容器进行扩容，而只对某个segment进行扩容。
6.4.5 size方法
size的时候进行两次不加锁的统计，两次一致直接返回结果，不一致，重新加锁再次统计
6.4.6 弱一致性
get方法和containsKey方法都是通过对链表遍历判断是否存在key相同的节点以及获得该节点的value。但由于遍历过程中其他线程可能对链表结构做了调整，因此get和containsKey返回的可能是过时的数据，这一点是ConcurrentHashMap在弱一致性上的体现。
6.5 JDK 1.8 时的ConcurrentHashMap
6.5.1 与1.7相比的重大变化
1、 取消了segment数组，直接用table保存数据，锁的粒度更小，减少并发冲突的概率。
2、 存储数据时采用了链表+红黑树的形式，纯链表的形式时间复杂度为O(n)，红黑树则为O（logn），性能提升很大。什么时候链表转红黑树？当key值相等的元素形成的链表中元素个数超过8个的时候。
6.5.2 主要数据结构和关键变量
Node类存放实际的key和value值。
sizeCtl：
负数：表示进行初始化或者扩容,-1表示正在初始化，-N，表示有N-1个线程正在进行扩容
正数：0 表示还没有被初始化，>0的数，初始化或者是下一次进行扩容的阈值
TreeNode 用在红黑树，表示树的节点, TreeBin是实际放在table数组中的，代表了这个红黑树的根。
6.5.3 初始化做了什么事？
只是给成员变量赋值，put时进行实际数组的填充
6.5.4 在get和put操作中，是如何快速定位元素放在哪个位置的？
6.5.5 get（）方法
6.5.6 put()方法
数组的实际初始化
6.5.7 扩容操作
transfer()方法进行实际的扩容操作，table大小也是翻倍的形式，有一个并发扩容的机制。
6.5.8 size方法
估计的大概数量，不是精确数量
一致性
弱一致
7 更多的并发容器
7.1 ConcurrentSkipListMa和 ConcurrentSkipListSet
TreeMap和TreeSet有序的容器，这两种容器的并发版本
7.2 跳表
SkipList，以空间换时间，在原链表的基础上形成多层索引，但是某个节点在插入时，是否成为索引，随机决定，所以跳表又称为概率数据结构。
7.3 ConcurrentLinkedQueue
无界非阻塞队列，底层是个链表，遵循先进先出原则。
add,offer将元素插入到尾部，peek（拿头部的数据，但是不移除）和poll（拿头部的数据，但是移除）
7.4 写时复制容器 (CopyOnWriteArrayList,CopyOnWriteArraySet)
写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以写时复制容器也是一种读写分离的思想，读和写不同的容器。如果读的时候有多个线程正在向容器添加数据，读还是会读到旧的数据，因为写的时候不会锁住旧的，只能保证最终一致性。
适用读多写少的并发场景，常见应用：白名单/黑名单， 商品类目的访问和更新场景。
存在内存占用问题。
7.5 阻塞队列
7.5.1 概念、生产者消费者模式
1)当队列满的时候，插入元素的线程被阻塞，直达队列不满。
2)队列为空的时候，获取元素的线程被阻塞，直到队列不空。
7.5.2 生产者和消费者模式
生产者就是生产数据的线程，消费者就是消费数据的线程。在多线程开发中，如果生产者处理速度很快，而消费者处理速度很慢，那么生产者就必须等待消费者处理完，才能继续生产数据。同样的道理，如果消费者的处理能力大于生产者，那么消费者就必须等待生产者。为了解决这种生产消费能力不均衡的问题，便有了生产者和消费者模式。生产者和消费者模式是通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通信，而是通过阻塞队列来进行通信，所以生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列里取，阻塞队列就相当于一个缓冲区，平衡了生产者和消费者的处理能力。
7.6 常用方法
|
方法 |
抛出异常 |
返回值 |
一直阻塞 |
超时退出 |
|
插入方法 |
add |
offer |
put |
Offer(time) |
|
移除方法 |
remove |
poll |
take |
Poll(time) |
|
检查方法 |
element |
peek |
N/A |
N/A |
l 抛出异常：当队列满时，如果再往队列里插入元素，会抛出IllegalStateException（"Queuefull"）异常。当队列空时，从队列里获取元素会抛出NoSuchElementException异常。
l 返回特殊值：当往队列插入元素时，会返回元素是否插入成功，成功返回true。如果是移除方法，则是从队列里取出一个元素，如果没有则返回null。
l 一直阻塞：当阻塞队列满时，如果生产者线程往队列里put元素，队列会一直阻塞生产者线程，直到队列可用或者响应中断退出。当队列空时，如果消费者线程从队列里take元素，队列会阻塞住消费者线程，直到队列不为空。
l 超时退出：当阻塞队列满时，如果生产者线程往队列里插入元素，队列会阻塞生产者线程一段时间，如果超过了指定的时间，生产者线程就会退出。
7.7 常用阻塞队列
·ArrayBlockingQueue：一个由数组结构组成的有界阻塞队列。
按照先进先出原则，要求设定初始大小
·LinkedBlockingQueue：一个由链表结构组成的有界阻塞队列。
按照先进先出原则，可以不设定初始大小，Integer.Max_Value
ArrayBlockingQueue和LinkedBlockingQueue不同：
l 锁上面：ArrayBlockingQueue只有一个锁，LinkedBlockingQueue用了两个锁，
l 实现上：ArrayBlockingQueue直接插入元素，LinkedBlockingQueue需要转换。
·PriorityBlockingQueue：一个支持优先级排序的无界阻塞队列。
默认情况下，按照自然顺序，要么实现compareTo()方法，指定构造参数Comparator
·DelayQueue：一个使用优先级队列实现的无界阻塞队列。
支持延时获取的元素的阻塞队列，元素必须要实现Delayed接口。适用场景：实现自己的缓存系统，订单到期，限时支付等等。
·SynchronousQueue：一个不存储元素的阻塞队列。
每一个put操作都要等待一个take操作
·LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。
transfer()，必须要消费者消费了以后方法才会返回，tryTransfer()无论消费者是否接收，方法都立即返回。
·LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。
可以从队列的头和尾都可以插入和移除元素，实现工作密取，方法名带了First对头部操作，带了last从尾部操作，另外：add=addLast; remove=removeFirst; take=takeFirst
7.8 阻塞队列的实现原理
比如，ArrayBlockingQueue就是基于Lock和Condition实现的。
8 线程池
8.1 什么是线程池？为什么要用线程池？
1、 降低资源的消耗。降低线程创建和销毁的资源消耗；
2、 提高响应速度：线程的创建时间为T1，执行时间T2,销毁时间T3，免去T1和T3的时间
3、 提高线程的可管理性。
8.2 实现一个我们自己的线程池
1、 线程必须在池子已经创建好了，并且可以保持住，要有容器保存多个线程；
2、线程还要能够接受外部的任务，运行这个任务。容器保持这个来不及运行的任务.
8.3 JDK中的线程池和工作机制
8.3.1 线程池的创建
ThreadPoolExecutor，jdk所有线程池实现的父类
8.3.2 构造方法中各个参数含义
- 1. int corePoolSize ：线程池中核心线程数，< corePoolSize，就会创建新线程，= corePoolSize ，这个任务就会保存到BlockingQueue，如果调用prestartAllCoreThreads（）方法就会一次性的启动corePoolSize 个数的线程。
- 2. int maximumPoolSize, 允许的最大线程数，BlockingQueue也满了，且< maximumPoolSize时候就会再次创建新的线程
- 3. long keepAliveTime, 线程空闲下来后，存活的时间，这个参数只在> corePoolSize才有用
- 4. TimeUnit unit, 存活时间的单位值
- 5. BlockingQueue<Runnable> workQueue, 保存任务的阻塞队列
- 6. ThreadFactory threadFactory, 创建线程的工厂，给新建的线程赋予名字
- 7. RejectedExecutionHandler handler ：饱和策略
7.1 AbortPolicy ：直接抛出异常，默认；
7.2 CallerRunsPolicy：用调用者所在的线程来执行任务
7.3 DiscardOldestPolicy：丢弃阻塞队列里最老的任务，队列里最靠前的任务
7.4 DiscardPolicy ：当前任务直接丢弃,实现自己的饱和策略，实现RejectedExecutionHandler接口即可
8.3.3 提交任务
execute(Runnable command) 不需要返回
Future<T> submit(Callable<T> task) 需要返回
8.3.4 关闭线程池
shutdown(),shutdownNow();
shutdownNow():设置线程池的状态，还会尝试停止正在运行或者暂停任务的线程
shutdown()设置线程池的状态，只会中断所有没有执行任务的线程
8.3.5 工作机制
8.4 合理配置线程池
根据任务的性质来：计算密集型（CPU），IO密集型，混合型
计算密集型：加密，大数分解，正则…….， 线程数适当小一点，最大推荐：机器的Cpu核心数+1，为什么+1，防止页缺失，(机器的Cpu核心=Runtime.getRuntime().availableProcessors();)
IO密集型：读取文件，数据库连接，网络通讯, 线程数适当大一点，机器的Cpu核心数*2,
混合型：尽量拆分，IO密集型>>计算密集型，拆分意义不大，IO密集型~计算密集型
队列的选择上，应该使用有界，无界队列可能会导致内存溢出，OOM
8.5 预定义的线程池
8.5.1 FixedThreadPool
创建固定线程数量的，适用于负载较重的服务器，使用了无界队列
8.5.2 SingleThreadExecutor
创建单个线程，需要顺序保证执行任务，不会有多个线程活动，使用了无界队列
8.5.3 CachedThreadPool
会根据需要来创建新线程的，执行很多短期异步任务的程序，使用了SynchronousQueue
8.5.4 WorkStealingPool（JDK7以后）
基于ForkJoinPool实现
8.5.5 ScheduledThreadPoolExecutor
需要定期执行周期任务，Timer不建议使用了。
newSingleThreadScheduledExecutor：只包含一个线程，只需要单个线程执行周期任务，保证顺序的执行各个任务
newScheduledThreadPool 可以包含多个线程的，线程执行周期任务，适度控制后台线程数量的时候
方法说明：
schedule：只执行一次，任务还可以延时执行
scheduleAtFixedRate：提交固定时间间隔的任务
scheduleWithFixedDelay：提交固定延时间隔执行的任务
两者的区别：
scheduleAtFixedRate任务超时：
规定60s执行一次，有任务执行了80S，下个任务马上开始执行
第一个任务 时长 80s，第二个任务20s，第三个任务 50s
第一个任务第0秒开始，第80S结束；
第二个任务第80s开始，在第100秒结束；
第三个任务第120s秒开始，170秒结束
第四个任务从180s开始
参加代码：ScheduleWorkerTime类，执行效果如图：
建议在提交给ScheduledThreadPoolExecutor的任务要住catch异常。
8.6 Executor框架
了解CompletionService
9 并发安全
9.1 类的线程安全定义
a) 如果多线程下使用这个类，不过多线程如何使用和调度这个类，这个类总是表示出正确的行为，这个类就是线程安全的。
b) 类的线程安全表现为：
l 操作的原子性
l 内存的可见性
不做正确的同步，在多个线程之间共享状态的时候，就会出现线程不安全。
9.2 怎么才能做到类的线程安全？
9.2.1 栈封闭
所有的变量都是在方法内部声明的，这些变量都处于栈封闭状态。
9.2.2 无状态
没有任何成员变量的类，就叫无状态的类
9.2.3 让类不可变
让状态不可变，两种方式：
1，加final关键字，对于一个类，所有的成员变量应该是私有的，同样的只要有可能，所有的成员变量应该加上final关键字，但是加上final，要注意如果成员变量又是一个对象时，这个对象所对应的类也要是不可变，才能保证整个类是不可变的。
2、根本就不提供任何可供修改成员变量的地方，同时成员变量也不作为方法的返回值
9.2.4 volatile
保证类的可见性，最适合一个线程写，多个线程读的情景，
9.2.5 加锁和CAS
9.2.6 安全的发布
类中持有的成员变量，特别是对象的引用，如果这个成员对象不是线程安全的，通过get等方法发布出去，会造成这个成员对象本身持有的数据在多线程下不正确的修改，从而造成整个类线程不安全的问题。
9.2.7 TheadLocal
9.3 关于Servlet（生命周期；是否安全）
9.3.1 不是线程安全的类。
为什么我们平时没感觉到：
- 1）在需求上（http请求），很少有共享的需求
- 2）接收到了请求，返回应答的时候，都是由一个线程来负责的
9.4 线程不安全引发的问题
9.4.1 死锁
资源一定是多于1个，同时小于等于竞争的线程数，资源只有一个，只会产生激烈的竞争。
死锁的根本成因：获取锁的顺序不一致导致。
9.4.1.1 检查死锁方法：
- 通过jps 查询进程 id
- 再通过jstack id 查看应用的锁的持有情况
怀疑发送死锁：
通过jps 查询应用的 id，
再通过jstack id 查看应用的锁的持有情况
解决办法：保证加锁的顺序性
9.4.1.2 动态的
动态顺序死锁，在实现时按照某种顺序加锁了，但是因为外部调用的问题，导致无法保证加锁顺序而产生的。
解决：
1、 通过内在排序，保证加锁的顺序性
2、 通过尝试拿锁，也可以。
9.4.2 活锁
尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生拿锁，释放锁的过程。
没有那个随机休眠，就会产生不同程度的活锁！
解决办法：每个线程休眠随机数，错开拿锁的时间
9.4.3 线程饥饿
低优先级的线程，总是拿不到执行时间
9.5 性能和思考
9.5.1 衡量指标
使用并发的目标是为了提高性能，引入多线程后，其实会引入额外的开销，如线程之间的协调、增加的上下文切换，线程的创建和销毁，线程的调度等等。过度的使用和不恰当的使用，会导致多线程程序甚至比单线程还要低。
衡量应用的程序的性能：服务时间，延迟时间，吞吐量，可伸缩性等等，其中服务时间，延迟时间（多快），吞吐量（处理能力的指标，完成工作的多少）。多
我们做应用的时候：
1、先保证程序正确，确实达不到要求的时候，再提高速度。（黄金原则）
2、一定要以测试为基准。
9.5.2 影响性能的因素
- A. 上下文切换（合理分配线程数）
- B. 内存同步（减少锁的竞争）
- C. 阻塞（减少锁的竞争）
9.5.3 提高性能的方法
9.5.3.1 减少锁的竞争
9.5.3.2 减少锁的粒度
使用锁的时候，锁所保护的对象是多个，当这些多个对象其实是独立变化的时候，不如用多个锁来一一保护这些对象。但是如果有同时要持有多个锁的业务方法，要注意避免发生死锁
9.5.3.3 缩小锁的范围
对锁的持有实现快进快出，尽量缩短持由锁的的时间。将一些与锁无关的代码移出锁的范围，特别是一些耗时，可能阻塞的操作
9.5.3.4 避免多余的缩减锁的范围
两次加锁之间的语句非常简单，导致加锁的时间比执行这些语句还长，这个时候应该进行锁粗化—扩大锁的范围。
9.5.3.5 锁分段
ConcurrrentHashMap就是典型的锁分段。
缺点：访问整个容器比较麻烦。
9.5.3.6 替换独占锁
在业务允许的情况下：
- 1） 使用读写锁
- 2）用自旋CAS
- 3） 使用系统的并发容器