当前位置：首页 > news >正文

Java线程池原理深度解析

news 2025/11/15 12:39:37

一、七大参数

Java自定义线程池有七大参数，分别为核心线程数、最大线程数、阻塞队列、存活时间、时间单位、线程工厂和拒绝策略。为方便理解，下面将通过举例分析自定义线程池的工作流程。

二、举例分析

假定自定义了一个线程池，参数如下：

核心线程数：6
最大线程数：10
阻塞队列：5
存活时间：30
时间单位：s
线程工厂：默认
拒绝策略：默认

一开始，线程池中是一个线程都没有的。此时，请求1过来了，请求1来到线程池后，首先会判断池中线程数是否达到核心线程数，很显然，没有达到，所以线程池就会创建出线程1，然后请求1不用入队直接被线程1处理。紧接着，请求2也来了，请求2来到线程池后，也是先判断池中线程数是否达到核心线程数，没有达到，则创建线程2，然后请求2不用入队直接被线程2处理。请求3、请求4、请求5和请求6都是同理，经过以上流程后，线程池分别创建出线程3、线程4、线程5和线程6来处理这三个请求。

到请求7的时候，情况就有所不同了，请求7来到线程池，同样是判断池中线程数是否达到核心线程数，经过判断，发现池中线程数已经达到核心线程数了，此时就不用创建新线程了，而是去入队。当然入队之前还有一个操作，需要先判断阻塞队列有没有满，显而易见，阻塞队列并没有满，所以请求7直接入队。这里要提一点，假定这些请求都极其耗时，所以先创建的6个线程并没有空闲来队列里获取任务。请求8也是先判断池中线程数是否达到核心线程数，发现池中线程数已经达到核心线程数，于是就去判断阻塞队列有没有满，没满，则入队。请求9、请求10和请求11也是同理，那么此时线程池中的情况就为：先去6个线程正在处理最开始的6个请求，而后面来的5个请求则是进入到阻塞队列中等待，可以看出阻塞队列已经满了。

那请求12来了会怎么样呢？请求12来了之后，同样的操作，判断池中线程数是否达到核心线程数，达到了，就尝试入队，结果发现阻塞队列已经满了，无法入队。既然无法入队，那就执行其他操作。此时请求12会判断池中线程数是否达到最大线程数，可以发现池中线程数并没有达到最大线程数，所以，线程池会创建线程7，紧接着，线程7略过阻塞队列中正在等待的任务，直接处理请求12，这里请求12的插队行为，让人不由地想到非公平锁，可以感受到线程池是带有非公平思想在里面的。接下来的请求13、请求14和请求15同理，都是判断池中线程数是否达到核心线程数，达到了，就尝试入队，发现阻塞队列已经满了，入队失败就判断池中线程数是否达到最大线程数，没达到，则创建线程，并略过阻塞队列中正在等待的任务直接处理请求13、请求14和请求15。到这时，线程池中的情景就变为了线程1~6分别处理请求1~6，线程7~10分别处理请求12~15，请求7~11在阻塞队列中等待。

此时若是再来个请求16，线程池会如何应对呢？前面的操作都是一样的，判断池中线程数是否达到核心线程数，达到了，则尝试入队，发现阻塞队列已满，则判断池中线程数是否达到最大线程数，达到了，则触发拒绝策略，而默认拒接策略是丢弃任务并抛异常，所以请求16被丢弃，同时线程池抛个异常出来。

现在，我们假设线程1~10陆续处理完手头上的任务，那么这些线程就会到阻塞队列中获取新的任务，获取到后进行处理，处理完后再次获取，循环往复。等到所有任务都处理完，阻塞队列为空时，线程1~10再去阻塞队列获取请求，就会在阻塞队列处，被阻塞队列给阻塞。这时，若是在存活时间(30s)内都没有新的请求过来，线程池就会用CAS随机销毁掉四个多余的线程，使池中线程数刚好为核心线程数；反之，若是在存活时间(30s)内有新的请求过来，线程池就不会销毁多余的四个线程。为什么是四个线程呢？自然是因为池中线程数比核心线程数多了四个。

