如果需要频繁的创建销毁线程, 就需要想办法降低创建和销毁的开销, 而线程池就是一个很好的选择: 提前创建好一些线程, 等到需要使用线程的时候, 直接从池子里拿一个就好了, 当不再使用该线程时, 就放回到池子里.
那么此时就从 创建/销毁线程 -> 池子里取线程/将线程还到池子里
线程池最大的好处就使减少每次启动销毁线程的损耗.
为什么这样会更高效?
如果是从系统申请创建线程, 就需要调通系统api, 进一步由操作系统内核完成线程的创建过程.
如果从线程池里获取, 那么上述内核进行的操作都提前做好了, 取线程的过程就是纯用户态的了.
标准库中的线程池
public static void main(String[] args) {
ExecutorService service = Executors.newFixedThreadPool(4);
service.submit(new Runnable() {
@Override
public void run() {
//
}
});
}
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){} }使用工厂模式就可以解决上述问题. 不使用构造方法, 使用普通的方法来构造对象, 这样方法名字就是任意的了, 在普通方法的内部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); } }
ThreadPoolExecutor
从这里可以看出该类有多种构造方法, 其中第四个构造方法的参数包含了以上三个, 那我们着重讲一下第四种构造方法.
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
int corePoolSize: 核心线程数
int maximumPoolSize: 最大线程数
ThreadPoolExecutor里面的线程个数并非是固定不变的, 会根据当前任务的情况发生动态变化corePoolSize:至少要有这些数量的线程maximumPoolSize: 最多这些数量的线程
long keepAliveTime: 空闲线程的存活时间.
- 如果线程空闲的时间超过了该时间阈值, 那么该线程就会被销毁, 前提是线程数目不小于核心线程数.
TimeUnit unit: 时间单位
BlockingQueue<Runnable> 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();
}
}
}
创建线程池的时候, 线程的个数是如何确定的?
不同的项目中, 线程要做的工作是不一样的. 有的线程的工作, 是"CPU密集型", 大部分工作是要再CPU上完成的, 所以需要CPU安排核心才能进展工作, 那么这样的就不需要大量的线程, 因为线程再多也得需要CPU分配核心; 有的线程的工作是"IO密集型"(读写, 网络通信, 等待用户输入…), 这样的工作涉及大量等待的时间, 而等待的过程中是不需要CPU的, 所以就算线程多一些也不会给CPU造成多大负担.
实际开发中, 往往是一部分工作是CPU密集型, 一部分工作是IO密集的. 此时, 线程有几成是在CPU上运行, 有几成在等待IO也说不好. 此时就需要进一步实验才能找到合适的线程数. 进行性能测试, 尝试不同的线程数目.
