并发

https://www.jianshu.com/p/6456af2a7c5d

1、锁的分类

自旋锁： 线程状态及上下文切换消耗系统资源，当访问共享资源的时间短，频繁上下文切换不值得。jvm实现，使线程在没获得锁的时候，不被挂起，转而执行空循环，循环几次之后，如果还没能获得锁，则被挂起
阻塞锁：阻塞锁改变了线程的运行状态，让线程进入阻塞状态进行等待，当获得相应的信号（唤醒或者时间）时，才可以进入线程的准备就绪状态，转为就绪状态的所有线程，通过竞争，进入运行状态
重入锁:支持线程再次进入的锁,就跟我们有房间钥匙，可以多次进入房间类似
读写锁： 两把锁，读锁跟写锁，写写互斥、读写互斥、读读共享
互斥锁： 上厕所，进门之后就把门关了，不让其他人进来
悲观锁： 总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁
乐观锁：每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。
公平锁：大家都老老实实排队，对大家而言都很公平
非公平锁：一部分人排着队，但是新来的可能插队。可能导致后面排队等待的线程等不到相应的cpu资源，从而引起线程饥饿
偏向锁：偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁
独占锁：独占锁模式下，每次只能有一个线程能持有锁
共享锁：允许多个线程同时获取锁，并发访问共享资源

2、深入理解Lock接口

Lock的使用
lock与synchronized的区别
lock
获取锁与释放锁的过程，都需要程序员手动的控制
Lock用的是乐观锁方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。乐观锁实现的机制就 是CAS操作
synchronized托管给jvm执行
原始采用的是CPU悲观锁机制，即线程获得的是独占锁。独占锁意味着其他线程只能依靠阻塞来等待线程释放锁。

3、AbstractQueuedSynchronizer浅析

AbstractQueuedSynchronizer -- 为实现依赖于先进先出 (FIFO) 等待队列的阻塞锁和相关同步器（信号量、事件，等等）提供一个框架。
此类的设计目标是成为依靠单个原子 int 值来表示状态的大多数同步器的一个有用基础。
子类必须定义更改此状态的受保护方法，并定义哪种状态对于此对象意味着被获取或被释放。
假定这些条件之后，此类中的其他方法就可以实现所有排队和阻塞机制。子类可以维护其他状态字段，但只是为了获得同步而只追踪使用 getState()、setState(int) 和 compareAndSetState(int, int) 方法来操作以原子方式更新的 int 值。
应该将子类定义为非公共内部帮助器类，可用它们来实现其封闭类的同步属性。类 AbstractQueuedSynchronizer 没有实现任何同步接口。而是定义了诸如 acquireInterruptibly(int) 之类的一些方法，在适当的时候可以通过具体的锁和相关同步器来调用它们，以实现其公共方法。
此类支持默认的独占 模式和共享 模式之一，或者二者都支持。处于独占模式下时，其他线程试图获取该锁将无法取得成功。在共享模式下，多个线程获取某个锁可能（但不是一定）会获得成功。此类并不“了解”这些不同，除了机械地意识到当在共享模式下成功获取某一锁时，下一个等待线程（如果存在）也必须确定自己是否可以成功获取该锁。处于不同模式下的等待线程可以共享相同的 FIFO 队列。通常，实现子类只支持其中一种模式，但两种模式都可以在（例如）ReadWriteLock 中发挥作用。只支持独占模式或者只支持共享模式的子类不必定义支持未使用模式的方法。
此类通过支持独占模式的子类定义了一个嵌套的 AbstractQueuedSynchronizer.ConditionObject 类，可以将这个类用作 Condition 实现。isHeldExclusively() 方法将报告同步对于当前线程是否是独占的；使用当前 getState() 值调用 release(int) 方法则可以完全释放此对象；如果给定保存的状态值，那么 acquire(int) 方法可以将此对象最终恢复为它以前获取的状态。没有别的 AbstractQueuedSynchronizer 方法创建这样的条件，因此，如果无法满足此约束，则不要使用它。AbstractQueuedSynchronizer.ConditionObject 的行为当然取决于其同步器实现的语义。
此类为内部队列提供了检查、检测和监视方法，还为 condition 对象提供了类似方法。可以根据需要使用用于其同步机制的 AbstractQueuedSynchronizer 将这些方法导出到类中。
此类的序列化只存储维护状态的基础原子整数，因此已序列化的对象拥有空的线程队列。需要可序列化的典型子类将定义一个 readObject 方法，该方法在反序列化时将此对象恢复到某个已知初始状态。

