Java 线程池

相信在实际工作中，大家对于线程池的使用并不陌生，例如以下几个应用场景：

支付成功之后，异步发送短信通知用户；
公司的OA系统中，提交某些申请之后，异步发送给各个部门负责人进行审批；
请求某个接口时，需要做些日志上报之类的记录。

线程池的使用

下边是一个非常简单的线程池使用案例：

public class ThreadExecutorDemo {

    public static void main(String[] args) {
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
                1,
                1,
                1,
                TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000));
        threadPoolExecutor.submit(new Runnable() {
            @Override
            public void run() {
                System.out.println("this is submitTask");
            }
        });
        threadPoolExecutor.execute(new Runnable() {
            @Override
            public void run() {
                System.out.println("this is executeTask");
            }
        });
    }
}

通过这段简单的案例代码我们可以知道，线程池常用接口有两类，一种叫 submit，一种叫 execute。这两种方法在执行的时候都不会阻塞到调用线程自身，都能达到异步的效果，但是它们在实现效果方面却有所不同。下边让我们对这两种不同接口做了一些比对，大致如下表所示：

方法名字	返回内容	异常处理情况	是否可以实现异步效果
execute	空	如果出现异常，并且没有加 try-catch 块，线程池会将异常给吞掉。	可以
submit	future对象	如果出现异常，会将异常自动抛出	可以

线程池在实际工作中，可以运用的业务场景非常多，下边我列举了几个非常实用的应用场景和大家分享。

用户注册场景

用户注册之后，当用户信息写入到数据库之后，通过线程池异步发送一条消息通知给到用户身上。

public class UserRegistryThreadExecutorDemo {

    public static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            1,
            1,
            1,
            TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000));


    /**
* 用户注册
*/
public static void userRegistry() {
        //插入用户信息
        addUserInfo();
        //异步发送消息通知
        threadPoolExecutor.execute(new Runnable() {
            @Override
            public void run() {
                sendNotifyMsg();
            }
        });
        System.out.println("用户注册操作流程结束");
    }

    /**
* 模拟信息插入动作
*/
private static void addUserInfo() {
        System.out.println("插入用户信息");
    }

    /**
* 发送通知信息
*/
private static void sendNotifyMsg() {
        System.out.println("发送消息通知开始");
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("发送消息通知结束");
    }


    public static void main(String[] args) {
        userRegistry();
    }
}

由于发送消息通知这个操作的过程耗时会比较高，并且其发送的结果不需要百分百返回给到用户那边，那么这个发送的操作就可以交给线程池去处理。

审核场景

在审核场景中，用户点击提交按钮之后，会将审核记录插入到对应的表中，然后通过异步线程发送给到各个部门的负责人。

public class AuditExecutorDemo {

    public static final ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            1,
            1,
            1,
            TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000));


    /**
* 执行审核操作
*/
public static boolean doAudit() {
        createAuditRecord();
        threadPoolExecutor.execute(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(1000);
                    System.out.println("发送审核记录给到A部门负责人");
                    Thread.sleep(1000);
                    System.out.println("发送审核记录给到B部门负责人");
                    Thread.sleep(1000);
                    System.out.println("发送审核记录给到C部门负责人");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
        return true;
    }

    /**
* 模拟将审核记录写入到数据库中
*/
private static void createAuditRecord() {
        System.out.println("插入审核记录");
    }

    public static void main(String[] args) {
        boolean auditStatus = doAudit();
        System.out.println("提交审核记录结果:" + auditStatus);
    }
}

和用户注册用例中比较相似，因为消息发送给到各个负责人的过程是比较耗时的一个操作，所以这一块可以通过线程池异步去完成。

通过这几个实际案例我们可以发现，我们在使用线程池的时候，基本都是将任务往线程池里丢。那么当我们将线程任务丢入到线程池之后，又会发生什么事情呢？下边就需要我们深入了解下线程池的原理了。

线程池原理

这里我用一张动态图来带大家形象地理解线程池的内部执行流程，如下：

其实线程池的核心原理就和生产者消费者差不多，比较相似的点在于，一端不断地提交任务，一端不断地消费任务，而生产者就是我们的调用方，消费者则是线程池内部的worker线程。

整体的执行逻辑大致如下：

当生产者提交任务之后，线程会优先分配给空闲的核心线程。
如果核心线程都处于忙碌状态，那么新提交的任务就会被放入到一个队列中去。
若队列满了之后，再有新的任务提交，则会将新提交的任务放入到非核心线程中处理。
假若连非核心线程也都处理不过来的话，那么接下来线程池就会执行拒绝策略。

为了方便大家理解，我整理了一张流程图供大家查看：

在实际使用线程池的时候，我们通常又会使用哪些参数呢？下边我整理了一些供大家参考：

corePoolSize 核心线程数；
maximumPoolSize 最大线程数；
keepAliveTime 线程活跃时间；
zaResizableCapacityLinkedBlockingQueue 基于 JDK 改造的可伸缩队列；
allowCoreThreadTimeOut 允许核心线程数超时后被回收；
preStartCoreThread 是否要在一开始就启动 corePoolSize 数量的线程数
preStartAllCoreThreads 是否要在一开始就启动 maximumPoolSize 数量的线程数

