手动创建线程:
频繁创建销毁开销大,疯狂抢占资源混乱,出错概率大。
线程池创建线程
很好的管理线程,复用线程,合理高效运用资源
我们创建 10000 个线程,做同样一件事。接下来来比较手动创建线程和线程池创建线程的运行时间。
代码如下:
public class ThreadTest {
public static void main(String[] args) throws InterruptedException {
long start = System.currentTimeMillis();
final Random random = new Random();
final List<Integer> list = new ArrayList();
for(int i=0;i<10000;i++){
Thread thread = new Thread(){
@Override
public void run() {
list.add(random.nextInt());
}
};
thread.start();
thread.join();
}
System.out.println("时间:" + (System.currentTimeMillis() - start));
System.out.println("大小:" + list.size());
}
}
运行时间 2120 毫秒,如下图
public class ThreadPoolTest {
public static void main(String[] args) throws InterruptedException {
long start = System.currentTimeMillis();
final Random random = new Random();
final List<Integer> list = new ArrayList();
ExecutorService executorService = Executors.newSingleThreadExecutor();
for(int i=0;i<10000;i++){
executorService.execute(new Runnable() {
@Override
public void run() {
list.add(random.nextInt());
}
});
}
executorService.shutdown();
// executorService.awaitTermination(1, TimeUnit.DAYS);
System.out.println("时间:" + (System.currentTimeMillis() - start));
System.out.println("大小:" + list.size());
}
}
运行时间 11 毫秒,如下图:
由于线程池工具类里面都是实例化线程池执行器,接下来看下线程池执行器的构造方法。如下图:
拒绝策略一共有 4 种,如下图:
这个线程池工具类为 java.util.concurrent.Executors,该工具类提供了很多创建线程池的方法,如下图:
单线程。核心线程数量为 1,总线程数量也为 1,即,非核心线程数量为 0。处理队列也使用了 LinkedBlockingQueue,同样也可能会导致内存溢出
定时任务线程。点进去看其参数 ScheduledThreadPoolExecutor,如下
又调用了父类构造器,其父类就是线程池执行器,如下图:
我们发现调用父类构造器时 super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
new DelayedWorkQueue()); 第二个参数也是 Integer.MAX_VALUE,同样也可能会导致内存溢出。
为了很好说明线程池内部线程分配情况,我们把线程池当作一个公司,一个线程当作一个员工。如下图左边灰色背景部分。
有本司员工(核心线程),数量为:corePoolSize
有一个仓库(处理队列)
外包员工(非核心线程),员工总数为:maximumPoolSize
假如我们现在创建好了一个线程池 MyThreadPool,如上图右边紫色背景部分。现在有 15 个任务需要处理,一个员工只能处理一个任务。那么:
处理任务,分配线程情况如下图:
线程池处理流程示意图:
对应源码如下:
java.util.concurrent#execute(Runnable command)
代码调用时序图如下:
现创建一个线程池有核心线程 5 个,悬挂队列容量 5,非核心线程 5 个。按照线程池提交流程分析,应该:
先 1~5 个任务交给前 5 个线程;
然后 6~10 个任务放到队列里面;
最后 11~15 个任务交给非核心线程;
这 3 组任务的提交顺序:先是 1~5 任务、再是 6~10 任务、最后 11~15 任务。那么其重写的 run 方法的执行顺序应该也是这样的。事实上真的如此吗?
代码示例如下:
执行结果:
我们发现中间 5 个任务竟然是最后执行的!按照我们上面的分析中间 5 个任务应该是紧接着前 5 个任务执行后执行。这是怎么回事呢?
原来上面我们分析的是线程池的提交优先级(提交顺序),控制台日志展示的执行优先级(执行顺序)。
这个执行流程到底在那控制着呢?我们根据代码从头开始捋下:
java.util.concurrent.ThreadPoolExecutor#execute(Runnable command)方法
从上图可以看到,核心线程与非核心线程 addWorker 时传的第一个参数 command,即,任务不为空。队列这种情况 addWorker 时上传的任务为 null。接着看 addWorker 方法。
java.util.concurrent.ThreadPoolExecutor#addWorker(Runnable firstTask, boolean core)方法
也就是说核心线程、非核心线程情况时上次的 firstTask 不为 null,队列情况时上传的 firstTask 为 null。接着看 Workder 类。
private final class Worker extends AbstractQueuedSynchronizer implements Runnable{}
接着查看 runWorker 方法。
java.util.concurrent.ThreadPoolExecutor#runWorker(Worker w)
注意看红框中这行代码,已知核心线程、非核心线程情况时上次的 firstTask 不为 null,队列情况时上传的 firstTask 为 null。
再来看蓝色框中代码,也就是当核心线程、非核心线程都为空,即,处理完后,这个 task 才能为 null。
当 task==null 时,去执行 getTask,来看下该方法 java.util.concurrent.ThreadPoolExecutor#getTask()
可见该方法中是从队列 workQueue 中获取的任务。
最后看绿色框(上上幅图)中的 task.run(),就去执行我们刚开始重写的 run()方法了。
这个就是线程池的执行优先级了。