4、读写锁特性

特性：写写互斥、读写互斥、读读共享
锁降级：写线程获取写入锁后可以获取读取锁，然后释放写入锁，这样就从写入锁变成了读取锁，从而实现锁降级的特性。

5、锁降级详解

锁降级：写线程获取写入锁后可以获取读取锁，然后释放写入锁，这样就从写入锁变成了读取锁，从而实现锁降级的特性。
注意点：锁降级之后，写锁并不会直接降级成读锁，不会随着读锁的释放而释放，因此需要显式地释放写锁
是否有锁升级？
在ReentrantReadWriteLock里面，不存在锁升级这一说法
锁降级的应用场景
用于对数据比较敏感，需要在对数据修改之后，获取到修改后的值，并进行接下来的其他操作

6、StampedLock原理及使用

1.8之前，锁已经那么多了，为什么还要有StampedLock？
一般应用，都是读多写少，ReentrantReadWriteLock 因读写互斥，故读时阻塞写，因而性能上上不去。可能会使写线程饥饿
StampedLock的特点
所有获取锁的方法，都返回一个邮戳（Stamp），Stamp为0表示获取失败，其余都表示成功；
所有释放锁的方法，都需要一个邮戳（Stamp），这个Stamp必须是和成功获取锁时得到的Stamp一致；
StampedLock是不可重入的；（如果一个线程已经持有了写锁，再去获取写锁的话就会造成死锁）
支持锁升级跟锁降级
可以乐观读也可以悲观读
使用有限次自旋，增加锁获得的几率，避免上下文切换带来的开销
乐观读不阻塞写操作，悲观读，阻塞写得操作

StampedLock的优点
相比于ReentrantReadWriteLock，吞吐量大幅提升
StampedLock的缺点
api相对复杂，容易用错
内部实现相比于ReentrantReadWriteLock复杂得多

StampedLock的原理
每次获取锁的时候，都会返回一个邮戳（stamp），相当于mysql里的version字段
释放锁的时候，再根据之前的获得的邮戳，去进行锁释放
使用stampedLock注意点
如果使用乐观读，一定要判断返回的邮戳是否是一开始获得到的，如果不是，要去获取悲观读锁，再次去读取

---

---

---

线程间的通信

1、 wait、notify、notifyAll

何时使用
在多线程环境下，有时候一个线程的执行，依赖于另外一个线程的某种状态的改变，这个时候，我们就可以使用wait与notify或者notifyAll
wait跟sleep的区别
wait会释放持有的锁，而sleep不会，sleep只是让线程在指定的时间内，不去抢占cpu的资源
注意点
wait notify必须放在同步代码块中, 且必须拥有当前对象的锁，即不能取得A对象的锁，而调用B对象的wait
哪个对象wait，就得调哪个对象的notify
notify跟notifyAll的区别
nofity随机唤醒一个等待的线程
notifyAll唤醒所有在该对象上等待的线程

2、Thread.join通信

使用场景：线程A执行到一半，需要一个数据，这个数据需要线程B去执行修改，只有B修改完成之后，A才能继续操作
线程A的run方法里面，调用线程B的join方法，这个时候，线程A会等待线程B运行完成之后，再接着运行

ThreadLocal的使用

