创建线程 VS 线程池？

有同学就会问了，为什么要用线程池呢？我需要用线程，直接 new 创建一个线程出来执行相应任务不就好了吗？

Thread thread = new Thread(() -> {
            System.out.println("启动一个线程.");

        }).start();

但实际上，在真实业务场景中，过多的创建销毁线程，会带来巨大的资源开销，甚至在流量巨大的时候会拖垮服务器！！！

那么这种直接创建线程的方式还带来了什么坏处呢？

1. #技术分享 #掘金资源开销：刚才讲过的过多的线程创建销毁会带来巨大的资源开销
2. cpu资源的浪费：无限制的创建线程会导致线程数量过多，就会导致频繁的上下文切换，无法发挥cpu完整的性能
3. 任务响应速度慢：一个线程创建和销毁都需要时间，任务到达时必然需要等待
4. 无序性：线程是宝贵资源，如果随意的创建和销毁，就会导致线程的不合理分布，资源调度失衡，整个系统的稳定性降低

如何解决频繁创建销毁线程的问题：池化

这里我用自己的理解来解释池化，池化 其实是一种成本最小化来保证利益最大化，将宝贵资源统一管理的思想或手段

那么 Java 中哪里体现了池化思想呢？

1. 数据库连接池：预先申请数据库连接，降低系统延迟，提高连接效率
2. 实例池：最典型的就是Spring中的IOC容器
3. 内存池：预先申请内存，提高系统响应速度

当然还有我们的线程池啦！

线程池通过维护多个线程，等待任务分配并执行，这样的做法一方面避免了频繁的创建和销毁线程而导致的资源开销，另一方面也保证了适度的上下文切换，保证了内核的使用效率。同时，使用线程池还可以对资源进行统一的分配和监控，保证各个任务顺利执行。

线程池还具有可扩展性，比如允许任务定时执行或者延期执行。这样就比单一线程具有更多优势

线程池核心参数

线程池会通过一些核心参数来配置其行为，不同的参数可以创建出适合不同业务的线程池。以下是线程池的一些常见核心参数：

1. corePoolSize（核心线程数） ：这是指线程池中的常驻线程数。即使线程处于空闲状态，它们也不会被销毁，除非设置了允许核心线程超时。（请注意，核心线程并不是伴随线程池创建而创建的，意思就是说线程池里面原本就是空的！）
2. maximumPoolSize（最大线程数） ：线程池中允许的最大线程数。当任务数量增加且所有核心线程都在忙碌时，线程池可以创建新的线程直到达到这个最大值。
3. keepAliveTime（线程存活时间） ：当线程池中的线程数超过核心线程数时，多余的空闲线程在这个时间内没有执行任务就会被终止。此参数对于非核心线程有效；如果允许核心线程超时，则也适用于核心线程。
4. unit（时间单位） ：为 keepAliveTime 指定的时间单位，例如秒、分钟等。
5. workQueue（工作队列） ：一个阻塞队列，用于保存等待执行的任务。它的容量和行为可以根据需要选择不同的实现类，如无界队列、有界队列或同步移交。
6. threadFactory（线程工厂） ：用于创建新线程的工厂。可以通过自定义线程工厂设置线程的名称、是否是守护线程等属性。
7. handler（拒绝策略） ：当线程池无法处理新提交的任务时（通常是由于达到了线程边界和队列容量限制），采用的拒绝策略。常见的策略包括抛出异常、直接丢弃任务、尝试由调用线程运行该任务等。

Executors 工具类提供了一系列特定的线程池供使用，但是由于实际业务场景的复杂性，都是推荐使用自定义 ThreadPoolExecutor 来提供线程池服务。

静态线程池 VS 动态线程池

普通的线程池一般都是”静态”的，这里的静态并不是说整个线程池是静止不动的，而是说线程池的核心配置是不变的。对应的动态线程池也代表是线程池的核心配置是可变的，不需要重新部署整个应用就可以实现。

为什么要使用动态线程池呢？因为在实际的业务场景中，开发人员仅凭经验是无法精确预估当前业务的流量的，有可能会将核心线程数，最大线程数等关键参数设置过大或者过小，过小可能会导致接口降级等事件，过大则有可能导致内核利用效率低，资源分配不均等问题。

针对这个问题，我们使用提出动态线程池这个方法。在应用上线时，也可以根据具体的业务流量来进行更改核心参数来应对起伏不定的流量。由于线程池的扩展性，我们还可以针对线程池任务执行情况进行监控，实现通知告警功能。

如何配置动态线程池

关于配置动态线程池，我们需要第三方的配置中心来进行存储或更改线程池当前的配置，比如当前非常热门的 Nacos，Zookeeper 等就非常适合用来做配置中心。这里提供一个实现基础动态线程池的思路。

简单来说，你甚至可以利用 Redis 的发布订阅功能来实现一个基础的动态线程池功能，通过管理端来更改当前 redis 里面线程池相应的参数，当 redis 的监听器 Listener 监听到相应 Topic 的消息，就可以利用 ThreadPoolExecutor 的底层方法更改相应线程池的参数，最后进行上报给 Redis 进行登记。这样管理端进行不断轮询就可以获取相应线程池参数。

还可以扩展更多功能，比如监控功能，通知告警功能...

如果这篇文章能够对你有所启发，不妨可以给我点赞和收藏，这是对笔者更新更多优质文章的鼓励，谢谢！！！