并发编程精要-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_36906802/article/details/97609812

1 基本概念

1.1 并发

同时拥有两个或者多个线程，如果程序在单核处理器上运行多个线程将交替地换入或者换出内存,这些线程是同时“存在"的，每个线程都处于执行过程中的某个状态，如果运行在多核处理器上,此时，程序中的每个线程都将分配到一个处理器核上，因此可以同时运行.

1.2 高并发( High Concurrency)

通常是指，通过设计保证系统能够同时并行处理很多请求.

1.3 区别与联系

并发: 多个线程操作相同的资源，保证线程安全，合理使用资源
高并发:服务能同时处理很多请求，提高程序性能

并发安全代码演示：

public class CountDownLatchExample1 {

// 模拟并发2000

private final static int threadCount = 2000;

// 模拟有100000个请求

private final static int threadClient = 100000;

// 计数器(资源)

private static int count=0;

public static void main(String[] args) throws InterruptedException {

// 线程池

ExecutorService executor = Executors.newCachedThreadPool();

// 信号量，用于模拟并发

final Semaphore semaphore = new Semaphore(threadCount);

for (int i = 0; i < threadClient; i++) {

executor.execute(new Runnable() {

public void run() {

try {

// 获取一个资源

semaphore.acquire();

add();

// 释放一个资源

semaphore.release();

} catch (InterruptedException e) {

e.printStackTrace();

}

});

}

executor.shutdown();

System.out.println(count);

}

// 加了同步关键字的方法，如果不加同步则最终会因为并发问题导致结果不固定

public synchronized static void add(){

count++;

}

JMM规定的八种操作以及同步规则

lock	将主内存中的变量锁定，标记为一个线程所独占
unclock	将主内存中之前lock的变量解除锁定，此时其它的线程可以有机会访问此变量
read	将主内存中的变量值读到工作内存当中
load	将read读取的值保存到工作内存中的变量副本中。
use	将工作内存中的值传递给线程的代码执行引擎
assign	将执行引擎处理返回的值重新赋值给工作内存中的变量副本
store	将工作内存中变量副本的值存储到主内存中。
write	将store存储的值写入到主内存的共享变量当中。

并发的优势与风险

优势：

a、处理速度，比如同时处理多个请求或者大任务拆分成小任务进行并行处理

b、提高资源利用率，CPU可以在等待IO(磁盘、网络等)的时候去操作别的事情，充分发挥多核处理性能

风险:

a、安全性，主要体现在多个线程操作共享资源，没有合理使用加锁，则会造成未知结果

b、活跃性，某个线程无法继续执行下去时就容易产生该问题，例如多个线程竞争资源可能会造成死锁问题，或者由于编码不当导致死锁

c、性能，过多的线程会造成CPU频繁调度，返回会降低处理效率，而且线程过多会消耗更多的内存，因此要合理使用线程，比如使用线程池

守护线程：

在Java中有两类线程：用户线程 (User Thread)、守护线程 (Daemon Thread)。
守护线程和用户线程的区别在于：守护线程依赖于创建它的线程，而用户线程则不依赖。举个简单的例子：如果在main线程中创建了一个守护线程，当main方法运行完毕之后，守护线程也会随着消亡。而用户线程则不会，用户线程会一直运行直到其运行完毕。在JVM中，像垃圾收集器线程就是守护线程。

CAS：

CAS是乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。

线程池：

线程池的作用：
在程序启动的时候就创建若干线程来响应处理，它们被称为线程池，里面的线程叫工作线程
第一：降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
第二：提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
第三：提高线程的可管理性。
常用线程池：ExecutorService 是主要的实现类，其中常用的有
Executors.newSingleT
hreadPool(),newFixedThreadPool(),newcachedTheadPool(),newScheduledThreadPool()。

ThreadPoolExecutor：

构造方法参数说明
corePoolSize:核心线程数，默认情况下核心线程会一直存活，即使处于闲置状态也不会受存keepAliveTime限制。除非将allowCoreThreadTimeOut设置为true。
maximumPoolSize:线程池所能容纳的最大线程数。超过这个数的线程将被阻塞。当任务队列为没有设置大小的LinkedBlockingDeque时，这个值无效。
keepAliveTime:非核心线程的闲置超时时间，超过这个时间就会被回收。
unit:指定keepAliveTime的单位，如TimeUnit.SECONDS。当将allowCoreThreadTimeOut设置为true时对corePoolSize生效。
workQueue:线程池中的任务队列.
常用的有三种队列，SynchronousQueue,LinkedBlockingDeque,ArrayBlockingQueue。

threadFactory:线程工厂，提供创建新线程的功能。ThreadFactory是一个接口，只有一个方法

原理
如果当前池大小 poolSize 小于 corePoolSize ，则创建新线程执行任务。
如果当前池大小 poolSize 大于 corePoolSize ，且等待队列未满，则进入等待队列
如果当前池大小 poolSize 大于 corePoolSize 且小于 maximumPoolSize ，且等待队列已满，则创建新线程执行任务。
如果当前池大小 poolSize 大于 corePoolSize 且大于 maximumPoolSize ，且等待队列已满，则调用拒绝策略来处理该任务。
线程池里的每个线程执行完任务后不会立刻退出，而是会去检查下等待队列里是否还有线程任务需要执行，如果在 keepAliveTime 里等不到新的任务了，那么线程就会退出。

死锁,以及解决死锁：

死锁产生的四个必要条件
互斥条件：资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。
不可剥夺条件：进程所获得的资源在未使用完毕之前，不被其他进程强行剥夺，而只能由获得该资源的进程资源释放。
请求和保持条件：进程每次申请它所需要的一部分资源，在申请新的资源的同时，继续占用已分配到的资源。
循环等待条件：在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有的资源，形成一个进程等待环路，环路中每一个进程所占有的资源同时被另一个申请，也就是前一个进程占有后一个进程所深情地资源。

解决死锁
一是死锁预防，就是不让上面的四个条件同时成立。
二是，合理分配资源。
三是使用银行家算法，如果该进程请求的资源操作系统剩余量可以满足，那么就分配。

并发模型

悲观锁

悲观锁假设最坏的情况（如果你不锁门，那么捣蛋鬼就会闯入并搞得一团糟），并且只有在确保其他线程不会干扰（通过获取正确的锁）的情况下才能执行下去。

常见实现如独占锁等。

安全性更高，但在中低并发程度下的效率更低。

乐观锁

乐观锁借助冲突检查机制来判断在更新过程中是否存在其他线程的干扰，如果存在，这个操作将失败，并且可以重试（也可以不重试）。

常见实现如CAS等。

部分乐观锁削弱了一致性，但中低并发程度下的效率大大提高。

悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。

乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

两种锁的使用场景

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。