线程变量，是一个以ThreadLocal对象为键、任意对象为值的存储结构。为每个线程单独存放一份变量副本，也就是说一个线程可以根据一个ThreadLocal对象查询到绑定在这个线程上的一个值。
只要线程处于活动状态并且ThreadLocal实例可访问，那么每个线程都拥有对其本地线程副本的隐式引用变量一个线程消失后，它的所有副本线程局部实例受垃圾回收（除非其他存在对这些副本的引用）
一般用的比较多的是
1、ThreadLocal.get: 获取ThreadLocal中当前线程共享变量的值。
2、ThreadLocal.set: 设置ThreadLocal中当前线程共享变量的值。
3、ThreadLocal.remove: 移除ThreadLocal中当前线程共享变量的值。
4、ThreadLocal.initialValue: ThreadLocal没有被当前线程赋值时或当前线程刚调用remove方法后调用get方法，返回此方法值。

Condition的使用

可以在一个锁里面，存在多种等待条件
主要的方法
await
signal
signalAll

原子类

1、 什么是原子类

一度认为原子是不可分割的最小单位，故原子类可以认为其操作都是不可分割

2、 为什么要有原子类？

对多线程访问同一个变量，我们需要加锁，而锁是比较消耗性能的，JDk1.5之后，新增的原子操作类提供了一种用法简单、性能高效、线程安全地更新一个变量的方式，这些类同样位于JUC包下的atomic包下，发展到JDk1.8，该包下共有17个类，囊括了原子更新基本类型、原子更新数组、原子更新属性、原子更新引用

3、1.8新增的原子类

DoubleAccumulator、DoubleAdder、LongAccumulator、LongAdder、Striped64

4、原子更新基本类型

发展至JDk1.8，基本类型原子类有以下几个：
AtomicBoolean、AtomicInteger、AtomicLong、DoubleAccumulator、DoubleAdder、LongAccumulator、LongAdder
大致可以归为3类
AtomicBoolean、AtomicInteger、AtomicLong 元老级的原子更新，方法几乎一模一样
DoubleAdder、LongAdder 对Double、Long的原子更新性能进行优化提升
DoubleAccumulator、LongAccumulator 支持自定义运算

5、原子更新数组类型

AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray

6、原子地更新属性

原子地更新某个类里的某个字段时，就需要使用原子更新字段类，Atomic包提供了以下4个类进行原子字段更新
AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicStampedReference、AtomicReferenceFieldUpdater
使用上述类的时候，必须遵循以下原则
字段必须是volatile类型的，在线程之间共享变量时保证立即可见
字段的描述类型是与调用者与操作对象字段的关系一致。
也就是说调用者能够直接操作对象字段，那么就可以反射进行原子操作。
对于父类的字段，子类是不能直接操作的，尽管子类可以访问父类的字段。
只能是实例变量，不能是类变量，也就是说不能加static关键字。
只能是可修改变量，不能使final变量，因为final的语义就是不可修改。
对于AtomicIntegerFieldUpdater和AtomicLongFieldUpdater只能修改int/long类型的字段，不能修改其包装类型（Integer/Long）。
如果要修改包装类型就需要使用AtomicReferenceFieldUpdater。

7、原子更新引用

AtomicReference：用于对引用的原子更新
AtomicMarkableReference：带版本戳的原子引用类型，版本戳为boolean类型。
AtomicStampedReference：带版本戳的原子引用类型，版本戳为int类型。

容器

1、同步容器与并发容器

同步容器
Vector、HashTable -- JDK提供的同步容器类
Collections.synchronizedXXX 本质是对相应的容器进行包装
同步容器类的缺点
在单独使用里面的方法的时候，可以保证线程安全，但是，复合操作需要额外加锁来保证线程安全，使用Iterator迭代容器或使用使用for-each遍历容器，在迭代过程中修改容器会抛出ConcurrentModificationException异常。想要避免出现ConcurrentModificationException，就必须在迭代过程持有容器的锁。但是若容器较大，则迭代的时间也会较长。那么需要访问该容器的其他线程将会长时间等待。从而会极大降低性能。
若不希望在迭代期间对容器加锁，可以使用"克隆"容器的方式。使用线程封闭，由于其他线程不会对容器进行修改，可以避免ConcurrentModificationException。但是在创建副本的时候，存在较大性能开销。
toString，hashCode，equalse，containsAll，removeAll，retainAll等方法都会隐式的Iterate，也即可能抛出ConcurrentModificationException。

2、并发容器

