并发系列之线程池解析

以你之姓@ 2022-11-18 10:48 187阅读 0赞

### 并发系列之线程池解析 ###

*   *  1、线程池是什么？
     *  2、线程池核心设计与实现
     *   *  2.1、线程池的生命周期
         *  2.2、任务执行的机制
         *   *  2.2.1、任务调度
             *  2.2.2、任务缓冲
             *  2.2.3、任务申请
             *  2.2.4、任务拒绝
         *  2.3、核心参数
         *  2.4、功能线程池
     *  3、Worker线程管理
     *   *  3.1、Worker线程增加
         *  3.2、Worker线程回收
         *  3.3、Worker线程执行任务
     *  4、线程池在业务中的实践
     *   *  4.1、快速响应用户请求
         *  4.2、快速处理批量任务
         *  4.3、解决方案
         *   *  4.3.1、能否不用线程池?
             *  4.3.2、追求参数设置合理性？
             *  4.3.3、线程池参数动态化？（推荐）
     *  5、往期佳文
     *   *  5.1、面试系列
         *  5.2、技术系列
         *  5.3、源码系列
         *  5.4、数据结构和算法系列
         *  5.5、并发系列

## 1、线程池是什么？ ##

线程池（Thread Pool）是一种基于池化思想管理线程的工具，经常出现在多线程服务器中，如MySQL。  
       线程过多回带来额外的开销，其中包括创建销毁线程的开销、调度线程的开销等等，同时也降低了计算机的整体性能。线程池维护多个线程，等待监督管理这分配可执行的任务。这种做法，一方面避免了处理任务时创建销毁线程开销的代价，另一方面避免了线程数量膨胀导致的过分调度问题，保证了对内核的充分利用（**线程池解决的核心问题就是资源管理问题**）。  
使用线程池带来的好处：

1.  降低资源消耗：通过池化技术重复利用已创建的线程，降低线程创建和销毁造成的损耗。
2.  提高响应速度：任务到达是，无需等待线程创建即可立即执行。
3.  提高线程的可管理性：线程是稀缺资源，如果无限制创建，不仅会消耗系统资源，还会因为线程的不合理分布导致资源调度失衡，降低系统的稳定性。使用线程池可以进行统一的分配、调优和监控。
4.  提供更多更强大的功能：线程池具备可扩展性，允许开发人员向其中添加更多的功能，另一方面避免了线程数量膨胀导致的过度调度问题，保证了对内核的充分利用。

--------------------

## 2、线程池核心设计与实现 ##

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

Java中的线程池核心实现类是ThreadPoolExecutor，基于JDK 1.8的源码来分析Java线程池的核心设计与实现ThreadPoolExecutor的UML类图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 1]  
       ThreadPoolExecutor实现的顶层接口是Executor，顶层接口Executor提供了一种思想：将任务提交和任务执行进行解耦。用户无需关注如何创建线程，如何调度线程来执行任务，用户只需提供Runnable对象，将任务的运行逻辑提交到执行器(Executor)中，由Executor框架完成线程的调配和任务的执行部分。  
       ExecutorService接口增加了一些能力：（1）扩充执行任务的能力，补充可以为一个或一批异步任务生成Future的方法；（2）提供了管控线程池的方法，比如停止线程池的运行。  
       AbstractExecutorService则是上层的抽象类，将执行任务的流程串联了起来，保证下层的实现只需关注一个执行任务的方法即可。  
       最下层的实现类ThreadPoolExecutor实现最复杂的运行部分，ThreadPoolExecutor将会一方面维护自身的生命周期，另一方面同时管理线程和任务，使两者良好的结合从而执行并行任务。  
线程池在内部实际上构建了一个生产者消费者模型，将线程和任务两者解耦，并不直接关联，从而良好的缓冲任务，复用线程。ThreadPoolExecutor运行流程图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 2]  
       线程池的运行主要分成两部分：任务管理、线程管理。  
       任务管理部分充当生产者的角色，当任务提交后，线程池会判断该任务后续的流转：（1）直接申请线程执行该任务；（2）缓冲到队列中等待线程执行；（3）拒绝该任务。  
       线程管理部分是消费者，它们被统一维护在线程池内，根据任务请求进行线程的分配，当线程执行完任务后则会继续获取新的任务去执行，最终当线程获取不到任务的时候，线程就会被回收。

### 2.1、线程池的生命周期 ###

