标签:thread 自身 服务端 asc caller link dfa 上下文 有用
为什么引入线程池技术?
对于服务端的程序,经常面对的是执行时间较短、工作内容较为单一的任务,需要服务端快速处理并返回接口。假若服务端每次接收到一个任务,就创建一个线程,然后执行,这种方式在原型阶段是不错的选择,但是面对成千上万的任务提交进服务器时,这个时候将会创建数以万记的线程,这很明显不是一个好的选择。为什么呢?
- 第一,频繁的线程切换会使操作系统频繁的进行上下文切换,增加了系统的负载;
- 第二,线程的创建和销毁是需要耗费系统资源的,这样子很明显浪费了系统资源。
线程池技术很好的解决了这个问题,它预先创建一定数量的线程,用户不能直接控制线程的创建和销毁,重复使用固定或者较为固定数目的线程来完成任务的执行。这样做的好处:
- 消除了频繁创建和销毁线程的系统资源开销;
- 面对过量任务的提交能够平缓劣化。
在看具体的源码之前,先给一个线程池使用案例
executor.submit(Runnable task)
提交10个任务;executor.submit(Callable<T> task)
提交5个任务;public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
RejectedExecutionHandler handler) {
this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, Executors.defaultThreadFactory(), handler);}
核心参数:
- corePoolSize
:核心线程数,线程池里一直不会被销毁的线程数量;
- maximumPoolSize
:最大线程数量;
- keepAliveTime
:非核心线程空闲时的存活时间,该参数只有在线程数量 > corePoolSize情况下才有用;
- unit
:keepAlive时间单位;
- workQueue
:工作队列,JDK提供这几种工作队列:
ArrayBlockingQueue
:基于数组的有界阻塞队列,任务以FIFO顺序排序;LinkedBlockingQueue
:基于链表的阻塞队列,任务以FIFO顺序排列,吞吐量优于ArrayBlockingQueue,在使用时需要注意,此阻塞队列在不设置大小的时候,默认的长度是Integer.MAX_VALUE
;PriorityBlockingQueue
:类似于LinkedBlockQueue,但其所含任务的排序不是FIFO,而是依据任务的自然排序顺序或者是构造函数的Comparator决定的顺序;SynchronousQueue
:特殊的BlockingQueue,对其的操作必须是放和取交替完成的,典型的生产者-消费者模型,它不存储元素,每一次的插入必须要等另一个线程的移除操作完成。 threadFactory
:创建线程工厂,可以自定义线程工厂给线程池里的线程设置一个自定义线程名。 handler
:饱和策略,假如线程池已满,并且没有空闲的线程,这个时候不再允许提交任务到线程池,线程池提供了4中策略,至于具体采用哪种策略还是自定义策略,具体情况具体分析。AbortPolicy
:拒绝提交,直接抛出异常,也是默认的饱和策略;CallerRunsPolicy
:线程池还未关闭时,用调用者的线程执行任务;DiscardPolicy
:丢掉提交任务;DiscardOldestPolicy
:线程池还未关闭时,丢掉阻塞队列最久为处理的任务,并且执行当前任务。线程池用ctl的低29位表示线程池中的线程数,高3位表示当前线程状态,后续假如想要增大这个值,可以将AtomicInteger改成AtomicLong。
- RUNNING:运行状态,高3位为111;
- SHUTDOWN:关闭状态,高3位为000,在此状态下,线程池不再接受新任务,但是仍然处理阻塞队列中的任务;
- STOP:停止状态,高3位为001,在此状态下,线程池不再接受新任务,也不会处理阻塞队列中的任务,正在运行的任务也会停止;
- TIDYING:高3位为010;
- TERMINATED:终止状态,高3位为011。
接下来就以submit
方法入手,分析一下相关源码。
public Future<?> submit(Runnable task) {
//提交的task为null,抛出空指针异常
if (task == null)
throw new NullPointerException();
RunnableFuture<Void> ftask = newTaskFor(task, null);
//执行任务
execute(ftask);
return ftask;
}
整个任务的提交核心都在任务执行这部分,执行任务,拿到返回值。
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
} else if (!addWorker(command, false))
reject(command);
}
具体的执行流程如下:
- 通过workerCountOf
计算出当前线程池的线程数,如果线程数小于corePoolSize
,执行addWork
方法创建新的线程执行任务;
- 如果当前线程池线程数大于coreSize
,向队列里添加task,不继续增加线程;
- 当workQueue.offer
失败时,也就是说现在队列已满,不能再向队列里放,此时工作线程大于等于corePoolSize
,创建新的线程执行该task;
- 执行addWork
失败,执行reject
方法处理该任务。
总结一下,对于使用线程池的外部来说,线程池的机制是这样的:
1. 如果正在运行的线程数 < coreSize
,马上创建线程执行该task,不排队等待;
2. 如果正在运行的线程数 >= coreSize
,把该task放入队列;
3. 如果队列已满 && 正在运行的线程数 < maximumPoolSize
,创建新的线程执行该task;
4. 如果队列已满 && 正在运行的线程数 >= maximumPoolSize
,线程池调用handler的reject方法拒绝本次提交。
从全局来看,ThreadPoolExcutor一定维护一个池:
addWorker的实质是向该HashSet里add一个worker,worker有一个线程,这个线程执行完成时,会从该HashSet里remove掉。
看一下addWorker的具体代码实现:
这只是addWorker的前半部分代码,首先,判断当前线程的状态是否符合条件,不符合条件不做处理直接返回;通过参数core判断当前线程是否为核心线程,如果是核心线程,跳出循环创建新的线程来执行该task,在break retry的时候会执行compareAndIncrementWorkerCount(c)
,利用CAS原则,将线程数量+1。
看看创建线程部分(addWorker的后半部分)代码实现:
创建线程部分最核心的操作就是:new一个新的worker,add进HashSet,然后启动woker里的Thread。
从源码可以看到,在执行add之前先活取了mainLock锁,该锁是一个公用的可重入锁:
private final ReentrantLock mainLock = new ReentrantLock();
addWorker(command, true)
addWorker(command, false)
addWorker(null, false)
addWorker(null, true)
prestartCoreThread()
等方法,有兴趣的读者可以自行阅读,在此不做详细赘述。在addWorker中,t.start()
使线程就绪,我们来看看Worker类的具体设计。
- Worker继承AbstractQueuedSynchronizer
,方便实现工作线程的中止等操作;
- Worker实现Runnable
接口,将自身作为一个task在工作线程中执行;
addWoker中的t.start()
实质上是执行Worker的run()
方法:
public void run() {
runWorker(this);
}
run方法主要干了一件事,调用runWorker(this)
,接下来我们来看看runWorker的具体实现。
beforeExecute
和afterExecute
;private Runnable getTask() {
boolean timedOut = false;
for (;;) {
int c = ctl.get();
int rs = runStateOf(c);
//必要情况下需要检查workQueue是否为空
if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) {
decrementWorkerCount();
return null;
}
int wc = workerCountOf(c);
//如果线程池允许线程超时或者当前线程数大于核心线程数,则会进行超时处理
boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;
if ((wc > maximumPoolSize || (timed && timedOut)) && (wc > 1 || workQueue.isEmpty())) {
if (compareAndDecrementWorkerCount(c))
return null;
continue;
}
try {
Runnable r = timed ? workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) : workQueue.take();
if (r != null)
return r;
timedOut = true;
} catch (InterruptedException retry) {
timedOut = false;
}
}
}
整个getTask循环实现:
- workQueue.poll:如果在keepAliveTime时间内阻塞队列有任务,返回该任务并执行;
- workQueue.take:如果阻塞队列为空,当前线程阻塞,当队列有任务时,线程被唤醒,执行take返回的任务。
标签:thread 自身 服务端 asc caller link dfa 上下文 有用
原文地址:http://blog.csdn.net/u010185262/article/details/53607203