前言
大家好，我是捡田螺的小男孩。
日常开发中，为了更好管理线程资源，减少创建线程和销毁线程的资源损耗，我们会使用线程池来执行一些异步任务。但是线程池使用不当，就可能会引发生产事故。今天田螺哥跟大家聊聊线程池的10个坑。大家看完肯定会有帮助的~
-
线程池默认使用无界队列，任务过多导致oom
-
线程创建过多，导致oom
-
共享线程池，次要逻辑拖垮主要逻辑
-
线程池拒绝策略的坑
-
spring内部线程池的坑
-
使用线程池时，没有自定义命名
-
线程池参数设置不合理
-
线程池异常处理的坑
-
使用完线程池忘记关闭
-
threadlocal与线程池搭配，线程复用，导致信息错乱。
1.线程池默认使用无界队列，任务过多导致oom
jdk开发者提供了线程池的实现类，我们基于executors组件，就可以快速创建一个线程池。日常工作中，一些小伙伴为了开发效率，反手就用executors新建个线程池。写出类似以下的代码：
/**
* 公众号；捡田螺的小男孩
*/
public class newfixedtest {
public static void main(string[] args) {
executorservice executor = executors.newfixedthreadpool(10);
for (int i = 0; i < integer.max_value; i ) {
executor.execute(() -> {
try {
thread.sleep(10000);
} catch (interruptedexception e) {
//do nothing
}
});
}
}
}
使用newfixedthreadpool创建的线程池，是会有坑的，它默认是无界的阻塞队列，如果任务过多，会导致oom问题。 运行一下以上代码，出现了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.example.dto.newfixedtest.main(newfixedtest.java:14)
这是因为newfixedthreadpool使用了无界的阻塞队列的linkedblockingqueue，如果线程获取一个任务后，任务的执行时间比较长(比如，上面demo代码设置了10秒)，会导致队列的任务越积越多，导致机器内存使用不停飙升， 最终出现oom。
看下newfixedthreadpool的相关源码，是可以看到一个无界的阻塞队列的，如下：
//阻塞队列是linkedblockingqueue，并且是使用的是无参构造函数
public static executorservice newfixedthreadpool(int nthreads) {
return new threadpoolexecutor(nthreads, nthreads,
0l, timeunit.milliseconds,
new linkedblockingqueue());
}
//无参构造函数，默认最大容量是integer.max_value，相当于无界的阻塞队列的了
public linkedblockingqueue() {
this(integer.max_value);
}
因此，工作中，建议大家自定义线程池，并使用指定长度的阻塞队列。
2. 线程池创建线程过多，导致oom
有些小伙伴说，既然executors组件创建出的线程池newfixedthreadpool，使用的是无界队列，可能会导致oom。那么，executors组件还可以创建别的线程池，如newcachedthreadpool，我们用它也不行嘛？
我们可以看下newcachedthreadpool的构造函数：
public static executorservice newcachedthreadpool() {
return new threadpoolexecutor(0, integer.max_value,
60l, timeunit.seconds,
new synchronousqueue());
}
它的最大线程数是integer.max_value。大家应该意识到使用它，可能会引发什么问题了吧。没错，如果创建了大量的线程也有可能引发oom！
笔者在以前公司，遇到这么一个oom问题：一个第三方提供的包，是直接使用
new thread实现多线程的。在某个夜深人静的夜晚，我们的监控系统报警了。。。这个相关的业务请求瞬间特别多，监控系统告警oom了。
所以我们使用线程池的时候，还要当心线程创建过多，导致oom问题。大家尽量不要使用newcachedthreadpool，并且如果自定义线程池时，要注意一下最大线程数。
3. 共享线程池，次要逻辑拖垮主要逻辑
要避免所有的业务逻辑共享一个线程池。比如你用线程池a来做登录异步通知，又用线程池a来做对账。如下图：
如果对账任务checkbillservice响应时间过慢，会占据大量的线程池资源，可能直接导致没有足够的线程资源去执行loginnotifyservice的任务，最后影响登录。就这样，因为一个次要服务，影响到重要的登录接口，显然这是绝对不允许的。因此，我们不能将所有的业务一锅炖，都共享一个线程池，因为这样做，风险太高了，犹如所有鸡蛋放到一个篮子里。应当做线程池隔离！
4. 线程池拒绝策略的坑，使用不当导致阻塞
我们知道线程池主要有四种拒绝策略，如下：
-
abortpolicy: 丢弃任务并抛出
rejectedexecutionexception异常。(默认拒绝策略) -
discardpolicy：丢弃任务，但是不抛出异常。
-
discardoldestpolicy：丢弃队列最前面的任务，然后重新尝试执行任务。
-
callerrunspolicy：由调用方线程处理该任务。
如果线程池拒绝策略设置不合理，就容易有坑。我们把拒绝策略设置为discardpolicy或discardoldestpolicy并且在被拒绝的任务，future对象调用get()方法,那么调用线程会一直被阻塞。
我们来看个demo：
/**
* 关注公众号：捡田螺的小男孩
*/
public class discardthreadpooltest {
public static void main(string[] args) throws executionexception, interruptedexception {
// 一个核心线程，队列最大为1，最大线程数也是1.拒绝策略是discardpolicy
threadpoolexecutor executorservice = new threadpoolexecutor(1, 1, 1l, timeunit.minutes,
new arrayblockingqueue<>(1), new threadpoolexecutor.discardpolicy());
future f1 = executorservice.submit(()-> {
system.out.println("提交任务1");
try {
thread.sleep(3000);
} catch (interruptedexception e) {
e.printstacktrace();
}
});
future f2 = executorservice.submit(()->{
system.out.println("提交任务2");
});
future f3 = executorservice.submit(()->{
system.out.println("提交任务3");
});
system.out.println("任务1完成 " f1.get());// 等待任务1执行完毕
system.out.println("任务2完成" f2.get());// 等待任务2执行完毕
system.out.println("任务3完成" f3.get());// 等待任务3执行完毕
executorservice.shutdown();// 关闭线程池，阻塞直到所有任务执行完毕
}
}
运行结果：一直在运行中。。。
这是因为discardpolicy拒绝策略，是什么都没做，源码如下：
public static class discardpolicy implements rejectedexecutionhandler {
/**
* creates a {@code discardpolicy}.
*/
public discardpolicy() { }
/**
* does nothing, which has the effect of discarding task r.
*/
public void rejectedexecution(runnable r, threadpoolexecutor e) {
}
}
我们再来看看线程池 submit 的方法：
public future submit(runnable task) {
if (task == null) throw new nullpointerexception();
//把runnable任务包装为future对象
runnablefuture ftask = newtaskfor(task, null);
//执行任务
execute(ftask);
//返回future对象
return ftask;
}
public futuretask(runnable runnable, v result) {
this.callable = executors.callable(runnable, result);
this.state = new; //future的初始化状态是new
}
我们再来看看future的get() 方法
//状态大于completing，才会返回，要不然都会阻塞等待
public v get() throws interruptedexception, executionexception {
int s = state;
if (s <= completing)
s = awaitdone(false, 0l);
return report(s);
}
futuretask的状态枚举
private static final int new = 0;
private static final int completing = 1;
private static final int normal = 2;
private static final int exceptional = 3;
private static final int cancelled = 4;
private static final int interrupting = 5;
private static final int interrupted = 6;
阻塞的真相水落石出啦，futuretask的状态大于completing才会返回，要不然都会一直阻塞等待。又因为拒绝策略啥没做，没有修改futuretask的状态，因此futuretask的状态一直是new，所以它不会返回，会一直等待。
这个问题，可以使用别的拒绝策略，比如callerrunspolicy，它让主线程去执行拒绝的任务，会更新futuretask状态。如果确实想用discardpolicy，则需要重写discardpolicy的拒绝策略。
温馨提示，日常开发中，使用 future.get() 时，尽量使用带超时时间的，因为它是阻塞的。
future.get(1, timeunit.seconds);
难道使用别的拒绝策略，就万无一失了嘛？ 不是的，如果使用callerrunspolicy拒绝策略，它表示拒绝的任务给调用方线程用，如果这是主线程，那会不会可能也导致主线程阻塞呢？总结起来，大家日常开发的时候，多一份心眼把，多一点思考吧。
5. spring内部线程池的坑
工作中，个别开发者，为了快速开发，喜欢直接用spring的@async，来执行异步任务。
@async
public void testasync() throws interruptedexception {
system.out.println("处理异步任务");
timeunit.seconds.sleep(new random().nextint(100));
}
spring内部线程池，其实是simpleasynctaskexecutor，这玩意有点坑，它不会复用线程的，它的设计初衷就是执行大量的短时间的任务。有兴趣的小伙伴，可以去看看它的源码：
/** * {@link taskexecutor} implementation that fires up a new thread for each task, * executing it asynchronously. * *supports limiting concurrent threads through the "concurrencylimit" * bean property. by default, the number of concurrent threads is unlimited. * *
note: this implementation does not reuse threads! consider a * thread-pooling taskexecutor implementation instead, in particular for * executing a large number of short-lived tasks. * * @author juergen hoeller * @since 2.0 * @see #setconcurrencylimit * @see synctaskexecutor * @see org.springframework.scheduling.concurrent.threadpooltaskexecutor * @see org.springframework.scheduling.commonj.workmanagertaskexecutor */ @suppresswarnings("serial") public class simpleasynctaskexecutor extends customizablethreadcreator implements asynclistenabletaskexecutor, serializable { ...... }
也就是说来了一个请求，就会新建一个线程！大家使用spring的@async时，要避开这个坑，自己再定义一个线程池。正例如下：
@bean(name = "threadpooltaskexecutor")
public executor threadpooltaskexecutor() {
threadpooltaskexecutor executor=new threadpooltaskexecutor();
executor.setcorepoolsize(5);
executor.setmaxpoolsize(10);
executor.setthreadnameprefix("tianluo-%d");
// 其他参数设置
return new threadpooltaskexecutor();
}
6. 使用线程池时，没有自定义命名
使用线程池时，如果没有给线程池一个有意义的名称，将不好排查回溯问题。这不算一个坑吧，只能说给以后排查埋坑，哈哈。我还是单独把它放出来算一个点，因为个人觉得这个还是比较重要的。反例如下：
/**
* 关注公众号：捡田螺的小男孩
*/
public class threadtest {
public static void main(string[] args) throws exception {
threadpoolexecutor executorone = new threadpoolexecutor(5, 5, 1,
timeunit.minutes, new arrayblockingqueue(20));
executorone.execute(()->{
system.out.println("关注公众号：捡田螺的小男孩");
throw new nullpointerexception();
});
}
}
运行结果：
关注公众号：捡田螺的小男孩
exception in thread "pool-1-thread-1" java.lang.nullpointerexception
at com.example.dto.threadtest.lambda$main$0(threadtest.java:17)
at java.util.concurrent.threadpoolexecutor.runworker(threadpoolexecutor.java:1149)
at java.util.concurrent.threadpoolexecutor$worker.run(threadpoolexecutor.java:624)
at java.lang.thread.run(thread.java:748)
可以发现，默认打印的线程池名字是pool-1-thread-1，如果排查问题起来，并不友好。因此建议大家给自己线程池自定义个容易识别的名字。其实用customizablethreadfactory即可，正例如下：
public class threadtest {
public static void main(string[] args) throws exception {
threadpoolexecutor executorone = new threadpoolexecutor(5, 5, 1,
timeunit.minutes, new arrayblockingqueue(20),new customizablethreadfactory("tianluo-thread-pool"));
executorone.execute(()->{
system.out.println("关注公众号：捡田螺的小男孩");
throw new nullpointerexception();
});
}
}
7. 线程池参数设置不合理
线程池最容易出坑的地方，就是线程参数设置不合理。比如核心线程设置多少合理，最大线程池设置多少合理等等。当然，这块不是乱设置的，需要结合具体业务。
比如线程池如何调优，如何确认最佳线程数？
最佳线程数目 = （（线程等待时间 线程cpu时间）/线程cpu时间 ）* cpu数目
ag真人游戏的服务器cpu核数为8核，一个任务线程cpu耗时为20ms，线程等待（网络io、磁盘io）耗时80ms，那最佳线程数目：( 80 20 )/20 * 8 = 40。也就是设置 40个线程数最佳。
有兴趣的小伙伴，也可以看这篇文章哈： 线程池到底设置多少线程比较合适？
对于线程池参数，如果小伙伴还有疑惑的话，可以看我之前这篇文章哈：java线程池解析
8. 线程池异常处理的坑
我们来看段代码：
/**
* 关注公众号：捡田螺的小男孩
*/
public class threadtest {
public static void main(string[] args) throws exception {
threadpoolexecutor executorone = new threadpoolexecutor(5, 5, 1,
timeunit.minutes, new arrayblockingqueue(20),new customizablethreadfactory("tianluo-thread-pool"));
for (int i = 0; i < 5; i ) {
executorone.submit(()->{
system.out.println("current thread name" thread.currentthread().getname());
object object = null;
system.out.print("result## " object.tostring());
});
}
}
}
按道理，运行这块代码应该抛空指针异常才是的，对吧。但是，运行结果却是这样的;
current thread nametianluo-thread-pool1
current thread nametianluo-thread-pool2
current thread nametianluo-thread-pool3
current thread nametianluo-thread-pool4
current thread nametianluo-thread-pool5
这是因为使用submit提交任务，不会把异常直接这样抛出来。大家有兴趣的话，可以去看看源码。可以改为execute方法执行，当然最好就是try...catch捕获，如下：
/**
* 关注公众号：捡田螺的小男孩
*/
public class threadtest {
public static void main(string[] args) throws exception {
threadpoolexecutor executorone = new threadpoolexecutor(5, 5, 1,
timeunit.minutes, new arrayblockingqueue(20),new customizablethreadfactory("tianluo-thread-pool"));
for (int i = 0; i < 5; i ) {
executorone.submit(()->{
system.out.println("current thread name" thread.currentthread().getname());
try {
object object = null;
system.out.print("result## " object.tostring());
}catch (exception e){
system.out.println("异常了" e);
}
});
}
}
}
其实，我们还可以为工作者线程设置uncaughtexceptionhandler，在uncaughtexception方法中处理异常。大家知道这个坑就好啦。
9. 线程池使用完毕后，忘记关闭
如果线程池使用完，忘记关闭的话，有可能会导致内存泄露问题。所以，大家使用完线程池后，记得关闭一下。同时，线程池最好也设计成单例模式，给它一个好的命名，以方便排查问题。
public class threadtest {
public static void main(string[] args) throws exception {
threadpoolexecutor executorone = new threadpoolexecutor(5, 5, 1,
timeunit.minutes, new arrayblockingqueue(20), new customizablethreadfactory("tianluo-thread-pool"));
executorone.execute(() -> {
system.out.println("关注公众号：捡田螺的小男孩");
});
//关闭线程池
executorone.shutdown();
}
}
10. threadlocal与线程池搭配，线程复用，导致信息错乱。
使用threadlocal缓存信息，如果配合线程池一起，有可能出现信息错乱的情况。先看下一下例子：
private static final threadlocal currentuser = threadlocal.withinitial(() -> null);
@getmapping("wrong")
public map wrong(@requestparam("userid") integer userid) {
//设置用户信息之前先查询一次threadlocal中的用户信息
string before = thread.currentthread().getname() ":" currentuser.get();
//设置用户信息到threadlocal
currentuser.set(userid);
//设置用户信息之后再查询一次threadlocal中的用户信息
string after = thread.currentthread().getname() ":" currentuser.get();
//汇总输出两次查询结果
map result = new hashmap();
result.put("before", before);
result.put("after", after);
return result;
}
按理说，每次获取的before应该都是null，但是呢，程序运行在 tomcat 中，执行程序的线程是tomcat的工作线程，而tomcat的工作线程是基于线程池的。
线程池会重用固定的几个线程，一旦线程重用，那么很可能首次从 threadlocal 获取的值是之前其他用户的请求遗留的值。这时，threadlocal 中的用户信息就是其他用户的信息。
把tomcat的工作线程设置为1
server.tomcat.max-threads=1
用户1，请求过来，会有以下结果，符合预期：
用户2请求过来，会有以下结果，「不符合预期」：
因此，使用类似 threadlocal 工具来存放一些数据时，需要特别注意在代码运行完后，显式地去清空设置的数据，正例如下：
@getmapping("right")
public map right(@requestparam("userid") integer userid) {
string before = thread.currentthread().getname() ":" currentuser.get();
currentuser.set(userid);
try {
string after = thread.currentthread().getname() ":" currentuser.get();
map result = new hashmap();
result.put("before", before);
result.put("after", after);
return result;
} finally {
//在finally代码块中删除threadlocal中的数据，确保数据不串
currentuser.remove();
}
}