线程池
作用
- 降低资源消耗，减少创建和销毁线程的次数
- 提高响应速度，任务到达时又线程可以直接使用，无需创建
- 提高线程可管理性，如果无限制的创建线程，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控
阻塞队列
链表队列
LinkedBlockingQueue 源码
public class LinkedBlockingQueue<E> extends AbstractQueue<E>
implements BlockingQueue<E>, java.io.Serializable {
static class Node<E> {
E item;
/**
* 下列三种情况之一
* - 真正的后继节点
* - 自己, 发生在出队时
* - null, 表示是没有后继节点, 是尾节点了
*/
Node<E> next;
Node(E x) { item = x; }
}
}
入队出队
入队： 尾插法
last = last.next = node
出队：FIFO
h = head→first = h.next
h.next = h→head = first
*
first.item = null：当前节点置为 Dummy 节点
加锁分析
用了两把锁和 dummy 节点：
- 用一把锁，同一时刻，最多只允许有一个线程（生产者或消费者，二选一）执行
- 用两把锁，同一时刻，可以允许两个线程同时（一个生产者与一个消费者）执行
- 消费者与消费者线程仍然串行
- 生产者与生产者线程仍然串行
线程安全分析：
- 当节点总数大于 2 时（包括 dummy 节点），putLock 保证的是 last 节点的线程安全，takeLock 保证的是 head 节点的线程安全，两把锁保证了入队和出队没有竞争
- 当节点总数等于 2 时（即一个 dummy 节点，一个正常节点）这时候，仍然是两把锁锁两个对象，不会竞争
- 当节点总数等于 1 时（就一个 dummy 节点）这时 take 线程会被 notEmpty 条件阻塞，有竞争，会阻塞
// 用于 put(阻塞) offer(非阻塞)
private final ReentrantLock putLock = new ReentrantLock();
private final Condition notFull = putLock.newCondition(); // 阻塞等待不满，说明已经满了
// 用于 take(阻塞) poll(非阻塞)
private final ReentrantLock takeLock = new ReentrantLock();
private final Condition notEmpty = takeLock.newCondition(); // 阻塞等待不空，说明已经是空的
入队出队：
- put 操作：
public void put(E e) throws InterruptedException {
// 空指针异常
if (e == null) throw new NullPointerException();
int c = -1;
// 把待添加的元素封装为 node 节点
Node<E> node = new Node<E>(e);
// 获取全局生产锁
final ReentrantLock putLock = this.putLock;
// count 用来维护元素计数
final AtomicInteger count = this.count;
// 获取可打断锁，会抛出异常
putLock.lockInterruptibly();
try {
// 队列满了等待
while (count.get() == capacity) {
// 【等待队列不满时，就可以生产数据】，线程处于 Waiting
notFull.await();
}
// 有空位, 入队且计数加一，尾插法
enqueue(node);
// 返回自增前的数字
c = count.getAndIncrement();
// put 完队列还有空位, 唤醒其他生产 put 线程，唤醒一个减少竞争
if (c + 1 < capacity)
notFull.signal();
} finally {
// 解锁
putLock.unlock();
}
// c自增前是0，说明生产了一个元素，唤醒一个 take 线程
if (c == 0)
signalNotEmpty();
}
private void signalNotEmpty() {
final ReentrantLock takeLock = this.takeLock;
takeLock.lock();
try {
// 调用 notEmpty.signal()，而不是 notEmpty.signalAll() 是为了减少竞争，因为只剩下一个元素
notEmpty.signal();
} finally {
takeLock.unlock();
}
}
- take 操作：
public E take() throws InterruptedException {
E x;
int c = -1;
// 元素个数
final AtomicInteger count = this.count;
// 获取全局消费锁
final ReentrantLock takeLock = this.takeLock;
// 可打断锁
takeLock.lockInterruptibly();
try {
// 没有元素可以出队
while (count.get() == 0) {
// 【阻塞等待队列不空，就可以消费数据】，线程处于 Waiting
notEmpty.await();
}
// 出队，计数减一，FIFO，出队头节点
x = dequeue();
// 返回自减前的数字
c = count.getAndDecrement();
// 队列还有元素
if (c > 1)
// 唤醒一个消费take线程
notEmpty.signal();
} finally {
takeLock.unlock();
}
// c 是消费前的数据，消费前满了，消费一个后还剩一个空位，唤醒生产线程
if (c == capacity)
// 调用的是 notFull.signal() 而不是 notFull.signalAll() 是为了减少竞争
signalNotFull();
return x;
}
性能比较
主要列举 LinkedBlockingQueue 与 ArrayBlockingQueue 的性能比较：
- Linked 支持有界，Array 强制有界
- Linked 实现是链表，Array 实现是数组
- Linked 是懒惰的，而 Array 需要提前初始化 Node 数组
- Linked 每次入队会生成新 Node，而 Array 的 Node 是提前创建好的
- Linked 两把锁，Array 一把锁
为什么不推荐内置线程池
Executors 返回线程池对象的弊端如下：
FixedThreadPool和SingleThreadExecutor:固定拥有多个或1个线程，使用的是阻塞队列 ，任务队列最大长度可以看作是无界的，可能堆积大量的请求，从而导致 OOM。CachedThreadPool:可扩容线程池，且全部都是救急线程 (60s 后可回收)，使用的是同步队列 ，允许创建的线程数量为Integer.MAX_VALUE，如果任务数量过多且执行速度较慢，可能会创建大量的线程，从而导致 OOM。ScheduledThreadPool和SingleThreadScheduledExecutor:使用的无界的延迟阻塞队列，任务队列最大长度为Integer.MAX_VALUE,可能堆积大量的请求，从而导致 OOM。
多大容量的线程池合适
- 一般来说池中总线程数是核心池线程数量两倍，确保当核心池有线程停止时，核心池外有线程进入核心池
- 过小会导致程序不能充分利用系统资源、容易导致饥饿
- 过大会导致更多的线程上下文切换，占用更多内存
ThreadPoolExecutor
核心构造函数
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
重要参数
- volatile int corePoolSize：核心线程数，线程池常驻的线程数量。
- volatile int maximumPoolSize：最大线程数（包括核心线程）。
- BlockingQueue workQueue：阻塞队列，用来存放等待执行的任务。
- volatile int keepAliveTime：非核心线程空闲多久会被销毁。
- volatile threadFactory：线程工厂，定制线程名称等。
- volatile handler：拒绝策略，任务满了之后怎么处理。
- unit：参数时间单位，针对非核心线程
核心线程会被回收吗
默认不会，为减少线程创建的开销，核心线程通常需要长期保持活跃。但是，如果线程池是被用于周期性使用的场景，且频率不高，可以考虑设置核心线程超时机制
工作原理
ThreadPoolExecutor 使用 int 的高 3 位来表示线程池状态，低 29 位表示线程数量。这些信息会存储在一个原子变量 CTL 中，目的是将线程池状态与线程个数合二为一，这样就可以用一次 CAS 原子操作进行赋值
四种状态
|
状态 |
高3位 |
接收新任务 |
处理阻塞任务队列 |
说明 |
|
RUNNING |
111 |
Y |
Y | |
|
SHUTDOWN |
000 |
N |
Y |
不接收新任务，但处理阻塞队列剩余任务 |
|
STOP |
001 |
N |
N |
中断正在执行的任务，并抛弃阻塞队列任务 |
|
TIDYING |
010 |
- |
- |
任务全执行完毕，活动线程为 0 即将进入终结 |
|
TERMINATED |
011 |
- |
- |
终止状态 |
核心线程空闲时处于什么状态
- 设置了核心线程的存活时间 ：核心线程在空闲时，会处于
WAITING状态，等待获取任务。如果阻塞等待的时间超过了核心线程存活时间，则该线程会退出工作，将该线程从线程池的工作线程集合中移除，线程状态变为TERMINATED状态。 - 没有设置核心线程的存活时间 ：核心线程在空闲时，会一直处于
WAITING状态，等待获取任务，核心线程会一直存活在线程池中
工作流程
- 线程池中刚开始没有线程，当一个任务提交给线程池后，线程池会创建一个新线程来执行任务。
- 当线程数达到 corePoolSize 并没有线程空闲，这时再加入任务，新加的任务会被加入workQueue 队列排队，直到有空闲的线程。
- 如果任务超过了队列大小时，会创建 maximumPoolSize - corePoolSize 数目的线程来救急。
- 如果线程到达 maximumPoolSize 仍然有新任务，这时会执行拒绝策略。拒绝策略 jdk 提供了 4 种实现，其它著名框架也提供了实现
- 当高峰过去后，超过corePoolSize 的救急线程如果一段时间没有任务做，需要结束，节省资源，这个时间由 keepAliveTime 和 unit 来控制
线程池在提交任务前，可以提前创建线程，实现线程池预热
prestartCoreThread():启动一个线程，等待任务，如果已达到核心线程数，这个方法返回 false，否则返回 true；
prestartAllCoreThreads():启动所有的核心线程，并返回启动成功的核心线程数。
拒绝策略
四种内置策略
AbortPolicy （中止策略） - 默认策略
- 直接抛出
RejectedExecutionException异常- **优点：**抛出异常后，提交任务的调用方可以捕获到这个异常，并做相应的处理
- **缺点：**如果处理不好，异常可能会向上扩散，导致整个服务链路中断。
CallerRunsPolicy （调用者运行策略）
- 将被拒绝的任务退回到调用者线程（即调用
execute方法的线程）来执行。（不允许丢弃任务首选策略）- 优点：
- 负反馈：调用者线程执行任务，会占用调用者线程的时间，从而降低其提交新任务的速度，形成一种负反馈
- **保证任务不丢失：**所有任务最终都会执行
- **缺点：**提交任务的线程会导致原本负责的工作被阻塞或变慢
DiscardPolicy （丢弃策略）
- 直接丢弃这个被拒绝的任务
- **优点：**不会又任何干扰
- **缺点：**无法感知任务被丢弃了，可能对业务产生影响
DiscardOldestPolicy （丢弃最老策略）
- 放弃队列中最早的任务，本任务取而代之
- **优点：**避免了新任务被丢弃。
- **缺点：**丢弃的任务可能会对业务产生影响
其他拒绝策略
- Dubbo 的实现，在抛出 RejectedExecutionException 异常之前会记录日志，并 dump 线程栈信息，方 便定位问题
- Netty 的实现，是创建一个新线程来执行任务
- ActiveMQ 的实现，带超时等待（60s）尝试放入队列，类似我们之前自定义的拒绝策略
- PinPoint 的实现，它使用了一个拒绝策略链，会逐一尝试策略链中每种拒绝策略
任务持久化
- 设计一张任务表将任务存储到 MySQL 数据库中。
- Redis 缓存任务。
- 将任务提交到消息队列中。
以方案一为例，自定义拒绝策略，将线程池中无法处理的任务入库，然后实现一个混合式阻塞队列，取任务时，优先从数据库中读取最早的任务，数据库中无任务时再去阻塞队列中取任务
线程池常用阻塞队列
- 容量为
Integer.MAX_VALUE的LinkedBlockingQueue（有界阻塞队列）：FixedThreadPool和SingleThreadExecutor。FixedThreadPool最多只能创建核心线程数的线程（核心线程数和最大线程数相等），SingleThreadExecutor只能创建一个线程（核心线程数和最大线程数都是 1），二者的任务队列永远不会被放满。 SynchronousQueue（同步队列）：CachedThreadPool。SynchronousQueue没有容量，不存储元素，目的是保证对于提交的任务，如果有空闲线程，则使用空闲线程来处理；否则新建一个线程来处理任务。也就是说，CachedThreadPool的最大线程数是Integer.MAX_VALUE，可以理解为线程数是可以无限扩展的，可能会创建大量线程，从而导致 OOM。DelayedWorkQueue（延迟队列）：ScheduledThreadPool和SingleThreadScheduledExecutor。DelayedWorkQueue的内部元素并不是按照放入的时间排序，而是会按照延迟的时间长短对任务进行排序，内部采用的是“堆”的数据结构，可以保证每次出队的任务都是当前队列中执行时间最靠前的。DelayedWorkQueue添加元素满了之后会自动扩容，增加原来容量的 50%，即永远不会阻塞，最大扩容可达Integer.MAX_VALUE，所以最多只能创建核心线程数的线程。ArrayBlockingQueue（有界阻塞队列）：底层由数组实现，容量一旦创建，就不能修改
扫一扫
1131
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
