菜鸟笔记
提升您的技术认知

使用线程池的10个坑-ag真人游戏

前言

大家好,我是捡田螺的小男孩

日常开发中,为了更好管理线程资源,减少创建线程和销毁线程的资源损耗,我们会使用线程池来执行一些异步任务。但是线程池使用不当,就可能会引发生产事故。今天田螺哥跟大家聊聊线程池的10个坑。大家看完肯定会有帮助的~

  1. 线程池默认使用无界队列,任务过多导致oom

  2. 线程创建过多,导致oom

  3. 共享线程池,次要逻辑拖垮主要逻辑

  4. 线程池拒绝策略的坑

  5. spring内部线程池的坑

  6. 使用线程池时,没有自定义命名

  7. 线程池参数设置不合理

  8. 线程池异常处理的坑

  9. 使用完线程池忘记关闭

  10. 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();
    }
}
网站地图