线程池的底层实现原理

忘是亡心i 2023-07-15 02:56 66阅读 0赞

### 文章目录 ###

*  线程池的三个方法
 *   *  newFixedThreadPool(int nThread)
     *  newSingleThreadExecutor()
     *  newCachedThreadPool()
 *  线程池的七大参数
 *  线程池的底层工作原理
 *  如何设置合理参数
 *   *  线程池的拒绝策略
     *   *  什么是拒绝策略？
         *  有哪些拒绝策略？
         *   *   *  AbortPolicy()
                 *  CallerRunsPolicy()
                 *  DiscardPolicy()
                 *  DiscardOldestPolicy()
         *  JDK 内置的拒绝策略
         *  RejectExecutionHandler 接口
     *  单一的/固定数的/可变的三种创建线程池的方法哪个用的多？
     *   *  Executors 中 JDK 已经提供了为什么不用？

# 线程池的三个方法 #

## newFixedThreadPool(int nThread) ##

public static ExecutorService newFixedThreadPool(int nThreads) { 
    	return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable>());
    }

## newSingleThreadExecutor() ##

public static ExecutorService newSingleThreadExecutor() { 
    	return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable>()));
    }

## newCachedThreadPool() ##

public static ExecutorService newCachedThreadPool() { 
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
    }

通过这三大方法可以发现其实底层都是 new 了一个 ThreadPoolExecutor

# 线程池的七大参数 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70]

*  corePoolSize：线程池中的常驻核心线程数
 *  maximumPoolSize：线程池中的能够容纳同时执行的最大线程数，此值必须大于等于 1
 *  keepAliveTime：多余的空间线程的存活时间当前池中线程数量超过 corePoolSize 时，当空余时间达到 keepAliveTime 时，多余线程会被销毁直到只剩下 corePoolSize 个线程为止
 *  unit：keepAliveTime 的单位
 *  workQueue：任务队列，被提交但尚未被执行的任务
 *  threadFactory：表示生成线程池中工作线程的线程工厂，用于创建线程，一般默认的即可
 *  handler：拒绝策略，表示当队列满了，并且工作线程大于等于线程池的最大线程数（maximumPoolSize）时如何拒绝请求执行的 runnable 的策略

# 线程池的底层工作原理 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 2]

*  在创建了线程池后，开始等待请求
 *  当调用 execute() 方法添加一个请求任务时，线程池会做出如下判断：
    
     *  如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务
     *  如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务 放入队列
     *  如果这个时候队列满了且正在运行的线程数量还小于 maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务
     *  如果队列满了且正在运行的线程数量大于或等于 maximumPoolSize，那么线程池会 启动饱和拒绝策略来执行
 *  当一个线程完成任务时，它会从队列中取下一个任务来执行
 *  当一个线程无事可做超过一定的时间（keepAliveTime）时，线程会判断：
    
     *  如果当前运行的线程数大于 corePoolSize，那么这个线程就会被停掉
     *  所以线程池的所有任务完成后，它最终会收缩到 corePoolSize 的大小

# 如何设置合理参数 #

根据自己的要求合理配置即可

// 自定义线程池
    ExecutorService threadPool = new ThreadPoolExecutor(
    				                2, // 线程池中的常驻核心线程数
    				                5, // 最大线程数
    				                2L,
    				                TimeUnit.SECONDS,
    				                new LinkedBlockingQueue<>(3), // 任务队列数
    				                Executors.defaultThreadFactory(),
    				                // AbortPolicy 拒绝策略
    				                new ThreadPoolExecutor.AbortPolicy());

## 线程池的拒绝策略 ##

### 什么是拒绝策略？ ###

等待队列已经排满了，再也塞不下新任务了。同时，线程池中的 max 线程也达到了，无法继续为新任务服务。这个时候我们就需要拒绝策略机制合理地处理这个问题

### 有哪些拒绝策略？ ###

##### AbortPolicy() #####

直接抛出 RejectExecutionException 异常阻止系统正常运行

先看下下面这段代码