线程池内部使用一个变量维护两个值：运行状态(runState)和线程数量 (workerCount)。在具体实现中，线程池将运行状态(runState)、线程数量 (workerCount)两个关键参数的维护放在了一起，高3位保存runState，低29位保存workerCount（用一个变量去存储两个值，可避免在做相关决策时，出现不一致的情况，不必为了维护两者的一致，而占用锁资源。）。

private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
    // RUNNING:能接受新提交的任务，并且也能处理阻塞队列中的任务
    private static final int RUNNING    = -1 << COUNT_BITS;
    // SHUTDOWN：关闭状态，不能接受新提交的任务，但却可以继续处理阻塞队列中的任务
    private static final int SHUTDOWN   =  0 << COUNT_BITS;
    // STOP：不能接受新提交的任务，也不能处理阻塞队列中的任务，会中断处理任务的线程
    private static final int STOP       =  1 << COUNT_BITS;
    // TIDYING：所有任务都已终止了，workerCount为0
    private static final int TIDYING    =  2 << COUNT_BITS;
    // TERMINATED：在terminated()方法执行完成后进入该状态
    private static final int TERMINATED =  3 << COUNT_BITS;
    //计算当前运行状态
    private static int runStateOf(int c)     {  return c & ~CAPACITY; } 
    //计算当前线程数量
    private static int workerCountOf(int c)  {  return c & CAPACITY; }  
    //通过状态和线程数生成ctl
    private static int ctlOf(int rs, int wc) {  return rs | wc; }

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

### 2.2、任务执行的机制 ###

#### 2.2.1、任务调度 ####

任务调度是线程池的主要入口，当用户提交了一个任务，接下来这个任务将如何执行都是由这个阶段决定的（检查现在线程池的运行状态、运行线程数、运行策略，决定接下来执行的流程，是直接申请线程执行，或是缓冲到队列中执行，亦或是直接拒绝该任务）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 4]

1.  首先检测线程池运行状态，如果不是RUNNING，则直接拒绝，线程池要保证在RUNNING的状态下执行任务。
2.  如果workerCount < corePoolSize，则创建并启动一个线程来执行新提交的任务。
3.  如果workerCount >= corePoolSize，且线程池内的阻塞队列未满，则将任务添加到该阻塞队列中。
4.  如果workerCount >= corePoolSize && workerCount < maximumPoolSize，且线程池内的阻塞队列已满，则创建并启动一个线程来执行新提交的任务。
5.  如果workerCount >= maximumPoolSize，并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常。

#### 2.2.2、任务缓冲 ####

任务缓冲模块是线程池能够管理任务的核心部分。阻塞队列(BlockingQueue)是一个支持两个附加操作的队列。这两个附加的操作是：在队列为空时，获取元素的线程会等待队列变为非空。当队列满时，存储元素的线程会等待队列可用。阻塞队列常用于生产者和消费者的场景，生产者是往队列里添加元素的线程，消费者是从队列里拿元素的线程。阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 5]  
使用不同的队列可以实现不一样的任务存取策略，阻塞队列的成员：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 6]

#### 2.2.3、任务申请 ####

任务的执行有两种可能：一种是任务直接由新创建的线程执行。另一种是线程从任务队列中获取任务然后执行，执行完任务的空闲线程会再次去从队列中申请任务再去执行。第一种情况仅出现在线程初始创建的时候，第二种是线程获取任务绝大多数的情况。线程需要从任务缓存模块中不断地取任务执行，帮助线程从阻塞队列中获取任务，实现线程管理模块和任务管理模块之间的通信。这部分策略由getTask方法实现，其执行流程：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 7]

#### 2.2.4、任务拒绝 ####

任务拒绝模块是线程池的保护部分，线程池有一个最大的容量，当线程池的任务缓存队列已满，并且线程池中的线程数目达到maximumPoolSize时，就需要拒绝掉该任务，采取任务拒绝策略，保护线程池。

public interface RejectedExecutionHandler { 
        void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
    }

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

### 2.3、核心参数 ###

1.  corePoolSize（必需）：核心线程数。默认情况下，核心线程会一直存活，但是当将 allowCoreThreadTimeout 设置为 true 时，核心线程也会超时回收。
2.  maximumPoolSize（必需）：线程池所能容纳的最大线程数。当活跃线程数达到该数值后，后续的新任务将会阻塞。
3.  keepAliveTime（必需）：线程闲置超时时长。如果超过该时长，非核心线程就会被回收。如果将 allowCoreThreadTimeout 设置为 true 时，核心线程也会超时回收。
4.  unit（必需）：指定 keepAliveTime 参数的时间单位。常用的有：TimeUnit.MILLISECONDS（毫秒）、TimeUnit.SECONDS（秒）、TimeUnit.MINUTES（分）。
5.  workQueue（必需）：任务队列。通过线程池的 execute() 方法提交的 Runnable 对象将存储在该参数中。其采用阻塞队列实现。
6.  threadFactory（可选）：线程工厂。用于指定为线程池创建新线程的方式。
7.  handler（可选）：拒绝策略。当达到最大线程数时需要执行的饱和策略。

