使用线程池时候，我们可能会使用下面四个场景，这在alibaba代码规范中都是明令禁止的
// 创建一个单线程化的Executor[因为数量固定，可能会堆积大量请求，导致OOM]
private static ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();
// 创建一个固定数目线程的线程池[因为数量固定，可能会堆积大量请求，导致OOM]
private static ExecutorService fixedThreadPool = Executors.newFixedThreadPool(10);
// 创建一个可执行命令的单线程Executor[可能会创建大量的线程，导致OOM]
private static ExecutorService singleThreadScheduledExecutor = Executors.newSingleThreadScheduledExecutor();
// 创建一个可缓存的线程池(60S存活时间)[可能会创建大量的线程，导致OOM]
private static ExecutorService cachedThreadPool = Executors.newCachedThreadPool();
我们先来一个简单的例子，模拟一下使用 Executors 导致 OOM 的情况。
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 参数：-Xmx8m -Xms8m 运行以上代码，会抛出 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)
以上代码指出，ExecutorsDemo.java 的第 16 行，就是代码中的 executor.execute(new SubThread());。
通过上面的例子，我们知道了 Executors 创建的线程池存在 OOM 的风险，那么到底是什么原因导致的呢？我们需要深入 Executors 的源码来分析一下。其实，在上面的报错信息中，我们是可以看出蛛丝马迹的，在以上的代码中其实已经说了，真正的导致 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());
}
如果读者对 Java 中的阻塞队列有所了解的话，看到这里或许就能够明白原因了。Java 中 的 BlockingQueue 主 要 有 两 种 实 现， 分 别 是 ArrayBlockingQueue 和 LinkedBlockingQueue。ArrayBlockingQueue 是一个用数组实现的有界阻塞队列，必须设置容量。LinkedBlockingQueue 是一个用链表实现的有界阻塞队列，容量可以选择进行设置，不设置的话，将是一个无边界的阻塞队列，最大长度为 Integer.MAX_VALUE。这里的问题就出在：不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE。也就是说，如果我们不设置 LinkedBlockingQueue 的容量的话，其默认容量将会是 Integer.MAX_VALUE。 而 newFixedThreadPool 中创建 LinkedBlockingQueue 时，并未指定容量。此时，LinkedBlockingQueue 就是一个无边界队列，对于一个无边界队列来说，是可以不断的向队列中加入任务的，这种情况下就有可能因为任务过多而导致内存溢出问题。上面提到的问题主要体现在 newFixedThreadPool 和 newSingleThreadExecutor 两个工厂方法上，并不是说newCachedThreadPool 和 newScheduledThreadPool 这两个方法就安全了，这两种方式创建的最大线程数可能是Integer.MAX_VALUE，而创建这么多线程，必然就有可能导致 OOM
正确使用：
private static ExecutorService executor = new ThreadPoolExecutor(10, 10, 60L, TimeUnit.SECONDS,
new ArrayBlockingQueue(10));
这种情况下，一旦提交的线程数超过当前可用线程数时，就会抛出java.util.concurrent.RejectedExecutionException，这是因为当前线程池使用的队列是有边界队列，队列已经满了便无法继续处理新的请求。但是异常（Exception）总比发生错误（Error）要好。
但是部分alibaba作者更推荐使用guava创建对应的线程池，示例如下：
public class ExecutorsDemo {
private static ThreadFactory namedThreadFactory = new
ThreadFactoryBuilder()
.setNameFormat("demo-pool-%d").build();
private static ExecutorService pool = new ThreadPoolExecutor(5, 200,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue(1024), namedThreadFactory, new
ThreadPoolExecutor.
AbortPolicy());
public static void main(String[] args) {
for (int i = 0; i < Integer.MAX_VALUE; i++) {
pool.execute(new SubThread());
}
}
}
通过上述方式创建线程时，不仅可以避免 OOM 的问题，还可以自定义线程名称，更加方便的出错的时候溯源。