CopyOnWrite、Concurrent、BlockingQueue
根据具体场景进行设计，尽量避免使用锁，提高容器的并发访问性。
ConcurrentBlockingQueue：基于queue实现的FIFO的队列。队列为空，取操作会被阻塞
ConcurrentLinkedQueue，队列为空，取得时候就直接返回空

LinkedBlockingQueue的使用
在并发编程中，LinkedBlockingQueue使用的非常频繁。因其可以作为生产者消费者的中间商
add 实际上调用的是offer，区别是在队列满的时候，add会报异常
offer 对列如果满了，直接入队失败
put("111"); 在队列满的时候，会进入阻塞的状态

remove(); 直接调用poll，唯一的区别即使remove会抛出异常，而poll在队列为空的时候直接返回null
poll(); 在队列为空的时候直接返回null
take(); 在队列为空的时候，会进入等待的状态

并发工具类

CountDownLatch
await(),进入等待的状态
countDown(),计数器减一
应用场景：启动三个线程计算，需要对结果进行累加。

CyclicBarrier--栅栏
允许一组线程相互等待达到一个公共的障碍点，之后再继续执行

跟countDownLatch的区别
CountDownLatch一般用于某个线程等待若干个其他线程执行完任务之后，它才执行；不可重复使用
CyclicBarrier一般用于一组线程互相等待至某个状态，然后这一组线程再同时执行；可重用的

Semaphore--信号量
控制并发数量
使用场景：接口限流

Exchanger
用于交换数据
它提供一个同步点，在这个同步点两个线程可以交换彼此的数据。这两个线程通过exchange方法交换数据， 如果第一个线程先执行exchange方法，它会一直等待第二个线程也执行exchange，当两个线程都到达同步点时，这两个线程就可以交换数据，将本线程生产出来的数据传递给对方。因此使用Exchanger的重点是成对的线程使用exchange()方法，当有一对线程达到了同步点，就会进行交换数据。因此该工具类的线程对象是【成对】的。

线程池及Executor框架

1、 为什么要使用线程池？

诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器，这种方式可能是通过网络协议（例如 HTTP、FTP ）、通过 JMS队列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常出现的情况是：单个任务处理的时间很短而请求的数目却是巨大的。每当一个请求到达就创建一个新线程，然后在新线程中为请求服务，但是频繁的创建线程，销毁线程所带来的系统开销其实是非常大的。
线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建的开销被分摊到了多个任务上。其好处是，因为在请求到达时线程已经存在，所以无意中也消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使应用程序响应更快。而且，通过适当地调整线程池中的线程数目，也就是当请求的数目超过某个阈值时，就强制其它任何新到的请求一直等待，直到获得一个线程来处理为止，从而可以防止资源不足。

风险与机遇
用线程池构建的应用程序容易遭受任何其它多线程应用程序容易遭受的所有并发风险，
诸如同步错误和死锁，它还容易遭受特定于线程池的少数其它风险，诸如与池有关的死锁、资源不足和线程泄漏。

Future与Callable、FutureTask
Callable与Runable功能相似，Callable的call有返回值，可以返回给客户端，而Runable没有返回值，一般情况下，Callable与FutureTask一起使用，或者通过线程池的submit方法返回相应的Future
Future就是对于具体的Runnable或者Callable任务的执行结果进行取消、查询是否完成、获取结果、设置结果操作。get方法会阻塞，直到任务返回结果
FutureTask则是一个RunnableFuture，而RunnableFuture实现了Runnbale又实现了Futrue这两个接口

线程池的核心组成部分及其运行机制
corePoolSize：核心线程池大小 cSize
maximumPoolSize：线程池最大容量 mSize
keepAliveTime：当线程数量大于核心时，多余的空闲线程在终止之前等待新任务的最大时间。
unit：时间单位
workQueue:工作队列 nWorks
ThreadFactory：线程工厂
handler：拒绝策略

运行机制
通过new创建线程池时，除非调用prestartAllCoreThreads方法初始化核心线程，否则此时线程池中有0个线程，即使工作队列中存在多个任务，同样不会执行