### 2.4、功能线程池 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 9]  
其实 Executors 的 4 个功能线程有如下弊端：  
       FixedThreadPool 和 SingleThreadExecutor：主要问题是堆积的请求处理队列均采用 LinkedBlockingQueue，可能会耗费非常大的内存，甚至 OOM。  
       CachedThreadPool 和 ScheduledThreadPool：主要问题是线程数最大数是 Integer.MAX\_VALUE，可能会创建数量非常多的线程，甚至 OOM。

--------------------

## 3、Worker线程管理 ##

private final class Worker extends AbstractQueuedSynchronizer implements Runnable{ 
        final Thread thread;//Worker持有的线程
        Runnable firstTask;//初始化的任务，可以为null
    }

Worker这个工作线程，实现了Runnable接口，并持有一个线程thread，一个初始化的任务firstTask。thread是在调用构造方法时通过ThreadFactory来创建的线程，可以用来执行任务；firstTask用它来保存传入的第一个任务，这个任务可以有也可以为null。如果这个值是非空的，那么线程就会在启动初期立即执行这个任务，也就对应核心线程创建时的情况；如果这个值是null，那么就需要创建一个线程去执行任务列表（workQueue）中的任务，也就是非核心线程的创建。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 10]  
Worker是通过继承AQS，使用AQS来实现独占锁这个功能，

1.  lock方法一旦获取了独占锁，表示当前线程正在执行任务中。
2.  如果正在执行任务，则不应该中断线程。
3.  如果该线程现在不是独占锁的状态，也就是空闲的状态，说明它没有在处理任务，这时可以对该线程进行中断。
4.  线程池在执行shutdown方法或tryTerminate方法时会调用interruptIdleWorkers方法来中断空闲的线程，interruptIdleWorkers方法会使用tryLock方法来判断线程池中的线程是否是空闲状态；如果线程是空闲状态则可以安全回收。

### 3.1、Worker线程增加 ###

addWorker方法有两个参数：firstTask、core。firstTask参数用于指定新增的线程执行的第一个任务，该参数可以为空；core参数为true表示在新增线程时会判断当前活动线程数是否少于corePoolSize，false表示新增线程前需要判断当前活动线程数是否少于maximumPoolSize。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 11]

private boolean addWorker(Runnable firstTask, boolean core) { 
            retry:
            for (;;) { 
                int c = ctl.get();
                int rs = runStateOf(c);
    
                // Check if queue empty only if necessary.
                if (rs >= SHUTDOWN &&
                    ! (rs == SHUTDOWN &&
                       firstTask == null &&
                       ! workQueue.isEmpty()))
                    return false;
    
                for (;;) { 
                    int wc = workerCountOf(c);
                    if (wc >= CAPACITY ||
                        wc >= (core ? corePoolSize : maximumPoolSize))
                        return false;
                    if (compareAndIncrementWorkerCount(c))
                        break retry;
                    c = ctl.get();  // Re-read ctl
                    if (runStateOf(c) != rs)
                        continue retry;
                    // else CAS failed due to workerCount change; retry inner loop
                }
            }
    
            boolean workerStarted = false;
            boolean workerAdded = false;
            Worker w = null;
            try { 
                w = new Worker(firstTask);
                final Thread t = w.thread;
                if (t != null) { 
                    final ReentrantLock mainLock = this.mainLock;
                    mainLock.lock();
                    try { 
                        // Recheck while holding lock.
                        // Back out on ThreadFactory failure or if
                        // shut down before lock acquired.
                        int rs = runStateOf(ctl.get());
    
                        if (rs < SHUTDOWN ||
                            (rs == SHUTDOWN && firstTask == null)) { 
                            if (t.isAlive()) // precheck that t is startable
                                throw new IllegalThreadStateException();
                            workers.add(w);
                            int s = workers.size();
                            if (s > largestPoolSize)
                                largestPoolSize = s;
                            workerAdded = true;
                        }
                    } finally { 
                        mainLock.unlock();
                    }
                    if (workerAdded) { 
                        t.start();
                        workerStarted = true;
                    }
                }
            } finally { 
                if (! workerStarted)
                    addWorkerFailed(w);
            }
            return workerStarted;
        }

