【小家java】java5新特性(简述十大新特性) 重要一跃
【小家java】java6新特性(简述十大新特性) 鸡肋升级
【小家java】java7新特性(简述八大新特性) 不温不火
【小家java】java8新特性(简述十大新特性) 饱受赞誉
【小家java】java9新特性(简述十大新特性) 褒贬不一
【小家java】java10新特性(简述十大新特性) 小步迭代
【小家java】java11新特性(简述八大新特性) 首个重磅LTS版本java
【小家java】Java中的线程池,你真的用对了吗?(教你用正确的姿式使用线程池)
小家Java】一次Java线程池误用(newFixedThreadPool)引起的线上血案和总结
【小家java】BlockingQueue阻塞队列详解以及5大实现(ArrayBlockingQueue、DelayQueue、LinkedBlockingQueue…)
【小家java】用 ThreadPoolExecutor/ThreadPoolTaskExecutor 线程池技术提升系统吞吐量(附带线程池参数详解和使用注意事项)web
在【小家java】用 ThreadPoolExecutor/ThreadPoolTaskExecutor 线程池技术提升系统吞吐量(附带线程池参数详解和使用注意事项)这篇文章中,咱们介绍过了Java中线程池的常见用法以及基本原理。缓存
在文中末尾有这样一句描述:安全
能够经过Executors静态工厂构建线程池,但通常不建议这样使用。多线程
关于这个问题,在那篇文章中并无深刻的展开。之因此这么说,是由于这种建立线程池的方式有很大的隐患,稍有不慎就有可能致使线上故障,如:【小家Java】一次Java线程池误用(newFixedThreadPool)引起的线上血案和总结ide
本文咱们就来围绕这个问题来分析一下为何JDK自身提供的构建线程池的方式并不建议使用?到底应该如何建立一个线程池呢?svg
Executors 是一个Java中的工具类。提供工厂方法来建立不一样类型的线程池。
从上图中也能够看出,Executors的建立线程池的方法,建立出来的线程池都实现了ExecutorService接口。经常使用方法有如下几个:
newFiexedThreadPool(int Threads)
:建立固定数目线程的线程池。
newCachedThreadPool()
:建立一个可缓存的线程池,调用execute 将重用之前构造的线程(若是线程可用)。若是没有可用的线程,则建立一个新线程并添加到池中。终止并从缓存中移除那些已有 60 秒钟未被使用的线程。
newSingleThreadExecutor()
:建立一个单线程化的Executor。
newScheduledThreadPool(int corePoolSize)
:建立一个支持定时及周期性的任务执行的线程池,多数状况下可用来替代Timer类。函数
此类看起来功能仍是比较强大的,又用到了工厂模式、又有比较强的扩展性,重要的是用起来还比较方便,如:工具
ExecutorService executor = Executors.newFixedThreadPool(nThreads) ;
我提到的是『不建议』,可是在阿里巴巴Java开发手册
中也明确指出,并且用的词是『不容许』使用Executors建立线程池。
阿里巴巴的规范手册里面说的是严令禁止使用的。所以,你们也能够彻底的遵照一下吧spa
public class ExecutorsDemo { private static ExecutorService executor = Executors.newFixedThreadPool(15); public static void main(String[] args) { for (int i = 0; i < Integer.MAX_VALUE; i++) { executor.execute(new SubThread()); } } } class SubThread implements Runnable { @Override public void run() { try { Thread.sleep(10000); } catch (InterruptedException e) { //do nothing } } }
经过指定JVM参数:-Xmx10m -Xms10m 运行以上代码,很快会抛出OOM:
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371) at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)
其实,在上面的报错信息中,咱们是能够看出蛛丝马迹的,在以上的代码中其实已经说了,真正的致使OOM的实际上是LinkedBlockingQueue.offer方法。
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371) at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)
若是读者翻看代码的话,也能够发现,其实底层确实是经过LinkedBlockingQueue
实现的:
public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());
若是咱们不设置LinkedBlockingQueue
的容量的话,其默认容量将会是Integer.MAX_VALUE
。所以是个无界队列
上面提到的问题主要体如今newFixedThreadPool和newSingleThreadExecutor两个工厂方法上,并非说newCachedThreadPool和newScheduledThreadPool这两个方法就安全了,这两种方式建立的最大线程数多是Integer.MAX_VALUE,而建立这么多线程,必然就有可能致使OOM。
避免使用Executors建立线程池,主要是避免使用其中的默认实现,那么咱们能够本身直接调用ThreadPoolExecutor的构造函数来本身建立线程池。在建立的同时,给BlockQueue指定容量就能够了。
private static ExecutorService executor = new ThreadPoolExecutor(10, 10, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(10));
这种状况下,一旦提交的线程数超过当前可用线程数时,就会抛出java.util.concurrent.RejectedExecutionException
,这是由于当前线程池使用的队列是有边界队列,队列已经满了便没法继续处理新的请求。可是异常(Exception)总比发生错误(Error)要好。
线程池的使用不当,可能致使服务的宕机,严重状况更有可能形成雪崩。
既然连《阿里巴巴Java开发手册》
这么权威的手册都明文禁止使用Executors了,那么但愿你们之后尽可能少用,甚至不用吧。
这种参数,显示指定确定比隐式的来得更加安全的,当心哟~