JUC-共享模型之工具
一、线程池（重点）
池化技术有很多, 比如
线程池、数据库连接池、HTTP连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。
线程池的核心思想：线程复用，同一个线程可以被重复使用，来处理多个任务
线程池的好处：
降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。(创建的线程，实际最后要和操作系统的线程做映射，很消耗资源)提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。
1.1 自定义一个简单的线程池
- 阻塞队列中维护了由主线程（或者其他线程）所产生的的任务
- 主线程类似于生产者，产生任务并放入阻塞队列中
- 线程池类似于消费者，得到阻塞队列中已有的任务并执行
自定义线程池的实现步骤 :
- 步骤1：自定义拒绝策略接口
- 步骤2：自定义任务阻塞队列
- 步骤3：自定义线程池
- 步骤4：测试
/**
* Description: 自定义一个简单的线程池
*
*/
@Slf4j(topic = "guizy.TestPool")
public class TestPool {
public static void main(String[] args) {
ThreadPool threadPool = new ThreadPool(1, 1000, TimeUnit.MILLISECONDS, 1, new RejectPolicy<Runnable>() {
@Override
public void reject(BlockingQueue<Runnable> queue, Runnable task) {
// 拒绝策略
// 1、死等
// queue.put(task);
// 2、带超时等待
queue.offer(task, 2000, TimeUnit.MILLISECONDS);
// 3、让调用者放弃任务执行
// log.debug("放弃-{}", task);
// 4、让调用者抛弃异常
// throw new RuntimeException("任务执行失败" + task);
// 5、让调用者自己执行任务
// task.run();
}
});
// 创建5个任务
for (int i = 0; i < 4; i++) {
int j = i;
threadPool.execute(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
log.debug("{}", j);
}
});
}
}
}
/**
* 拒绝策略接口
*/
@FunctionalInterface
interface RejectPolicy<T> {
void reject(BlockingQueue<T> queue, T task);
}
/**
* 线程池
*/
@Slf4j(topic = "guizy.TestPool")
class ThreadPool {
// 阻塞任务队列
private BlockingQueue<Runnable> taskQueue;
// 线程集合
private HashSet<Worker> workers = new HashSet<>();
// 核心线程数
private int coreSize;
// 获取任务的超时时间
private long timeout;
private TimeUnit timeUnit;
// 拒绝策略
private RejectPolicy<Runnable> rejectPolicy;
public ThreadPool(int coreSize, long timeout, TimeUnit timeUnit, int queueCapacity, RejectPolicy<Runnable> rejectPolicy) {
this.coreSize = coreSize;
this.timeout = timeout;
this.timeUnit = timeUnit;
this.taskQueue = new BlockingQueue<>(queueCapacity);
this.rejectPolicy = rejectPolicy;
}
// 执行任务
public void execute(Runnable task) {
synchronized (workers) {
// 当任务没有超过线程数, 说明当前worker线程可以消费这些任务, 不用将任务加入到阻塞队列中
if (workers.size() < coreSize) {
Worker worker = new Worker(task);
log.debug("新增 worker {}, {}", worker, task);
workers.add(worker);
worker.start();
} else {
// taskQueue.put(task); // 这一种死等
// 拒绝策略
// 1、死等
// 2、带超时等待
// 3、让调用者放弃任务执行
// 4、让调用者抛弃异常
// 5、让调用者自己执行任务
taskQueue.tryPut(rejectPolicy, task);
}
}
}
class Worker extends Thread {
private Runnable task;
public Worker(Runnable task) {
this.task = task;
}
@Override
public void run() {
// 执行任务
// 1): 当task不为空, 执行任务
// 2): 当task执行完毕, 从阻塞队列中获取任务并执行
//while (task != null || (task = taskQueue.take()) != null) {
while (task != null || (task = taskQueue.poll(timeout, timeUnit)) != null) {
try {
log.debug("正在执行...{}", task);
task.run();
} catch (Exception e) {
e.printStackTrace();
} finally {
task = null;
}
}
// 将线程集合中的线程移除
synchronized (workers) {
log.debug("worker被移除 {}", this);
workers.remove(this);
}
}
}
}
/**
* 用于存放任务的阻塞队列
*
* @param <T> Runnable, 任务抽象为Runnable
*/
@Slf4j(topic = "guizy.TestPool")
class BlockingQueue<T> {
// 1、任务队列
private Deque<T> queue = new ArrayDeque<>();
// 2、锁
private ReentrantLock lock = new ReentrantLock();
// 3、生产者的条件变量 (当阻塞队列塞满任务的时候, 没有空间, 此时进入条件变量中等待)
private Condition fullWaitSet = lock.newCondition();
// 4、消费者的条件变量 (当没有任务可以消费的时候, 进入条件变量中等待)
private Condition emptyWaitSet = lock.newCondition();
// 5、阻塞队列的容量
private int capacity;
public BlockingQueue(int capacity) {
this.capacity = capacity;
}
// 从阻塞队列中获取任务, 如果没有任务, 会等待指定的时间
public T poll(long timeout, TimeUnit unit) {
lock.lock();
try {
// 将timeout统一转换为纳秒
long nanos = unit.toNanos(timeout);
while (queue.isEmpty()) {
try {
// 表示超时, 无需等待, 直接返回null
if (nanos <= 0) {
return null;
}
// 返回值的时间(剩余时间) = 等待时间 - 经过时间 所以不存在虚假唤醒(时间还没等够就被唤醒,然后又从新等待相同时间)
nanos = emptyWaitSet.awaitNanos(nanos);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
T t = queue.removeFirst();
fullWaitSet.signal(); // 唤醒生产者进行生产, 此时阻塞队列没有满
return t;
} finally {
lock.unlock();
}
}
// 从阻塞队列中获取任务, 如果没有任务,会一直等待
public T take() {
lock.lock();
try {
// 阻塞队列是否为空
while (queue.isEmpty()) {
// 进入消费者的条件变量中等待,此时没有任务供消费
try {
emptyWaitSet.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
// 阻塞队列不为空, 获取队列头部任务
T t = queue.removeFirst();
fullWaitSet.signal(); // 唤醒生产者进行生产, 此时阻塞队列没有满
return t;
} finally {
lock.unlock();
}
}
// 往阻塞队列中添加任务
public void put(T task) {
lock.lock();
try {
// 阻塞队列是否满了
while (queue.size() == capacity) {
try {
log.debug("等待进入阻塞队列...");
fullWaitSet.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
queue.addLast(task);
log.debug("加入任务阻塞队列 {}", task);
emptyWaitSet.signal(); // 此时阻塞队列中有任务了, 唤醒消费者进行消费任务
} finally {
lock.unlock();
}
}
// 往阻塞队列中添加任务(带超时)
public boolean offer(T task, long timeout, TimeUnit timeUnit) {
lock.lock();
try {
long nanos = timeUnit.toNanos(timeout);
while (queue.size() == capacity) {
try {
if (nanos <= 0) {
return false;
}
log.debug("等待进入阻塞队列 {}...", task);
nanos = fullWaitSet.awaitNanos(nanos);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
log.debug("加入任务阻塞队列 {}", task);
queue.addLast(task);
emptyWaitSet.signal(); // 此时阻塞队列中有任务了, 唤醒消费者进行消费任务
return true;
} finally {
lock.unlock();
}
}
// 获取队列大小
public int size() {
lock.lock();
try {
return queue.size();
} finally {
lock.unlock();
}
}
public void tryPut(RejectPolicy<T> rejectPolicy, T task) {
lock.lock();
try {
// 判断队列是否满
if (queue.size() == capacity) {
rejectPolicy.reject(this, task);
} else {
// 有空闲
log.debug("加入任务队列 {}", task);
queue.addLast(task);
emptyWaitSet.signal();
}
} finally {
lock.unlock();
}
}
}
实现了一个简单的线程池
- 阻塞队列
BlockingQueue用于暂存来不及被线程执行的任务- 也可以说是平衡生产者和消费者执行速度上的差异
- 里面的获取任务和放入任务用到了
生产者消费者模式
- 线程池中对线程Thread进行了再次的封装，封装为了Worker
- 在调用 任务对象 (Runnable、Callable) 的
run方法时，线程会去执行该任务，执行完毕后还会到阻塞队列中获取新任务来执行
- 在调用 任务对象 (Runnable、Callable) 的
- 线程池中执行任务的主要方法为
execute方法- 执行时要判断正在执行的线程数是否大于了线程池容量
1.2 ThreadPoolExecutor
1.2.1 线程池的继承关系
1.2.2 Executor 框架结构
-
任务类 (
Runnable/Callable)- 执行任务需要实现的
Runnable接口 或Callable接口。Runnable 接口或 Callable 接口 实现类都可以被 ThreadPoolExecutor 或 ScheduledThreadPoolExecutor 执行。
- 执行任务需要实现的
-
任务的执行 (
Executor)- 如上图所示，包括任务执行机制的核心接口 Executor ，以及继承自 Executor 接口的 ExecutorService 接口。
ThreadPoolExecutor和ScheduledThreadPoolExecutor这两个关键类实现了ExecutorService接口。 - 这里有很多底层的类关系，但是，实际上我们需要更多关注的是 ThreadPoolExecutor 这个类，它在我们实际使用线程池的过程中，使用频率非常高。
- 如上图所示，包括任务执行机制的核心接口 Executor ，以及继承自 Executor 接口的 ExecutorService 接口。
-
异步计算的结果 (
Future)Future接口 以及 Future接口的实现类FutureTask类 都可以代表异步计算的结果。- 当把 Runnable接口 或 Callable 接口的实现类提交给 ThreadPoolExecutor 或 ScheduledThreadPoolExecutor 执行。（调用
submit() 方法时会返回一个FutureTask对象） - Futrue和join方法类似，
futrue的get方法需要等待线程执行完毕，才可以获取的线程的执行结果。也称之为保护性暂停
- 1.主线程首先要创建实现 Runnable 或者 Callable 接口的任务对象。
- 2.把创建完成的实现 Runnable/Callable接口的对象 直接交给 ExecutorService 执行:
ExecutorService.execute（Runnable command）ExecutorService.submit（Runnable task）ExecutorService.submit（Callable <T> task）
- 3.如果执行
ExecutorService.submit（…），ExecutorService 将返回一个实现Future接口的对象 - 4.最后，主线程可以执行
FutureTask.get()方法来等待任务执行完成。主线程也可以执行FutureTask.cancel（boolean mayInterruptIfRunning）来取消此任务的执行
1.3 线程池状态
ThreadPoolExecutor 使用 int 的高 3 位来表示线程池状态，低 29 位表示线程数量。
这些信息存储在一个原子变量 ctl中，目的是将线程池状态与线程个数合二为一，这样就可以用一次 CAS 原子操作进行赋值。
// 原子整数，前3位保存了线程池的状态，剩余位保存的是线程数量
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
// 并不是所有平台的int都是32位。
// 去掉前三位保存线程状态的位数，剩下的用于保存线程数量
// 高3位为0，剩余位数全为1
private static final int COUNT_BITS = Integer.SIZE - 3;
// 2^COUNT_BITS次方，表示可以保存的最大线程数
// CAPACITY 的高3位为 0
private static final int CAPACITY = (1 << COUNT_BITS) - 1;
| 状态 | 高3位 | 接收新任务 | 处理阻塞任务队列 | 说明 |
|---|---|---|---|---|
| RUNNING | 111 | Y | Y | |
| SHUTDOWN | 000 | N | Y | 不接收新任务，但处理阻塞队列剩余任务 |
| STOP | 001 | N | N | 中断正在执行的任务，并抛弃阻塞队列任务 |
| TIDYING | 010 | - | - | 任务全执行完毕，活动线程为 0 即将进入终结 |
| TERMINATED | 011 | - | - | 终止状态 |
获取线程池状态、线程数量以及合并两个值的操作
// Packing and unpacking ctl
// 获取运行状态
// 该操作会让除高3位以外的数全部变为0
private static int runStateOf(int c) { return c & ~CAPACITY; }
// 获取运行线程数
// 该操作会让高3位为0
private static int workerCountOf(int c) { return c & CAPACITY; }
// 重置当前线程池状态 ctl
// rs 表示线程池状态，wc 表示当前线程池中 worker（线程）数量，相与以后就是合并后的状态
private static int ctlOf(int rs, int wc) { return rs | wc; }
比较当前线程池 ctl 所表示的状态
// 比较当前线程池 ctl 所表示的状态，是否小于某个状态 s
// 状态对比：RUNNING < SHUTDOWN < STOP < TIDYING < TERMINATED
private static boolean runStateLessThan(int c, int s) { return c < s; }
// 比较当前线程池 ctl 所表示的状态，是否大于等于某个状态s
private static boolean runStateAtLeast(int c, int s) { return c >= s; }
// 小于 SHUTDOWN 的一定是 RUNNING，SHUTDOWN == 0
private static boolean isRunning(int c) { return c < SHUTDOWN; }
设置线程池 ctl
// 使用 CAS 方式 让 ctl 值 +1 ，成功返回 true, 失败返回 false
private boolean compareAndIncrementWorkerCount(int expect) {
return ctl.compareAndSet(expect, expect + 1);
}
// 使用 CAS 方式 让 ctl 值 -1 ，成功返回 true, 失败返回 false
private boolean compareAndDecrementWorkerCount(int expect) {
return ctl.compareAndSet(expect, expect - 1);
}
// 将 ctl 值减一，do while 循环会一直重试，直到成功为止
private void decrementWorkerCount() {
do {} while (!compareAndDecrementWorkerCount(ctl.get()));
}
1.4 线程池的成员属性
// 工作线程，内部封装了Thread
private final class Worker
extends AbstractQueuedSynchronizer
implements Runnable {
...
}
// 线程全局锁
// 增加减少 worker 或者时修改线程池运行状态需要持有 mainLock
private final ReentrantLock mainLock = new ReentrantLock();
// 可重入锁的条件变量
// 当外部线程调用 awaitTermination() 方法时，会等待当前线程池状态为 Termination 为止
private final Condition termination = mainLock.newCondition()
// 用于存放核心线程的容器，只有当持有锁时才能够获取其中的元素（核心线程）
private final HashSet<Worker> workers = new HashSet<Worker>();
线程池相关参数
private volatile int corePoolSize; // 核心线程数量
private volatile int maximumPoolSize; // 线程池最大线程数量
private volatile long keepAliveTime; // 空闲线程存活时间
private volatile ThreadFactory threadFactory; // 创建线程时使用的线程工厂，默认是 DefaultThreadFactory
private final BlockingQueue<Runnable> workQueue;// 【超过核心线程提交任务就放入 阻塞队列】
private volatile RejectedExecutionHandler handler; // 拒绝策略，juc包提供了4中方式
private static final RejectedExecutionHandler defaultHandler = new AbortPolicy();// 默认策略
记录线程池相关属性的数值
private int largestPoolSize; // 记录线程池生命周期内线程数最大值
private long completedTaskCount; // 记录线程池所完成任务总数，当某个 worker 退出时将完成的任务累加到该属性
控制核心线程数量内的线程是否可以被回收
// false（默认）代表不可以，为 true 时核心线程空闲超过 keepAliveTime 也会被回收
// allowCoreThreadTimeOut(boolean value) 方法可以设置该值
private volatile boolean allowCoreThreadTimeOut;
1.5 构造方法及参数
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
参数介绍：
-
corePoolSize：核心线程数，定义了最小可以同时运行的线程数量 -
maximumPoolSize：最大线程数，当队列中存放的任务达到队列容量时，当前可以同时运行的数量变为最大线程数，创建线程并立即执行最新的任务，与核心线程数之间的差值又叫救急线程数 -
keepAliveTime：救急线程最大存活时间，当线程池中的线程数量大于corePoolSize的时候，如果这时没有新的任务提交，核心线程外的线程不会立即销毁，而是会等到keepAliveTime时间超过销毁 -
unit：keepAliveTime参数的时间单位 -
workQueue：阻塞队列，存放被提交但尚未被执行的任务 -
threadFactory：线程工厂，创建新线程时用到，可以为线程创建时起名字 -
handler：拒绝策略，线程到达最大线程数仍有新任务时会执行拒绝策略
RejectedExecutionHandler 下有 4 个实现类：
AbortPolicy 中止策略：让调用者抛出 RejectedExecutionException 异常，默认策略CallerRunsPolicy 调用者运行策略：让调用者运行的调节机制，将某些任务回退到调用者，从而降低新任务的流量DiscardPolicy 丢弃策略：直接丢弃任务，不予任何处理也不抛出异常DiscardOldestPolicy 弃老策略：放弃队列中最早的任务，把当前任务加入队列中尝试再次提交当前任务
补充：其他框架拒绝策略
- Dubbo：在抛出 RejectedExecutionException 异常前记录日志，并 dump 线程栈信息，方便定位问题
- Netty：创建一个新线程来执行任务
- ActiveMQ：带超时等待（60s）尝试放入队列
- PinPoint：它使用了一个拒绝策略链，会逐一尝试策略链中每种拒绝策略
- 1.创建线程池，这时没有创建线程（懒惰），等待提交过来的任务请求，调用 execute 方法才会创建线程
- 2.当调用 execute() 方法添加一个请求任务时，线程池会做如下判断：
- 如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务
- 如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入阻塞队列
- 如果这时队列满了且正在运行的线程数量还小于 maximumPoolSize，那么会创建
非核心线程立刻运行这个任务，对于阻塞队列中的任务不公平。这是因为创建每个 Worker （线程）对象会绑定一个初始任务，启动 Worker 时会优先执行 - 如果队列满了且正在运行的线程数量大于或等于 maximumPoolSize，那么线程池会启动饱和拒绝策略来执行
- 3.当一个线程完成任务时，会从队列中取下一个任务来执行
- 4.当一个线程空闲超过一定的时间（keepAliveTime）时，线程池会判断：如果当前运行的线程数大于 corePoolSize，那么这个线程就被停掉，所以线程池的所有任务完成后最终会收缩到 corePoolSize 大小
1.6 Executors
Executors 提供了四种线程池的创建：newCachedThreadPool、newFixedThreadPool、newSingleThreadExecutor、newScheduledThreadPool
newFixedThreadPool
newFixedThreadPool：创建一个拥有 n 个线程的线程池
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
- 核心线程数 == 最大线程数（没有救急线程被创建），因此也无需超时时间
LinkedBlockingQueue是一个单向链表实现的阻塞队列，默认大小为Integer.MAX_VALUE，也就是无界队列，可以放任意数量的任务，在任务比较多的时候会导致 OOM（内存溢出）- 适用于任务量已知，相对耗时的长期任务
newCachedThreadPool
-
newCachedThreadPool：创建一个可扩容的线程池public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>()); }- 核心线程数是 0， 最大线程数是 29 个 1，全部都是救急线程（60s 后可以回收），可能会创建大量线程，从而导致 OOM
SynchronousQueue作为阻塞队列，没有容量，对于每一个 take 的线程会阻塞直到有一个 put 的线程放入元素为止（类似一手交钱、一手交货）- 适合任务数比较密集，但每个任务执行时间较短的情况
newSingleThreadExecutor
-
newSingleThreadExecutor：创建一个只有 1 个线程的单线程池public static ExecutorService newSingleThreadExecutor() { return new FinalizableDelegatedExecutorService (new ThreadPoolExecutor(1, 1,0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>())); }- 保证所有任务按照指定顺序执行，线程数固定为 1，任务数多于 1 时会放入无界队列排队，任务执行完毕，这唯一的线程也不会被释放
对比：
-
创建一个单线程串行执行任务，如果任务执行失败而终止那么没有任何补救措施，线程池则会新建一个线程，保证池的正常工作
-
Executors.newSingleThreadExecutor() 线程个数始终为1，不能修改。FinalizableDelegatedExecutorService 应用的是装饰器模式，只对外暴露了 ExecutorService 接口，因此不能调用 ThreadPoolExecutor 中特有的方法
原因：父类不能直接调用子类中的方法，需要反射或者创建对象的方式，可以调用子类静态方法
-
Executors.newFixedThreadPool(1) 初始时为1，可以修改。对外暴露的是 ThreadPoolExecutor 对象，可以强转后调用 setCorePoolSize 等方法进行修改
-
阿里巴巴 Java 开发手册要求
-
线程资源必须通过线程池提供，不允许在应用中自行显式创建线程
- 使用线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题
- 如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者过度切换的问题
-
线程池不允许使用 Executors 去创建，而是通过
ThreadPoolExecutor的方式，这样的处理方式更加明确线程池的运行规则，规避资源耗尽的风险
Executors 返回线程池对象的弊端如下：
FixedThreadPool和SingleThreadExecutor： 允许请求的队列长度为 Integer.MAX_VALUE (无界阻塞队列)，可能堆积大量的请求，从而导致OOM。CachedThreadPool和ScheduledThreadPool： 允许创建的线程数量为 Integer.MAX_VALUE ，可能会创建大量线程，从而导致OOM。
1.7 执行/提交任务 execute/submit
// 执行任务
void execute(Runnable command);
// 提交任务 task，用返回值 Future 获得任务执行结果，Future的原理就是利用我们之前讲到的保护性暂停模式来接受返回结果的，主线程可以执行 FutureTask.get()方法来等待任务执行完成
<T> Future<T> submit(Callable<T> task);
// 提交 tasks 中所有任务
<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException;
// 提交 tasks 中所有任务，带超时时间
<T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks,long timeout, TimeUnit unit) throws InterruptedException;
// 提交 tasks 中所有任务，哪个任务先成功执行完毕，返回此任务执行结果，其它任务取消
<T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException;
// 提交 tasks 中所有任务，哪个任务先成功执行完毕，返回此任务执行结果，其它任务取消，带超时时间
<T> T invokeAny(Collection<? extends Callable<T>> tasks,long timeout, TimeUnit unit) throws InterruptedException, ExecutionException, TimeoutException;
execute和submit都属于线程池的方法，对比：
-
execute只能执行Runnable类型的任务，没有返回值；submit既能提交 Runnable 类型任务也能提交 Callable 类型任务，底层是封装成FutureTask，然后调用 execute 执行 -
execute会直接抛出任务执行时的异常，submit会吞掉异常，可通过 Future 的 get 方法将任务执行时的异常重新抛出
1.8 关闭线程池 shutdown()
- 将线程池的状态改为 SHUTDOWN
- 不再接受新任务，但是会将阻塞队列中的任务执行完
| 方法 | 说明 |
|---|---|
| void shutdown() | 线程池状态变为 SHUTDOWN，等待任务执行完后关闭线程池，不会接收新任务，但已提交任务会执行完，而且也可以添加线程 |
| List shutdownNow() | 线程池状态变为 STOP，用 interrupt 中断正在执行的任务，直接关闭线程池，不会接收新任务，会将队列中的任务返回 |
| boolean isShutdown() | 不在RUNNING状态的线程池，此执行者已被关闭，方法返回 true |
| boolean isTerminated() | 线程池状态是否是 TERMINATED，如果所有任务在关闭后完成，返回 true |
| boolean awaitTermination(long timeout, TimeUnit unit) | 调用 shutdown 后，由于调用线程不会等待所有任务运行结束，如果它想在线程池 TERMINATED 后做些事情，可以利用此方法等待 |
二、异步模式之工作线程
- 让有限的工作线程（Worker Thread）来轮流异步处理无限多的任务。也可以将其归类为分工模式，它的典型实现就是线程池，也体现了经典设计模式中的享元模式。
- 例如，海底捞的服务员（线程），轮流处理每位客人的点餐（任务），如果为每位客人都配一名专属的服务员，那么成本就太高了（对比另一种多线程设计模式：Thread-Per-Message）
注意: 不同任务类型应该使用不同的线程池，这样能够避免饥饿，并能提升效率
2.1 线程池中线程设置多少为好
-
一般来说池中总线程数是核心池线程数量两倍，确保当核心池有线程停止时，核心池外有线程进入核心池
-
过小会导致程序不能充分地利用系统资源、容易导致饥饿 -
过大会导致更多的线程上下文切换，占用更多内存
核心线程数常用公式：
-
CPU 密集型任务(N+1)： 这种任务消耗的是 CPU 资源，可以将核心线程数设置为
N (CPU 核心数) + 1，比 CPU 核心数多出来的一个线程是为了防止线程发生缺页中断，或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 某个核心就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间CPU 密集型简单理解就是利用 CPU 计算能力的任务比如在内存中对大量数据进行分析
-
I/O 密集型任务： 这种系统 CPU 处于阻塞状态，用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用，因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是
线程数 = 核数 * 期望 CPU 利用率 * 总时间(CPU计算时间+等待时间) / CPU 计算时间IO 密集型就是涉及到网络读取，文件读取此类任务 ，特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上
2.2 正确处理执行任务异常
execute会直接抛出任务执行时的异常，submit会吞掉异常，有两种处理方法
方法 1：主动捉异常
ExecutorService executorService = Executors.newFixedThreadPool(1);
pool.submit(() -> {
try {
System.out.println("task1");
int i = 1 / 0;
} catch (Exception e) {
e.printStackTrace();
}
});
方法 2：使用 Future 对象，错误信息都被封装进submit方法的返回方法中
ExecutorService executorService = Executors.newFixedThreadPool(1);
Future<?> future = pool.submit(() -> {
System.out.println("task1");
int i = 1 / 0;
return true;
});
System.out.println(future.get());
2.3 Fork/Join
概念
- Fork/Join 是 JDK 1.7 加入的新的线程池实现，它体现的是一种分治思想，适用于能够进行任务拆分的
cpu 密集型运算 - 所谓的任务拆分，是将一个大任务拆分为算法上相同的小任务，直至不能拆分可以直接求解。跟递归相关的一些计算，如归并排序、斐波那契数列、都可以用分治思想进行求解
- Fork/Join 在分治的基础上加入了多线程，可以把每个任务的分解和合并交给不同的线程来完成，进一步提升了运算效率
- Fork/Join 默认会创建与 cpu 核心数大小相同的线程池
使用
提交给 Fork/Join 线程池的任务需要继承 RecursiveTask（有返回值）或 RecursiveAction（没有返回值）
当调用fork，会重新执行compute方法，进行递归运算
例子
@Slf4j(topic = "guizy.TestForkJoin2")
public class TestForkJoin2 {
public static void main(String[] args) {
ForkJoinPool pool = new ForkJoinPool(4);
System.out.println(pool.invoke(new MyTask(5)));
// new MyTask(5) 5+ new MyTask(4) 4 + new MyTask(3) 3 + new MyTask(2) 2 + new MyTask(1)
}
}
// 1~n 之间整数的和
@Slf4j(topic = "guizy.MyTask")
class MyTask extends RecursiveTask<Integer> {
private int n;
public MyTask(int n) {
this.n = n;
}
@Override
public String toString() {
return "{" + n + '}';
}
@Override
protected Integer compute() {
// 如果 n 已经为 1，可以求得结果了
if (n == 1) {
log.debug("join() {}", n);
return n;
}
// 将任务进行拆分(fork)
AddTask1 t1 = new AddTask1(n - 1);
t1.fork();
log.debug("fork() {} + {}", n, t1);
// 合并(join)结果
int result = n + t1.join();
log.debug("join() {} + {} = {}", n, t1, result);
return result;
}
}
参考：
扫一扫
450
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