### 3.2、Worker线程回收 ###

线程池中线程的销毁依赖JVM自动的回收，线程池做的工作是根据当前线程池的状态维护一定数量的线程引用，防止这部分线程被JVM回收，当线程池决定哪些线程需要回收时，只需要将其引用消除即可。Worker被创建出来后，就会不断地进行轮询，然后获取任务去执行，核心线程可以无限等待获取任务，非核心线程要限时获取任务。当Worker无法获取到任务，也就是获取的任务为空时，循环会结束，Worker会主动消除自身在线程池内的引用。  
![在这里插入图片描述][20210413102155190.png]  
       事实上，在这个方法中，将线程引用移出线程池就已经结束了线程销毁的部分。但由于引起线程销毁的可能性有很多，线程池还要判断是什么引发了这次销毁，是否要改变线程池的现阶段状态，是否要根据新状态，重新分配线程。

try { 
      while (task != null || (task = getTask()) != null) { 
        //执行任务
      }
    } finally { 
      processWorkerExit(w, completedAbruptly);//获取不到任务时，主动回收自己
    }
    private void processWorkerExit(Worker w, boolean completedAbruptly) { 
            if (completedAbruptly) // If abrupt, then workerCount wasn't adjusted
                decrementWorkerCount();
    
            final ReentrantLock mainLock = this.mainLock;
            mainLock.lock();
            try { 
                completedTaskCount += w.completedTasks;
                workers.remove(w);
            } finally { 
                mainLock.unlock();
            }
    
            tryTerminate();
    
            int c = ctl.get();
            if (runStateLessThan(c, STOP)) { 
                if (!completedAbruptly) { 
                    int min = allowCoreThreadTimeOut ? 0 : corePoolSize;
                    if (min == 0 && ! workQueue.isEmpty())
                        min = 1;
                    if (workerCountOf(c) >= min)
                        return; // replacement not needed
                }
                addWorker(null, false);
            }
        }

### 3.3、Worker线程执行任务 ###

在Worker类中的run方法调用了runWorker方法来执行任务，runWorker方法的执行过程如下：

1.  while循环不断地通过getTask()方法获取任务。
2.  getTask()方法从阻塞队列中取任务。
3.  如果线程池正在停止，那么要保证当前线程是中断状态，否则要保证当前线程不是中断状态。
4.  执行任务。 5.如果getTask结果为null则跳出循环，执行processWorkerExit()方法，销毁线程。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 12]

final void runWorker(Worker w) { 
        Thread wt = Thread.currentThread();
        Runnable task = w.firstTask;
        w.firstTask = null;
        w.unlock(); // allow interrupts
        boolean completedAbruptly = true;
        try { 
            while (task != null || (task = getTask()) != null) { 
                w.lock();
                // If pool is stopping, ensure thread is interrupted;
                // if not, ensure thread is not interrupted. This
                // requires a recheck in second case to deal with
                // shutdownNow race while clearing interrupt
                if ((runStateAtLeast(ctl.get(), STOP) ||
                     (Thread.interrupted() &&
                      runStateAtLeast(ctl.get(), STOP))) &&
                    !wt.isInterrupted())
                    wt.interrupt();
                try { 
                    beforeExecute(wt, task);
                    Throwable thrown = null;
                    try { 
                        task.run();
                    } catch (RuntimeException x) { 
                        thrown = x; throw x;
                    } catch (Error x) { 
                        thrown = x; throw x;
                    } catch (Throwable x) { 
                        thrown = x; throw new Error(x);
                    } finally { 
                        afterExecute(task, thrown);
                    }
                } finally { 
                    task = null;
                    w.completedTasks++;
                    w.unlock();
                }
            }
            completedAbruptly = false;
        } finally { 
            processWorkerExit(w, completedAbruptly);
        }
    }

--------------------

## 4、线程池在业务中的实践 ##

### 4.1、快速响应用户请求 ###