在结合不同的应用场景下，我们通常会给线程池配置不同的参数，对于线程池参数的配置其实也是一门学问，常见的任务类型可以划分为 IO密集型和 CPU密集型。 通常 IO 密集型任务主要是一些涉及到读写磁盘，网络通信之类的任务，这类任务在互联网业务场景中会比较多，例如远程服务调用。而 CPU 密集型任务的代表如：数据加密解密计算、图片识别等。

关于线程池参数方面的设置，其实网上有许多种说法，有的会根据一套公式来给出定义，但其实线程池的参数应该可以动态调整才是合理的。

不同的应用中间件是如何使用线程池的？

Spring 内部的异步注解

在Spring框架中，有一个叫做 @Async 的注解，在 Spring 应用上下文中加入一个 @EnableAsync 的注解，接着在使用的方法头部加入一个 @Async 注解，则被标示的方法在执行的时候，就会被自动提交到一个异步线程池中使用，从而产生异步的效果。例如下边这段代码：

@Service
public class AsyncService {

    //加入注解之后，该方法自动就带有了异步的效果
    @Async
    public void testAsync(){
        try {
            Thread.sleep(1000*2);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(Thread.currentThread().getName()+" async test");
    }
}

控制器部分代码如下：

@RestController
@RequestMapping(value = "/test")
public class TestController {

    @Resource
    private AsyncService asyncService;

    @GetMapping(value = "/do-test")
    public String doTest(){
        //每次调用都会将该方法扔入一个线程池中执行    
        asyncService.testAsync();
        return "success";
    }
}

在生产环境中，我们通常不会直接使用 Spring 自带的线程池，而是会采用一个自定义的线程池去替代它。这是因为 Spring 对于带有 @Async 注解的方法，会将它们丢入到一个叫做 applicationTaskExecutor 的线程池中。

对于这个线程池的属性，我们可以看出，它的内部对于最大线程数设置是一个巨大的数值，因此使用@Async注解默认的线程池的话，容易产生无止境地工作，从而导致oom异常。

为了解决这一存在的风险，通常我们可以尝试将Async对应的线程池给更换为自定义的一个线程池，从而避免 oom 情况的发生，具体操作如下所示：

@Configuration
public class AsyncExecuteConfig extends AsyncConfigurerSupport {

    @Bean
    public ThreadPoolTaskExecutor asyncExecutor() {
        ThreadPoolTaskExecutor threadPool = new ThreadPoolTaskExecutor();
        threadPool.setCorePoolSize(3);
        threadPool.setMaxPoolSize(3);
        threadPool.setWaitForTasksToCompleteOnShutdown(true);
        threadPool.setAwaitTerminationSeconds(60 * 15);
        return threadPool;
    }

    @Override
    public Executor getAsyncExecutor() {
        return asyncExecutor();
    }
}

Dubbo 底层的线程池使用

在 Dubbo 线程池的底层中，其实也存在很多使用线程池场景。在 Dubbo 的内部源代码中，专门对不同类型的线程池做了各种扩展，具体可以通过阅读 Dubbo 的源代码去查看，如下图所示：

Dubbo 底层针对线程池的种类做了一系列的封装，并且定义了一个专门的 SPI 接口去进行扩展。

RocketMQ 的消费线程池

在 RocketMQ 的内部也存在着使用线程池的场景，在 Consumer 节点中，会有一个叫做 consumeExecutor 的线程池负责将消息从 broker 中拉取到本地内存进行消费。

初此之外，在构建对象 ConsumeMessageConcurrentlyService 的时候，就默认构建了一批线程池。

通过阅读不同的中间件我们可以发现，线程池在实际应用中是一款实用性非常高的技术，合理地应用线程池技术，可以很好地帮助我们解决一些复杂的应用场景。

总结：

Dubbo 底层使用了业务线程池和 IO 线程池进行分工合作，IO 线程池一般负责接收请求并且转发，业务线程池则是用于接收请求并且进行业务处理。
Spring 底层采用了线程池来异步化操作，但是要注意使用 @Async 注解的时候，其底层是会使用一个无界队列的线程池，所以要注意 oom 异常的发生。
在 RocketMQ 中，消费者端定义了一个线程池，用于从 broker 节点上拉取消息数据，具体源代码可以在 ConsumeMessageConcurrentlyService 类中查看到。

在使用线程池的时候有没有遇到过什么问题呢？

线程池没有做优雅关闭，导致部分运行到一半的任务被杀掉；
线程池执行submit的时候，内部出了异常，但是没有加入try-catch代码块，导致异常被吞；
线程池的队列长度配置过大，导致应用服务出现 oom；
线程池的内部希望获取到外部的线程变量，可以使用 TransmittableThreadLocal 来获取；
高并发场景下不适合使用线程池接收任务，适合使用 MQ 来替代。

posted @ 2023-03-25 14:51 Dazzling! 阅读(44) 评论(0) 编辑收藏举报

刷新页面返回顶部

Dazzling

外婆坐在阳光下轻轻抚着我的发那远去的少年恍然间长大

Java 线程池

线程池的使用

线程池原理

不同的应用中间件是如何使用线程池的？

Spring 内部的异步注解

Dubbo 底层的线程池使用

RocketMQ 的消费线程池

公告

Dazzling

外婆坐在阳光下 轻轻抚着我的发 那远去的少年 恍然间长大

Java 线程池

线程池的使用

线程池原理

不同的应用中间件是如何使用线程池的？

Spring 内部的异步注解

Dubbo 底层的线程池使用

RocketMQ 的消费线程池

公告

外婆坐在阳光下轻轻抚着我的发那远去的少年恍然间长大