任务数X
x <= cSize 只启动x个线程
x >= cSize && x < nWorks + cSize 会启动 <= cSize 个线程 其他的任务就放到工作队列里
x > cSize && x > nWorks + cSize
x-(nWorks) <= mSize 会启动x-(nWorks)个线程
x-(nWorks) > mSize 会启动mSize个线程来执行任务，其余的执行相应的拒绝策略

5 线程池拒绝策略
AbortPolicy：该策略直接抛出异常，阻止系统正常工作
CallerRunsPolicy：只要线程池没有关闭，该策略直接在调用者线程中，执行当前被丢弃的任务（叫老板帮你干活）
DiscardPolicy：直接啥事都不干，直接把任务丢弃
DiscardOldestPolicy：丢弃最老的一个请求（任务队列里面的第一个），再尝试提交任务

6 Executor框架
通过相应的方法，能创建出6种线程池
ExecutorService executorService = Executors.newCachedThreadPool();
ExecutorService executorService1 = Executors.newFixedThreadPool(2);
ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);
ExecutorService executorService2 = Executors.newWorkStealingPool();
ExecutorService executorService3 = Executors.newSingleThreadExecutor();
ScheduledExecutorService scheduledExecutorService1 = Executors.newSingleThreadScheduledExecutor();

上面的方法最终都创建了ThreadPoolExecutor
newCachedThreadPool：创建一个可以根据需要创建新线程的线程池，如果有空闲线程，优先使用空闲的线程
newFixedThreadPool：创建一个固定大小的线程池，在任何时候，最多只有N个线程在处理任务
newScheduledThreadPool：能延迟执行、定时执行的线程池
newWorkStealingPool：工作窃取，使用多个队列来减少竞争
newSingleThreadExecutor：单一线程的线程次，只会使用唯一一个线程来执行任务，即使提交再多的任务，也都是会放到等待队列里进行等待
newSingleThreadScheduledExecutor：单线程能延迟执行、定时执行的线程池

线程池的使用建议

尽量避免使用Executor框架创建线程池
newFixedThreadPool newSingleThreadExecutor
允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。
newCachedThreadPool newScheduledThreadPool
允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM

为什么第二个例子，在限定了堆的内存之后，还会把整个电脑的内存撑爆
创建线程时用的内存并不是我们制定jvm堆内存，而是系统的剩余内存。（电脑内存-系统其它程序占用的内存-已预留的jvm内存）

创建线程池时，核心线程数不要过大
相应的逻辑，发生异常时要处理
submit 如果发生异常，不会立即抛出，而是在get的时候，再抛出异常
execute 直接抛出异常

实战

1 数据同步接口--需求分析
业务场景：
一般系统，多数会与第三方系统的数据打交道，而第三方的生产库，并不允许我们直接操作。在企业里面，一般都是通过中间表进行同步，即第三方系统将生产数据放入一张与其生产环境隔离的另一个独立的库中的独立的表，再根据接口协议，增加相应的字段。而我方需要读取该中间表中的数据，并对数据进行同步操作。此时就需要编写相应的程序进行数据同步。
数据同步一般分两种情况
全量同步：每天定时将当天的生产数据全部同步过来（优点：实现简单 缺点：数据同步不及时）
增量同步：每新增一条，便将该数据同步过来（优点：数据近实时同步 缺点：实现相对困难）

我方需要做的事情：
读取中间表的数据，并同步到业务系统中（可能需要调用我方相应的业务逻辑）
模型抽离
生产者消费者模型
生产者：读取中间表的数据
消费者：消费生产者生产的数据

接口协议的制定
1.取我方业务所需要的字段
2.需要有字段记录数据什么时候进入中间表
3.增加相应的数据标志位，用于标志数据的同步状态
4.记录数据的同步时间

技术选型：
mybatis、单一生产者多消费者、多线程并发操作

2 中间表设计

3 基础环境搭建

4 生产者代码实现
1：分批读取中间表（10I），并将读取到的数据状态修改为10D（处理中）
2：将相应的数据交付给消费者进行消费
把生产完的数据，直接放到队列里，由消费者去进行消费
*把消费者放到队列里面，生产完数据，直接从队列里拿出消费者进行消费