**描述：** 用户发起的实时请求，服务追求响应时间。比如说用户要查看一个商品的信息，那么我们需要将商品维度的一系列信息如商品的价格、优惠、库存、图片等等聚合起来，展示给用户。  
       **分析：** 从用户体验角度看，这个结果响应的越快越好，如果一个页面半天都刷不出，用户可能就放弃查看这个商品了。而面向用户的功能聚合通常非常复杂，伴随着调用与调用之间的级联、多级级联等情况，业务开发往往会选择使用线程池这种简单的方式，将调用封装成任务并行的执行，缩短总体响应时间。另外，使用线程池也是有考量的，这种场景最重要的就是获取最大的响应速度去满足用户，所以应该不设置队列去缓冲并发任务，调高corePoolSize和maxPoolSize去尽可能创造多的线程快速执行任务。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 13]  
       **事故描述：** 页面展示接口产生大量调用降级，数量级在几十到上百。  
       **事故原因：** 该服务展示接口内部逻辑使用线程池做并行计算，由于没有预估好调用的流量，导致最大核心数设置偏小，大量抛出RejectedExecutionException，触发接口降级条件，示意图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 14]

### 4.2、快速处理批量任务 ###

**描述：** 离线的大量计算任务，需要快速执行。比如说，统计某个报表，需要计算出全国各个门店中有哪些商品有某种属性，用于后续营销策略的分析，那么我们需要查询全国所有门店中的所有商品，并且记录具有某属性的商品，然后快速生成报表。  
       **分析：** 这种场景需要执行大量的任务，我们也会希望任务执行的越快越好。这种情况下，也应该使用多线程策略，并行计算。但与响应速度优先的场景区别在于，这类场景任务量巨大，并不需要瞬时的完成，而是关注如何使用有限的资源，尽可能在单位时间内处理更多的任务，也就是吞吐量优先的问题。所以应该设置队列去缓冲并发任务，调整合适的corePoolSize去设置处理任务的线程数。在这里，设置的线程数过多可能还会引发线程上下文切换频繁的问题，也会降低处理任务的速度，降低吞吐量。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 15]  
       **事故描述：** 业务提供的服务执行时间过长，作为上游服务整体超时，大量下游服务调用失败。  
       **事故原因：** 该服务处理请求内部逻辑使用线程池做资源隔离，由于队列设置过长，最大线程数设置失效，导致请求数量增加时，大量任务堆积在队列中，任务执行时间过长，最终导致下游服务的大量调用超时失败。示意图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 16]

### 4.3、解决方案 ###

根据上面的描述，出现问题的核心就是参数配置的问题，只要我们解决了参数配置，就可以解决了。

#### 4.3.1、能否不用线程池? ####

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

#### 4.3.2、追求参数设置合理性？ ####

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

#### 4.3.3、线程池参数动态化？（推荐） ####

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

由于篇幅问题，下一篇文章讲：待更新

--------------------

## 5、往期佳文 ##

### 5.1、面试系列 ###

1、[吊打面试官之一面自我介绍][Link 1]  
2、[吊打面试官之一面项目介绍][Link 2]  
3、[吊打面试官之一面系统架构设计][Link 3]  
4、[吊打面试官之一面你负责哪一块][Link 4]  
5、[吊打面试官之一面试官提问][Link 5]  
6、[吊打面试官之一面你有什么问题吗][Link 6]

······持续更新中······

--------------------

### 5.2、技术系列 ###

1、[吊打面试官之分布式会话][Link 7]  
2、[吊打面试官之分布式锁][Link 8]  
3、[吊打面试官之乐观锁][Link 9]  
4、[吊打面试官之幂等性问题][Link 10]  
5、[吊打面试关之分布式事务][Link 11]  
6、[吊打面试官之项目线上问题排查][Link 12]

······持续更新中······

### 5.3、源码系列 ###

1、[源码分析之SpringBoot启动流程原理][SpringBoot]  
2、[源码分析之SpringBoot自动装配原理][SpringBoot 1]  
3、[源码分析之ArrayList容器][ArrayList]  
4、[源码分析之LinkedList容器][LinkedList]  
5、[源码分析之HashMap容器][HashMap]  
6、[源码分析之ConcurrentHashMap容器][ConcurrentHashMap]  
7、[源码分析之五种Map容器的区别][Map]

······持续更新中······

### 5.4、数据结构和算法系列 ###

1、[数据结构之八大数据结构][Link 13]  
2、[数据结构之动态查找树（二叉查找树，平衡二叉树，红黑树）][Link 14]

······持续更新中······

### 5.5、并发系列 ###

1、[并发系列之初识多线程][Link 15]  
2、[并发系列之JMM内存模型][JMM]  
3、[并发系列之synchronized解析][synchronized]  
4、[并发系列之volatile解析][volatile]  
5、[并发系列之synchronized与volatile的区别][synchronized_volatile]  
6、[并发系列之Lock解析][Lock]  
7、[并发系列之synchronized与lock的区别][synchronized_lock]  
8、[并发系列之CAS与原子操作][CAS]  
9、[并发系列之AQS分析][AQS]

