线程池简介及其简单实现

如果需要频繁的创建销毁线程, 就需要想办法降低创建和销毁的开销, 而线程池就是一个很好的选择: 提前创建好一些线程, 等到需要使用线程的时候, 直接从池子里拿一个就好了, 当不再使用该线程时, 就放回到池子里.

那么此时就从 创建/销毁线程 -> 池子里取线程/将线程还到池子里

线程池最大的好处就使减少每次启动销毁线程的损耗.

为什么这样会更高效?

如果是从系统申请创建线程, 就需要调通系统api, 进一步由操作系统内核完成线程的创建过程.

如果从线程池里获取, 那么上述内核进行的操作都提前做好了, 取线程的过程就是纯用户态的了.

标准库中的线程池

public static void main(String[] args) {
    ExecutorService service = Executors.newFixedThreadPool(4);
    service.submit(new Runnable() {
        @Override
        public void run() {
            //
        }
    });
}
1
2
3
4
5
6
7
8
9

ExecutorService: 线程池对象

Executors.newFixedThreadPool(int nThreads): 创建固定线程数量的线程池

• Executors: 工厂类
• newFixedThreadPool(int nThreads): 工厂类方法 创建固定线程数量的线程池
• newCachedThreadPool(): 创建线程数量动态变化的线程池
• newSingleThreadExecutor(): 创建单个线程的线程池
• newScheduledThreadPool(int corePoolSize): 周期性线程池, 类似于定时器的效果
• 上面四个方法都是对类ThreadPoolExecutor的封装, ThreadPoolExecutor 提供了更多的可选参数, 可以进一步细化线程池行为的设定.

service.submit(Runnable task): 向线程池中添加任务.

工厂设计模式:

顾名思义, 工厂是用来成产的, 这里的工厂, 是用来生产对象的. 一般创建对象, 都是用过new, 构造方法来创建. 但是构造方法存在着重大缺陷.

什么缺陷—构造方法的名字必须是类名

为什么?

有的类需要多种不同的构造方法, 但是构造方法的名字是固定的, 那就只能使用方法重载的方式实现(参数的个数和类型有差别), 那么这样就会出现一定的问题.

例如, 有一个坐标点的类, 它有两种表示方法, 一个是笛卡尔坐标, 一个是极坐标. 但是我们写构造方法的时候, 却出现了问题, 明明想按照两种方法构造, 但是这两种方法参数的类型和个数是一样的, 无法构成重载.

class Point{
    private double x;
    private double y;
    public Point(double x, double y){}
    public Point(double r, double a){}
}
1
2
3
4
5
6

使用工厂模式就可以解决上述问题. 不使用构造方法, 使用普通的方法来构造对象, 这样方法名字就是任意的了, 在普通方法的内部new对象. 由于该方法的目的是创建对象, 所以这样的方法应该是静态的. 因为又要创建实例, 还要依赖实例, 这就很那啥.

class Point{
    private double x;
    private double y;
    private Point(double x, double y) {
        this.x = x;
        this.y = y;
    }
    public static Point makePointXY(double x, double y) {
        return new Point(x, y);
    }
    public static Point makePointRA(double r, double a) {
        return new Point(r, a);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

ThreadPoolExecutor

从这里可以看出该类有多种构造方法, 其中第四个构造方法的参数包含了以上三个, 那我们着重讲一下第四种构造方法.

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler)
1
2
3
4
5
6
7

int corePoolSize: 核心线程数

int maximumPoolSize: 最大线程数

• ThreadPoolExecutor里面的线程个数并非是固定不变的, 会根据当前任务的情况发生动态变化
• corePoolSize:至少要有这些数量的线程
• maximumPoolSize: 最多这些数量的线程

long keepAliveTime: 空闲线程的存活时间.

• 如果线程空闲的时间超过了该时间阈值, 那么该线程就会被销毁, 前提是线程数目不小于核心线程数.

TimeUnit unit: 时间单位

BlockingQueue workQueue: 管理线程池中的任务

• 线程池可以内置阻塞队列, 也可以手动指定一个阻塞队列, 这样就可以带些别的属性, 比如优先级等

ThreadFactory threadFactory: 线程工厂, 创建线程.

RejectedExecutionHandler handler: 拒绝方式/拒绝策略

• 当阻塞队列满了之后, 继续往里面添加任务, 该如何应对?

  

上述这些类就是Java提供的拒绝策略

ThreadPoolExecutor.AbortPolicy: 终止线程池, 直接抛出异常.

ThreadPoolExecutor.CallerRunsPolicy: 由添加新任务的线程去执行这个任务

ThreadPoolExecutor.DiscardOldestPolicy: 丢弃最早的任务, 去执行新的任务.

ThreadPoolExecutor.DiscardPolicy: 丢弃新的任务

线程池的实现

class MyThreadPool {
    //阻塞队列组织任务
    private BlockingQueue<Runnable> queue = new LinkedBlockingQueue<>();
    //添加任务到线程池中
    public void submit(Runnable runnable) throws InterruptedException {
        queue.put(runnable);
    }
    //构造方法, 创建n个线程. 固定数量的线程池.
    public MyThreadPool(int n) {
        for (int i = 0; i < n; i++) {
            Thread t = new Thread(() -> {
                while (true) {
                    try {
                        //取出任务并执行
                        Runnable runnable = queue.take();
                        runnable.run();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            });
            t.start();
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

创建线程池的时候, 线程的个数是如何确定的?

不同的项目中, 线程要做的工作是不一样的. 有的线程的工作, 是"CPU密集型", 大部分工作是要再CPU上完成的, 所以需要CPU安排核心才能进展工作, 那么这样的就不需要大量的线程, 因为线程再多也得需要CPU分配核心; 有的线程的工作是"IO密集型"(读写, 网络通信, 等待用户输入…), 这样的工作涉及大量等待的时间, 而等待的过程中是不需要CPU的, 所以就算线程多一些也不会给CPU造成多大负担.

实际开发中, 往往是一部分工作是CPU密集型, 一部分工作是IO密集的. 此时, 线程有几成是在CPU上运行, 有几成在等待IO也说不好. 此时就需要进一步实验才能找到合适的线程数. 进行性能测试, 尝试不同的线程数目.