三、源码分析

1、问题提出及源码

其实有个问题需要了解，那就是正常来讲线程执行完逻辑后就会消失，那么，线程池是如何做到保留核心线程数的呢？从上面可知，线程池是通过阻塞队列来保留核心线程数，所以直接上源码，看看它究竟怎么保留核心线程数。

    final void runWorker(Worker w) {Thread wt = Thread.currentThread();Runnable task = w.firstTask;w.firstTask = null;w.unlock(); // allow interruptsboolean 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 interruptif ((runStateAtLeast(ctl.get(), STOP) ||(Thread.interrupted() &&runStateAtLeast(ctl.get(), STOP))) &&!wt.isInterrupted())wt.interrupt();try {beforeExecute(wt, task);try {task.run();afterExecute(task, null);} catch (Throwable ex) {afterExecute(task, ex);throw ex;}} finally {task = null;w.completedTasks++;w.unlock();}}completedAbruptly = false;} finally {processWorkerExit(w, completedAbruptly);}}

上面runWorker方法中，最需要关注的是while循环条件里的getTask方法，这是核心，下方有展示getTask方法的代码。

    private Runnable getTask() {boolean timedOut = false; // Did the last poll() time out?for (;;) {int c = ctl.get();// Check if queue empty only if necessary.if (runStateAtLeast(c, SHUTDOWN)&& (runStateAtLeast(c, STOP) || workQueue.isEmpty())) {decrementWorkerCount();return null;}int wc = workerCountOf(c);// Are workers subject to culling?boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;if ((wc > maximumPoolSize || (timed && timedOut))&& (wc > 1 || workQueue.isEmpty())) {if (compareAndDecrementWorkerCount(c))return null;continue;}try {Runnable r = timed ?workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :workQueue.take();if (r != null)return r;timedOut = true;} catch (InterruptedException retry) {timedOut = false;}}}

2、分析

为方便理解，我会把前面的例子和这里的源码结合起来分析。

看方法名就知道，这是获取任务时执行的代码，在getTask中有个死循环，进入其中后，通过int wc = workerCountOf(c);获取并记录池中线程数为10，boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;这里allowCoreThreadTimeOut默认为false，corePoolSize指的是核心线程数8，10 > 8，所以timed为true。

接下来有个if语句，其中maximumPoolSize代表最大线程数10，所以wc > maximumPoolSize为false，后面的timed为true，timedOut代表是否超时，在getTask方法刚开始，还没进入循环时就被赋值为false，所以timed && timedOut为false，所以(wc > maximumPoolSize || (timed && timedOut)) && (wc > 1 || workQueue.isEmpty())为false，进不了if。

然后就到了try块中了，timed为true，所以执行workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS)，这个方法会去阻塞队列获取任务，若是在规定时间内获取到任务，则r != null为true，直接return r；若是没有获取到任务，则将timedOut设为true，然后接着循环。

假设都没获取到任务，那么这10个线程都会接着循环，都会得到池中线程池为10，然后10 > 8，所以timed为true。到if这里的时候，由于timed和timedOut都为true，所以timed && timedOut为true，于是我们成功进入到了if中，这里就会执行CAS操作，随机销毁一个线程。

被销毁的线程return走了，没有被销毁的线程通过continue接着循环，接着销毁线程，直到池中线程数wc不大于corePoolSize，也就是池中线程数等于核心线程数时，timed为false，无法进入if，进而执行try块。由于timed为false，所以这次进入try块执行的是workQueue.take()。

对于take方法，若是队列中有任务，那就获取任务并返回；若是队列中没有任务，线程就会阻塞等待，直到队列中有新的任务进来，该线程才会被唤醒并获取任务，获取成功后返回。

正是take方法阻塞式获取的特性，才不会让线程因为没有任务可执行而消失，这样就成功地保留住核心线程数了。