* 进程在执行过程中拥有独立的内存单元，而多个线程共享内存资源，减少切换次数，从而效率更高。

* 线程是进程的一个实体，是cpu调度和分派的基本单位，是比程序更小的能独立运行的基本单位。

<div align="center"> <img src="https://github.com/lvminghui/Java-Notes/blob/master/docs/imgs/线程状态切换.png"/> </div><br>

创建一个固定线程数量的线程池，每当提交一个任务就创建一个线程，直到达到线程池的最大数量，这时线程规模将不再变化，新的任务会暂存在任务队列中，待有线程空闲时便处理任务。

* **corePoolSize**：线程池里的线程数量，核心线程池大小

* **maxPoolSize**：线程池里的最大线程数量

* **workQueue**： 任务队列，用于存放提交但是尚未被执行的任务。

* keepAliveTime：当线程池中的线程数量大于 corePoolSize 时，核心线程外的线程不会立即销毁，而是会等待，直到等待的时间超过了 keepAliveTime 才会被回收销毁； 参数的时间单位为 unit。

* threadFactory：线程工厂，用于创建线程，一般可以用默认的

* handler：拒绝策略

* ArrayBlockingQueue：基于数组实现的一个阻塞队列，在创建ArrayBlockingQueue对象时必须制定容量大小。并且可以指定公平性与非公平性，默认情况下为非公平的，即不保证等待时间最长的队列最优先能够访问队列。

* LinkedBlockingQueue：基于链表实现的一个阻塞队列，在创建LinkedBlockingQueue对象时如果不指定容量大小，则默认大小为Integer.MAX_VALUE。

* PriorityBlockingQueue：以上2种队列都是先进先出队列，而PriorityBlockingQueue却不是，它会按照元素的优先级对元素进行排序，按照优先级顺序出队，每次出队的元素都是优先级最高的元素。注意，此阻塞队列为无界阻塞队列，即容量没有上限（通过源码就可以知道，它没有容器满的信号标志），前面2种都是有界队列。

* DelayQueue：基于PriorityQueue，一种延时阻塞队列，DelayQueue中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素。DelayQueue也是一个无界队列，因此往队列中插入数据的操作（生产者）永远不会被阻塞，而只有获取数据的操作（消费者）才会被阻塞。

1. 减少创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务。

2. 可以根据系统的承受能力，调整线程池中工作线程的数目，放置因为消耗过多的内存，而把服务器累趴下

- 如果你使用的**LinkedBlockingQueue（阻塞队列）**，也就是**无界队列**的话，没关系，**继续添加任务**到阻塞队列中等待执行，因为LinkedBlockingQueue可以近乎认为是一个**无穷大的队列，可以无限存放任务**；如果你使用的是**有界队列**比方说**ArrayBlockingQueue**的话，任务首先会被添加到ArrayBlockingQueue中，**ArrayBlockingQueue满了**，则会使用**拒绝策略RejectedExecutionHandler**处理满了的任务，默认是**AbortPolicy**。

- 线程池的饱和策略：当阻塞队列满了，且没有空闲的工作线程，如果继续提交任务，必须采取一种策略处理该任务，线程池提供了**4种策略**

也叫做ThreadPoolexecutor工作流程

* 先判断核心线程池是否已满

* 如果没有满就创建线程

* 如果满了就判断等待队列是否已满

* 如果没满就加入等待队列

* 如果满了就判断最大线程池是否已满

* 没有满就提交给线程池

* 满了就执行拒绝策略

**有2种**：分别为Runnable和Callable。

分别使用execute 方法和 submit 方法

1. ThreadPoolExecutor.AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。

2. ThreadPoolExecutor.DiscardPolicy：丢弃任务，但是不抛出异常。

3. ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新提交被拒绝的任务

4. ThreadPoolExecutor.CallerRunsPolicy：由调用线程（提交任务的线程）处理该任务

1. 一般来说，如果是CPU密集型应用，则线程池大小设置为N+1。

2. 一般来说，如果是IO密集型应用，则线程池大小设置为2N+1。

3. 在IO优化中，线程等待时间所占比例越高，需要越多线程，线程CPU时间所占比例越高，需要越少线程。这样的估算公式可能更适合：最佳线程数目 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU数目

volatile在多处理器开发中保证了共享变量的“ 可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。

1.同步方法 synchronized 关键字修饰的方法（悲观锁）

2.使用特殊域变量(volatile)实现线程同步（保持可见性，多线程更新某一个值时，比如说线程安全单例双检查锁）

3.ThreadLocal（每个线程获取的都是该变量的副本）

4.使用重入锁实现线程同步（相对 synchronized 锁粒度更细了，效率高）

​ 一个java.util.concurrent 包来支持同步。

​ ReentrantLock 类是可重入、互斥、实现了 Lock 接口的锁

​ ReentrantLock() : 创建一个 ReentrantLock 实例

​ lock() : 获得锁

​ unlock() : 释放锁

5.java.util.concurrent.atomic 包 （乐观锁）

​ 方便程序员在多线程环境下，无锁的进行原子操作

​

​ CAS，Compare and Swap即比较并交换。java.util.concurrent 包借助 CAS 实现了区别于 synchronized 同步锁的一种乐观锁。乐观锁就是每次去取数据的时候都乐观的认为数据不会被修改，所以不会上锁，但是在更新的时候会判断一下在此期间数据有没有更新。CAS 有3个操作数：内存值 V，旧的预期值 A，要修改的新值 B

分2种情况

1. 局部变量肯定是线程安全的（原因：方法内局部变量是线程私有的）

2. 成员变量多个线程共享时，就不是线程安全的（原因：成员变量是线程共享的，因为 i++ 是三步操作。

* synchronized是java内置关键字在jvm层面，Lock是个java类。

* synchronized无法判断是否获取锁的状态，Lock可以判断是否获取到锁，并且可以主动尝试去获取锁。

* synchronized会自动释放锁，Lock需在finally中手工释放锁（unlock()方法释放锁），否则容易造成线程死锁。

* ReentrantLock更加灵活，提供了超时获取锁，可中断锁，在获取不到锁的情况会自己结束，而synchronized不可以

* synchronized的锁不可重入、不可中断、非公平，而Lock锁可重入、可判断、可公平（两者皆可）

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

总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。**乐观锁适用于多读的应用类型，这样可以提高吞吐量**

在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数，当数据被修改时，version 值会加一。当线程A要更新数据值时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

公平锁需要系统维护一个有序队列，获取锁时会判断阻塞队列里是否有线程再等待，若有获取锁就会失败，并且会加入阻塞队列。

非公平锁获取锁时不会判断阻塞队列是否有线程再等待，所以对于已经在等待的线程来说是不公平的，但如果是因为其它原因没有竞争到锁，它也会加入阻塞队列。

进入阻塞队列的线程，竞争锁时都是公平的，因为队列为先进先出（FIFO）。

**TODO:**

多线程的线程池是如何工作的？底层代码和原理？

Thredlocal 实现原理?