······持续更新中······

--------------------

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70]: /images/20221022/1eedfafac157438eb862372a818d505e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 1]: /images/20221022/fec22975352a44a58f1e47a5fbd8905d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 2]: /images/20221022/b1fba2cee6dc4fb999073f16ed383836.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 3]: /images/20221022/c97c188eb0a64380ab1d53de5bd25903.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 4]: /images/20221022/231f4c6a4b14404b94601605ff18c9f9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 5]: /images/20221022/a756e79d9f7f4e57acd5db374a2091cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 6]: /images/20221022/5df8d6fc3c3e41acb778686f53f7fbe7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 7]: /images/20221022/9b7fdc4ea54041219e158ed27f5f007d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 8]: /images/20221022/d5e4ce0fd3774a959678725713057d9f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 9]: /images/20221022/c58f2d21601144238b1510c29ab76b5b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 10]: /images/20221022/0628026b2093420793b98de7a9ffb663.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 11]: /images/20221022/b0137b111b05444d851e61d14da6159d.png
[20210413102155190.png]: /images/20221022/c0dd7d4ac5e84cb695ccf5b05b286384.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 12]: /images/20221022/e602d8ef3c3246ff9d5880959bfc05a1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 13]: /images/20221022/2f5467e767c442949c9f9132694493de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 14]: /images/20221022/b6575d81813e4f8e8247763db0638b88.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 15]: /images/20221022/d51959fad2254e24b78f69ac2dc92630.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 16]: /images/20221022/5abc9d809a2c40479f2288f21eeafb60.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 17]: /images/20221022/5bbb2bf5b2e2405fbebfcc5c1dde33dc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 18]: /images/20221022/54526f7877bd444694769f52de486435.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d0eWljeQ_size_16_color_FFFFFF_t_70 19]: /images/20221022/08ff7931910c48e89fd9d57cc8531594.png
[Link 1]: https://blog.csdn.net/wtyicy/article/details/114933478
[Link 2]: https://blog.csdn.net/wtyicy/article/details/114983053
[Link 3]: https://blog.csdn.net/wtyicy/article/details/115005012
[Link 4]: https://blog.csdn.net/wtyicy/article/details/115064661
[Link 5]: https://blog.csdn.net/wtyicy/article/details/115296365
[Link 6]: https://blog.csdn.net/wtyicy/article/details/115402511
[Link 7]: https://blog.csdn.net/wtyicy/article/details/114685293
[Link 8]: https://blog.csdn.net/wtyicy/article/details/114915987
[Link 9]: https://blog.csdn.net/wtyicy/article/details/114915177
[Link 10]: https://blog.csdn.net/wtyicy/article/details/114888754
[Link 11]: https://blog.csdn.net/wtyicy/article/details/115081790
[Link 12]: https://blog.csdn.net/wtyicy/article/details/115292969
[SpringBoot]: https://blog.csdn.net/wtyicy/article/details/115181539
[SpringBoot 1]: https://blog.csdn.net/wtyicy/article/details/115233701
[ArrayList]: https://blog.csdn.net/wtyicy/article/details/115244565
[LinkedList]: https://blog.csdn.net/wtyicy/article/details/115314536
[HashMap]: https://blog.csdn.net/wtyicy/article/details/115365586
[ConcurrentHashMap]: https://blog.csdn.net/wtyicy/article/details/115549277
[Map]: https://blog.csdn.net/wtyicy/article/details/115551781
[Link 13]: https://blog.csdn.net/wtyicy/article/details/115342236
[Link 14]: https://blog.csdn.net/wtyicy/article/details/115353145
[Link 15]: https://blog.csdn.net/wtyicy/article/details/115386707
[JMM]: https://blog.csdn.net/wtyicy/article/details/115455467
[synchronized]: https://blog.csdn.net/wtyicy/article/details/115454573
[volatile]: https://blog.csdn.net/wtyicy/article/details/115502376
[synchronized_volatile]: https://blog.csdn.net/wtyicy/article/details/115512541
[Lock]: https://blog.csdn.net/wtyicy/article/details/115524613
[synchronized_lock]: https://blog.csdn.net/wtyicy/article/details/115536187
[CAS]: https://blog.csdn.net/wtyicy/article/details/115611453
[AQS]: https://blog.csdn.net/wtyicy/article/details/115614355