线程池的作用
我们在用一个东西的时候,首先得搞明白一个问题。这玩意是干嘛的,为啥要用这个,用别的不行吗。那么一个一个解决这些问题
我们之前都用过数据库连接池,线程池的作用和连接池有点类似,频繁的创建,销毁线程会造成大量的不必要的性能开销,所以这个时候就出现了一个东西统一的管理线程,去负责线程啥时候销毁,啥时候创建,以及维持线程的状态,当程序需要使用线程的时候,直接从线程池拿,当程序用完了之后,直接把线程放回线程池,不需要去管线程的生命周期,专心的执行业务代码就行。
当然,如果非要是自己想手动new一个线程来执行,也不是不可以,只是像上面说的那样,第一麻烦,第二开销大,第三不好控制。
控制线程的方法
在说到线程池之前,首先要提到一个创建线程池的工具类,又或者说是工厂类 Executors
通过这个线程可以统一的创建线程,返回的是一个ExecutorService
类这个类中包含了一些对线程执行过程进行管理控制的方法;
-
void execute(Runnable command)
这个方法是将任务提交到线程池进行执行。这个方法没有返回值。 -
<T> Future<T> submit(Callable<T> task)
这个方法最特别的地方是线程执行完毕之后是有返回值的,返回值就存放于Future中,另外方法的参数可以用Callable
也可以为Runnable
。可以适用于一些后续的代码,需要线程执行结果的程序。
下面的示例中,我们创建了一个 ExecutorService 的实例,提交了一个任务,然后使用返回的 Future 的 get() 方法等待提交的任务完成并返回值。
Callable<String> c = new Callable() {
@Override
public String call() throws Exception {
return "Hello Callable";
}
};
ExecutorService service = Executors.newCachedThreadPool();
Future<String> future = service.submit(c); //异步
System.out.println(future.get());//阻塞
service.shutdown();
在实际使用时,我们并不会立即调用 future.get()
方法,可能会等待一些时间,推迟调用它直到我们需要它的值用于计算等目的。
ExecutorService
中的 submit()
方法被重载为支持 Runnable
或 Callable
,它们都是功能接口,可以接收一个 lambdas
作为参数( 从 Java 8 开始 ):
- 使用 Runnable 作为参数的方法不会抛出异常也不会返回任何值 ( 返回 void )
- 使用 Callable 作为参数的方法则可以抛出异常也可以返回值。
如果想让编译器将参数推断为 Callable
类型,只需要 lambda 返回一个值即可。
-
void shutdown()
在调用了shutdown方法之后,线程池就不会再接收新的任务,此时线程池还没有停止,仍然会把线程池中正在执行但是还没有执行完的任务继续执行完毕,那些没有开始执行的任务则被中断 -
List<Runnable> shutdownNow()
在调用了shutdownNow方法之后,会将线程池的状态设置为stop,正在执行的任务则被停止,没被执行任务的则返回。
这两种方法的使用场景:
- 如果线程中的任务相互之间没有什么关联某个线程的异常对结果影响不大。那么所有线程都能在执行任务结束之后可以正常结束,程序能在所有task都做完之后正常退出,适合用ShutDown。
- 如果一个线程在做某个任务的时候失败,则整个结果就是失败的,其他worker再继续做剩下的任务也是徒劳,这就需要让他们全部停止当前的工作。这里使用ShutDownNow就可以让该pool中的所有线程都停止当前的工作,从而迫使所有线程执行退出。从而让主程序正常退出。
自定义线程池
线程池在使用过程中大多数需要我们自定义
ThreadPoolExecutor tpe = new ThreadPoolExecutor(2, 4,
60, TimeUnit.SECONDS,
new ArrayBlockingQueue<Runnable>(4),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.CallerRunsPolicy());
定义线程池有7个参数,分别为:
corePoolSize
:线程池核心线程大小,线程池中会维护一个最小的线程数量,即使这些线程处理空闲状态,他们也不会被销毁,除非设置了allowCoreThreadTimeOut。maximumPoolSize
:线程池最大线程数量,一个任务被提交到线程池后,首先会缓存到工作队列中,如果工作队列满了,则会创建一个新线程,然后从工作队列中的取出一个任务交由新线程来处理,而将刚提交的任务放入工作队列。线程池不会无限制的去创建新线程,它会有一个最大线程数量的限制,这个数量即由maximunPoolSize来指定。keepAliveTime
:空闲线程存活时间,一个线程如果处于空闲状态,并且当前的线程数量大于corePoolSize,那么在指定时间后,这个空闲线程会被销毁,这里的指定时间keepAliveTime来设定unit
:空间线程存活时间单位,keepAliveTime的计量单位workQueue
:工作队列,新任务被提交后,会先进入到此工作队列中,任务调度时再从队列中取出任务。jdk中提供了四种工作队列:
①ArrayBlockingQueue
基于数组的有界阻塞队列,按FIFO排序。新任务进来后,会放到该队列的队尾,有界的数组可以防止资源耗尽问题。当线程池中线程数量达到corePoolSize后,再有新任务进来,则会将任务放入该队列的队尾,等待被调度。如果队列已经是满的,则创建一个新线程,如果线程数量已经达到maxPoolSize,则会执行拒绝策略。
②LinkedBlockingQuene
基于链表的无界阻塞队列(其实最大容量为Interger.MAX),按照FIFO排序。由于该队列的近似无界性,当线程池中线程数量达到corePoolSize后,再有新任务进来,会一直存入该队列,而不会去创建新线程直到maxPoolSize,因此使用该工作队列时,参数maxPoolSize其实是不起作用的。
③SynchronousQuene
一个不缓存任务的阻塞队列,生产者放入一个任务必须等到消费者取出这个任务。也就是说新任务进来时,不会缓存,而是直接被调度执行该任务,如果没有可用线程,则创建新线程,如果线程数量达到maxPoolSize,则执行拒绝策略。
④PriorityBlockingQueue
具有优先级的无界阻塞队列,优先级通过参数Comparator实现。threadFactory
:线程工厂,创建一个新线程时使用的工厂,可以用来设定线程名、是否为daemon线程等等//默认的线程工厂 private static class DefaultThreadFactory implements ThreadFactory { private static final AtomicInteger poolNumber = new AtomicInteger(1); private final ThreadGroup group; private final AtomicInteger threadNumber = new AtomicInteger(1); private final String namePrefix; DefaultThreadFactory() { SecurityManager s = System.getSecurityManager(); group = (s != null) ? s.getThreadGroup() : Thread.currentThread().getThreadGroup(); namePrefix = "pool-" + poolNumber.getAndIncrement() + "-thread-"; } public Thread newThread(Runnable r) { Thread t = new Thread(group, r, namePrefix + threadNumber.getAndIncrement(), 0); if (t.isDaemon()) t.setDaemon(false); if (t.getPriority() != Thread.NORM_PRIORITY) t.setPriority(Thread.NORM_PRIORITY); return t; } }
handler
:拒绝策略。当工作队列中的任务已到达最大限制,并且线程池中的线程数量也达到最大限制,这时如果有新任务提交进来,该如何处理呢。这里的拒绝策略,就是解决这个问题的,jdk中提供了4中拒绝策略:
①CallerRunsPolicy
该策略下,在调用者线程中直接执行被拒绝任务的run方法,除非线程池已经shutdown,则直接抛弃任务。
②AbortPolicy
该策略下,直接丢弃任务,并抛出RejectedExecutionException异常。
③DiscardPolicy
该策略下,直接丢弃任务,什么都不做。
④DiscardOldestPolicy
该策略下,抛弃进入队列最早的那个任务,然后尝试把这次拒绝的任务放入队列
Comments | 0 条评论