package juc;
    
    /** * @author Woo_home * @create by 2020/3/14 */
    public class MyThreadPoolDemo { 
        public static void main(String[] args) { 
        	// 自定义线程池
            ExecutorService threadPool = new ThreadPoolExecutor(
                    2,
                    5,
                    2L,
                    TimeUnit.SECONDS,
                    new LinkedBlockingQueue<>(3),
                    Executors.defaultThreadFactory(),
                    new ThreadPoolExecutor.AbortPolicy());
    
            try { 
            	// 模拟 8 个用户办理业务
                for (int i = 1; i <= 8; i++) { 
                    threadPool.execute(() -> { 
                        System.out.println(Thread.currentThread().getName() + " 办理业务");
                    });
                }
            } catch (Exception e) { 
                e.printStackTrace();
            } finally { 
                threadPool.shutdown();
            }
        }
    }

输出：

OK，8 个用户办理业务没问题，那么再多几个用户呢？  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 3]  
将上述代码中的 for 循环修改如下：

for (int i = 1; i <= 10; i++) { 
        threadPool.execute(() -> { 
            System.out.println(Thread.currentThread().getName() + " 办理业务");
        });
    }

输出：

抛出了个 RejectedExecutionException 异常  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 4]  
线程池请求数 > maximumPoolSize + 队列数 ——> 拒绝策略  
![在这里插入图片描述][20200316114518166.png]

##### CallerRunsPolicy() #####

“调用者运行” 一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务的流量

将上述线程池的代码修改如下，然后运行程序  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 5]  
输出：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 6]  
线程池处理不完的请求会丢给主线程去执行

##### DiscardPolicy() #####

该策略默默地丢弃无法处理的任务，不予任何处理也不抛出异常。如果允许任务丢失，这是最好的一种策略  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 7]  
输出：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 8]

##### DiscardOldestPolicy() #####

抛弃队列中等待最后的任务，然后把当前任务加入队列中尝试再次提交当前任务  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 9]

### JDK 内置的拒绝策略 ###

*  AbortPolicy（默认）：直接抛出 RejectExecutionException 异常阻止系统正常运行
 *  CallerRunsPolicy：“调用者运行” 一种调节机制，该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务的流量
 *  DiscardOldestPolicy：抛弃队列中等待最后的任务，然后把当前任务加入队列中尝试再次提交当前任务
 *  DiscardPolicy：该策略默默地丢弃无法处理的任务，不予任何处理也不抛出异常。如果允许任务丢失，这是最好的一种策略

### RejectExecutionHandler 接口 ###

上面讲述的四个拒绝策略都实现了 RejectExecutionHandler 接口并重写了 void rejectedExecution(Runnable r, ThreadPoolExecutor executor) 方法  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 10]

## 单一的/固定数的/可变的三种创建线程池的方法哪个用的多？ ##

### Executors 中 JDK 已经提供了为什么不用？ ###

在阿里巴巴开发手册中，线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险

说明：Executors 返回的线程池对象的弊端如下：

（1）FixedThreadPool 和 SingleThreadPool：允许请求队列长度为 Integer.MAX\_VALUE，可能会堆积大量的请求，从而导致 OOM（内存不足）  
（2）CacheThreadPool 和 ScheduledThreadPool：允许创建线程数量为 Integer.MAX\_VALUE，可能会创建大量的线程，从而导致 OOM

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70]: /images/20230529/a2eaa63df3f546db88db3fb947978817.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 1]: /images/20230529/b1b9718351a944dd9d42961e6dd20262.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 2]: /images/20230529/e01eccf714af40f5a76ef6a203fe1ed2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 3]: /images/20230529/14f9120bcbd94dc8a90a2a4a75dbd2f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 4]: /images/20230529/518336a65e62442cacf2e26dd27c39e6.png
[20200316114518166.png]: /images/20230529/06b7b45c08ed40868ff57677fa33e17b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 5]: /images/20230529/d6837d54e48e4134bf0f39694368ba48.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 6]: /images/20230529/ac2b7bf5d6e14d21b0b480e4942e9e3d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 7]: /images/20230529/4e2ad2339a6b43ae82283bbc5550df47.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 8]: /images/20230529/967acc923cf94de2bc219034b71b34f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 9]: /images/20230529/5a0b23af8372410ea639a797c081fce3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dvb19ob21l_size_16_color_FFFFFF_t_70 10]: /images/20230529/9ce751b42369493dbae9b3f4b329f1de.png