深入浅出线：程池的线程回收--回收的是非核心线程吗？

最新推荐文章于 2024-08-15 19:34:37 发布
最新推荐文章于 2024-08-15 19:34:37 发布
阅读量1.8k 收藏 9
点赞数 6
分类专栏： Java-多线程 文章标签： java 单例模式 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhujiangtaotaise/article/details/122358731
版权

写这篇文章的初衷是在和同事讨论线程池中线程去等待队列里面去取任务是随机的还是有序的，什么意思呢？举个例子，我自定义了下面一个线程池，如下：

ExecutorService executorService =
                    ThreadPoolExecutor(
                        2,
                        3,
                        60_000,
                        TimeUnit.MILLISECONDS,
                        LinkedBlockingQueue(2),
                        ZjtThreadFactory()
                    )

即核心池的大小是2，最大线程数是3，等待队列的大小是2，非核心线程存活的时间是60秒。

假设我现在向线程池中提交5个任务，每个任务耗时1s，那么按照线程池的原理，肯定是先创建2个线程（线程1和线程2）分别执行任务1和任务2，然后任务3和任务4放到等待队列中，然后再创建一个线程执行任务5，等1s任务结束后，线程1和线程2去等待队列中去取任务3和任务4执行。再然后就是任务执行完了，线程1和线程2和线程3都在等待任务，等待60秒之后会回收线程3。

注意本例中是回收线程3，并不是因为线程3是非核心线程，而是线程1和线程2执行完任务1和任务2后又去队列中取任务3和任务4执行了，线程3最先等待，所以会先回收线程3。

测试代码如下：

executorService =
    ThreadPoolExecutor(
        2,
        3,
        60_000,
        TimeUnit.MILLISECONDS,
        LinkedBlockingQueue(2),
        ZjtThreadFactory()
    )
for (i in 1..5) {
    executorService.execute {
        Log.e("zzzzz", "${Thread.currentThread().name} >> 任务 $i 开始执行")
        Thread.sleep(1000)
        Log.e("zzzzz", "${Thread.currentThread().name} >> 任务 $i 执行结束")
    }
}

看下结果是不是这样啊：

2022-01-07 10:45:13.806 30299-31786/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 1 开始执行
2022-01-07 10:45:13.806 30299-31787/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 2 开始执行
2022-01-07 10:45:13.807 30299-31788/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 5 开始执行
2022-01-07 10:45:14.807 30299-31786/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 1 执行结束
2022-01-07 10:45:14.807 30299-31787/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 2 执行结束
2022-01-07 10:45:14.807 30299-31786/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 3 开始执行
2022-01-07 10:45:14.807 30299-31788/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 5 执行结束
2022-01-07 10:45:14.807 30299-31787/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 4 开始执行
2022-01-07 10:45:15.808 30299-31786/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 3 执行结束
2022-01-07 10:45:15.809 30299-31787/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 4 执行结束

从 log 中可以看出结果和我们上面分析的一样。

  1. 首先创建线程1 和 线程2 去执行任务1 和 任务2
  2. 任务3 和 任务4 放入等待队列
  3. 创建线程3去执行任务5
  4. 线程1和线程2执行完任务1和任务2后，去等待队列中去取任务3和任务4执行
  5. 线程3执行完任务，由于等待队列中没有任务了就开始等待
  6. 线程1和线程2执行完任务后也开始等待
  7. 60秒后回收线程3，因为线程3是最先等待的，而不是因为线程3是非核心线程。

问题一、先往上面的线程池抛5个任务，延时10秒后，我们开始每隔3秒往线程池中抛一个任务，那么线程3最后会被回收吗？

条件是：10秒后，线程1，2，3都执行完任务都在等待了，线程3最先等待，然后是线程1和2。

那么问题来了：该选择哪个线程来执行这个任务呢？是随机选一个吗？

先看测试结果。
加上下面的测试代码如下：

Thread.sleep(10_000)
Thread{
    for(i in 6..10) {
        Thread.sleep(3000)
        executorService.execute {
            Log.e("zzzzz", "${Thread.currentThread().name} >> 任务 $i 开始执行")
            Thread.sleep(1000)
            Log.e("zzzzz", "${Thread.currentThread().name} >> 任务 $i 执行结束")
        }
    }
}.start()

看下结果：

2022-01-07 11:52:21.263 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 1 开始执行
2022-01-07 11:52:21.265 3701-4716/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 2 开始执行
2022-01-07 11:52:21.265 3701-4717/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 5 开始执行
2022-01-07 11:52:22.265 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 1 执行结束
2022-01-07 11:52:22.265 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 3 开始执行
2022-01-07 11:52:22.265 3701-4716/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 2 执行结束
2022-01-07 11:52:22.265 3701-4716/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 4 开始执行
2022-01-07 11:52:22.266 3701-4717/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 5 执行结束
2022-01-07 11:52:23.266 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 3 执行结束
2022-01-07 11:52:23.266 3701-4716/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 4 执行结束

// 10秒之后，线程3 开始执行任务6，每隔3秒 开始轮训 是 线程1 线程2 再到 线程3

2022-01-07 11:52:34.269 3701-4717/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 6 开始执行
2022-01-07 11:52:35.270 3701-4717/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 6 执行结束
2022-01-07 11:52:37.270 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 7 开始执行
2022-01-07 11:52:38.271 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 7 执行结束
2022-01-07 11:52:40.271 3701-4716/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 8 开始执行
2022-01-07 11:52:41.273 3701-4716/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-2 >> 任务 8 执行结束
2022-01-07 11:52:43.273 3701-4717/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 9 开始执行
2022-01-07 11:52:44.274 3701-4717/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-3 >> 任务 9 执行结束
2022-01-07 11:52:46.274 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 10 开始执行
2022-01-07 11:52:47.275 3701-4715/com.zjt.startmodepro E/zzzzz: zjt-pool-2-thread-1 >> 任务 10 执行结束

可以看到 10 秒之后，线程3 开始执行任务6，3秒后线程1执行任务7，再3秒后 线程2执行任务8，依次轮询下去直到不再有任务插入。

即在我们的案例中，虽然线程都是空闲的，但是当任务来的时候不是随机调用的，而是轮询。那么是不是所有的都是这样轮询的呢？下面我们通过源码来分析下：

3个线程都是由于等待队列为空阻塞等待，首先是线程3在 getTask 获取不到任务在阻塞等待，代码如下：

 private Runnable getTask() {
        boolean timedOut = false; // Did the last poll() time out?
        for (; ; ) {
            int c = ctl.get();
            int rs = runStateOf(c);
            // Check if queue empty only if necessary.
            if (rs >= SHUTDOWN && (rs >= STOP || workQueue.isEmpty())) { // 注1
                decrementWorkerCount();
                Log.e("test thread pool", "--getTask  c = " + ctl.get());
                return null;
            }
            int wc = workerCountOf(c);
            // allowCoreThreadTimeOut 默认为false，
            // 这里存活的线程数为3大于corePoolSize的2，所以time 为 true
            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;
            }
        }
    }

通过上面对代码的注释，可以看到 线程1 和 线程2 以及线程3通过 workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) 进行阻塞等待的，我这里的队列用的是 LinkedBlockingQueue ，poll 方法代码如下：

public E poll(long timeout, TimeUnit unit) throws InterruptedException {
    E x = null;
    int c = -1;
    long nanos = unit.toNanos(timeout);
    final AtomicInteger count = this.count;
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lockInterruptibly();
    try {
        while (count.get() == 0) {
            if (nanos <= 0L)
                return null;
            // 发现队列为空，通过 ReentrantLock 的 Condition 来实现阻塞等待线程存活时间
            nanos = notEmpty.awaitNanos(nanos);
        }
        x = dequeue();
        c = count.getAndDecrement();
        if (c > 1)
            notEmpty.signal();
    } finally {
        takeLock.unlock();
    }
    if (c == capacity)
        signalNotFull();
    return x;
}

notEmpty.awaitNanos(nanos) 的部分代码如下：

public final long awaitNanos(long nanosTimeout)
        throws InterruptedException {
    。。。。。。
    // 这里是会把 这个线程作为一个结点插入到等待队列，是队列当然是有序的
   // 注意，这里的等待队列不是线程池的等待队列，是AQS中的等待队列，可以看我关于AQS的文章分析
    Node node = addConditionWaiter();
    long savedState = fullyRelease(node);
    int interruptMode = 0;
    。。。。。。
    long remaining = deadline - System.nanoTime(); // avoid overflow
    return (remaining <= initialNanos) ? remaining : Long.MIN_VALUE;
}

关于 ReentrantLock 以及 Condition 的源码分析可参考我的另一篇文章：
ReentrantLock 以及 Condition深度解析

上面分析知道，线程3 先等待 然后是线程1，最后是线程2。所以AQS（AbstractQueuedLongSynchronizer） 中等待队列的顺序是:

在这里插入图片描述
等3秒之后往线程池里面抛一个任务后，就会唤醒 AQS中阻塞队列的第一个线程，即线程3被唤醒然后去执行任务。executorService.execute(runnable)，因为当前存活的线程数为3大于核心线程的个数2，所以直接插入队列 workQueue.offer(command):

 public boolean offer(E e) {
     if (e == null) throw new NullPointerException();
     final AtomicInteger count = this.count;
     if (count.get() == capacity)
         return false;
     int c = -1;
     Node<E> node = new Node<E>(e);
     final ReentrantLock putLock = this.putLock;
     putLock.lock();
     try {
         if (count.get() < capacity) {
             // 插入线程池的阻塞队列
             enqueue(node);
             // 注意:getAndIncrement 的操作是先将值付给c，然后再加1,
             //所以，count = 1，但是 c = 0，然后执行后面signalNotEmpty
             c = count.getAndIncrement();
             if (c + 1 < capacity)
                 notFull.signal();
         }
     } finally {
         putLock.unlock();
     }
     if (c == 0)
         signalNotEmpty();
     return c >= 0;
 }

signalNotEmpty 代码如下：

private void signalNotEmpty() {
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lock();
    try {
        notEmpty.signal(); // 唤醒AQS中阻塞的线程
    } finally {
        takeLock.unlock();
    }
}

signal 代码如下：

public final void signal() {
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    Node first = firstWaiter;
    if (first != null)
        doSignal(first);
}

这段代码最终走到的是 LockSupport.unpark(node.thread); 来唤醒线程。这段代码还是比较复杂的，可以先去看看我之前贴的链接的那篇文章。

所以1s 之后线程3完成任务，插入到AQS阻塞队列的尾部，然后再次往线程池里面抛任务的时候，这时是AQS的阻塞队列是线程1在前面，所以唤醒的是线程1去执行任务。后续逻辑就差不多了。

回收非核心线程的逻辑

也是在getTask中，部分代码如下：

private Runnable getTask() {
        boolean timedOut = false; // Did the last poll() time out?

        for (; ; ) {
            int c = ctl.get();
            。。。。。。
            int wc = workerCountOf(c);

            // Are workers subject to culling?
            boolean timed = allowCoreThreadTimeOut || wc > corePoolSize; //注1

            if ((wc > maximumPoolSize || (timed && timedOut))
                    && (wc > 1 || workQueue.isEmpty())) {//注2
                if (compareAndDecrementWorkerCount(c)) // 注3
                    return null;
                continue;
            }
           
            try {
                Runnable r = timed ?
                        workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
                        workQueue.take();//注4
                if (r != null)
                    return r;
                timedOut = true;//注5
            } catch (InterruptedException retry) {
                timedOut = false;
            }
        }
    }

注释1：boolean timed = allowCoreThreadTimeOut || wc > corePoolSize; 由于allowCoreThreadTimeOut默认是 false，但是当前线程数量wc=3 ，大于核心线程数量corePoolSize = 2，所以 timed = true。

注释2 ： (wc > maximumPoolSize || (timed && timedOut)) && (wc > 1 || workQueue.isEmpty()) wc = 3 ,且 maximumPoolSize = 3.所以不成立，timedOut = false，所以注释2 的条件不成立。

走到注释4的 workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) ，线程销毁时间60s时间到了之后，唤醒该线程，走到注释5 ， timedOut = true，接着getTask的for循环：

继续走注释2，由于此时timedOut = true，所以注释2成立。
接着走注释3，把存活的线程数量减1。然后return null。表示无任务了。

执行任务的方法 runWorker:

 final void runWorker(Worker w) {
    ......
    try {
      while (task != null || (task = getTask()) != null) {
         ......
      }
      completedAbruptly = false;
    } finally {
      processWorkerExit(w, completedAbruptly);
    }
 }

最后执行 processWorkerExit：

private void processWorkerExit(Worker w, boolean completedAbruptly) {
    Log.e("test thread pool", Thread.currentThread().getName()+ " >>> pr
    if (completedAbruptly) // If abrupt, then workerCount wasn't adjuste
        decrementWorkerCount();
    final ReentrantLock mainLock = this.mainLock;
    mainLock.lock();
    try {
        completedTaskCount += w.completedTasks;
        workers.remove(w); // 从工作列表中删除，于是线程就被回收了。
    } finally {
        mainLock.unlock();
    }
    tryTerminate(); // 中断空闲的线程
    ......
  }

所以当超过指定时间后，线程会被回收。

那么被回收的这个线程是核心线程还是非核心线程呢？

不知道。

因为在线程池里面，核心线程和非核心线程仅仅是一个概念而已，其实拿着一个线程，我们并不能知道它是核心线程还是非核心线程。

这个地方就是一个证明，因为当工作线程多余核心线程数之后，所有的线程都在 poll，也就是说所有的线程都有可能被回收：
在这里插入图片描述
举个例子来说明：

ThreadPoolExecutor(
                        1,
                        2,
                        60_000,
                        TimeUnit.MILLISECONDS,
                        LinkedBlockingQueue(2),
                        ZjtThreadFactory()
                    )

假设有4个任务，任务耗时1秒。

  1. 创建线程1 执行任务1
  2. 任务2和3放入队列
  3. 创建线程2执行任务4
  4. 1秒后线程1去队列中取任务2执行，线程2取任务3执行
  5. 再1秒后，线程1取队列中取任务，由于队列中没有任务，所以阻塞等待60秒，同理，线程2 也会阻塞等待60s
  6. 60s 后，由于是线程1先等待的，所以回收了线程1，而线程1是第一个创建的是属于"核心线程"

以上分析可知 回收的是超出核心线程数量的线程，并不一定是”非核心线程“。

小猪快跑22
关注
专栏目录
【线程池的工作参数、什么情况下会触发最大线程数？什么情况下会回收线程？】
学无止境
03-28 1789
线程池是一个重要的 Java 并发编程工具，用于控制线程的创建、调度和回收，可以有效地提高程序的性能和资源利用率。
【Java多线程】JUC之并发容器—深入剖析并发队列DelayQueue(六)
墩墩分墩
03-09 364
- **DelayQueue**： 一个`内部使用优先级队列PriorityQueue（二叉小顶堆）`实现**延迟读取** 的`无界阻塞队列`，该队列中每个元素均有*过期时间*，当从队列获取元素时，`只有过期元素才会出队列`。`队列头元素是最块要过期的元素`。**内部使用ReentrantLock和Condition实现。** - 使用**PriorityQueue**来实现队列，所以以`二叉小顶堆`结构维**护元素顺序**，**这样`剩余时间最小的元素就在堆顶`，每次出队其实就是删除剩余时间≤0的最小元
线程池的线程回收问题
m0_62565675的博客
08-02 705
线程池的线程回收问题
线程回收以及线程的问题处理
最新发布
weixin_63722559的博客
08-15 899
设置分离的状态，当一个分离的线程资源结束，他的资源自动被系统进行回收，不需要另一个线程等待回收，主线程也不需要关心子线程状态。1、pthread_join //需要自己回收 --- 线程的属性 （可结合性），阻塞，一般是子线程在较短时间内运行完。我们在做的过程中，可能还没有做完，发射了一个结束信号，线程没有结束返回的信息，故出现段错误。2、 //可分离属性 ------子线程运行很久结束 --- 设置分离属性，系统自动回收。此时执行逻辑，主线程执行流结束，进程会在其余线程都结束后，结束。
ThreadPoolExecutor线程池的非核心线程超时回收的问题
正儿八经的胡说八道的博客
05-25 685
线程池，非核心线程，超时回收
线程池回收工作者线程原理
wsndde的博客
08-18 1060
线程池是如何回收工作者线程的   首先线程池的工作者线程是不区分它是核心线程还是非核心线程的，那么线程池是如何回收掉非核心线程？又如何保证核心线程不会被回收？当然你也可以allowCoreThreadTimeOut(true)设置核心线程也过期。 runWorker()源码解析 工作者线程就是执行run()方法，然后内部调用runWorker() final void runWorker(Worker w) { Thread wt = Thread.currentThread();
并发面试题：线程池的线程回收
wcy_frist的博客
06-10 277
因为工作线程都是从阻塞队列里面去获取执行任务的，所以只要在一定的时间内，阻塞队列没有任何可以处理的任务，那么这些线程就可以结束了，而这个功能是通过阻塞队列里面的poll()方法来完成的。这个方法里面提供了超时时间和超时时间单位这两个参数，当前线程在指定的时间内没有从阻塞队列里面获取任务的时候，那么poll()方法就会返回null，从而去终止线程，完成对线程的回收。核心线程和非核心线程的数量是在构造线程池的时候去设置的，也可以动态的进行更改，由于非核心线程是为了解决任务过多的情况下临时增加的。
从入门到深入！深入浅出kubernetes（K8S）指南
m0_57066131的博客
07-05 8630
分享第一份Java基础-中级-高级面试集合 Java基础（对象+线程+字符+接口+变量+异常+方法） Java中级开发（底层+Spring相关+Redis+分布式+设计模式+MySQL+高并发+锁+线程） Java高级“程序猿”（高并发+Redis缓存+分布式+消息队列+高可用+微服务+分库分表+读写分离） 高并发系列（经典面试题：如何设计一个高并发系统？） Redis缓存系列 分布式系列 消息队列系列 高可用系列 微服务系列 分库分表系列 读写分离系列 …  … Java高
Go 并发编程 — 深入浅出 sync.Pool ，围观最全的使用姿势，理解最深刻的原理
伢之国
02-22 504
更多干货，关注公众号：奇伢云存储 文章目录使用姿势初始化 Pool 实例 New申请对象 Get释放对象 Put思考为什么用 Pool，而不是在运行的时候直接实例化对象呢？`sync.Pool` 是线程安全的吗？为什么 `sync.Pool` 不适合用于像 socket 长连接或数据库连接池?总结 Go 并发相关库 sync 里面有一个有趣的 package Pool，sync.Pool 是个有趣的库，用很少的代码实现了很巧的功能。 第一眼看到 Pool 这个名字，就让人想到池子，元素池化是常用的性能优.
由浅入深Linux下pthread线程库介绍
02-06
本文旨在深入浅出地介绍 Linux 下 pthread 线程库的相关知识。 #### 二、多线程的优势 多线程程序能够带来诸多优势： 1. **提高应用程序响应性**：对于图形界面程序而言，当某项操作耗时较长时，如果将该操作置于...
Linux中的线程
zsffzb的博客
11-04 1684
1.线程的基本概念 2.线程和进程的区别 *线程的同步 线程的调度 线程的通信编程思想之多线程与多进程(1)——以操作系统的角度述说线程与进程_阳光日志-CSDN博客_多线程和多进程编程线程是什么？要理解这个概念，须要先了解一下操作系统的一些相关概念。大部分操作系统(如Windows、Linux)的任务调度是采用时间片轮转的抢占式调度方式，也就是说一个任务执行一小段时间后强制暂停去执行下一个任务，每个任务轮流执行。任务执行的一小段时间叫做时间片，任务正在执行时的状态叫运行状态，任务执行一段时间后强制
Java线程池ExecutorService
tooky_poom的博客
03-14 301
开篇前，我们先来看看不使用线程池的情况：new Thread的弊端执行一个异步任务你还只是如下new Thread吗？new Thread(new Runnable() { @Override public void run() { // TODO Auto-generated method stub } }).start();那你就太out了，new ...
Java ExecutorService线程池
lulu147的专栏
10-29 272
1、new Thread的弊端 执行一个异步任务你还只是如下new Thread吗？ new Thread(new Runnable() { @Override public void run() { // TODO Auto-generated method stub } }).start(); 那你就out太多了，new Thread的弊端如...
解决Java线程池任务执行完毕后线程回收问题
热门推荐
zdy0_2004的专栏
12-03 2万+
http://www.cnblogs.com/pengineer/p/5011965.html       对于经常使用第三方框架进行web开发的程序员来说，Java线程池理所应当是非常智能的，线程的生命周期应该完全由Java本身控制，我们要做的就是添加任务和执行任务。但是，最近做文档批量上传同步时发现线程池中的所有任务执行完毕后，线程并没有停止，然后做了一个测试，发现确实如此：   问题及
ExecutorService线程池
musicwHello
05-08 234
下面 博客介绍的很详细：http://www.cnblogs.com/whoislcj/p/5607734.html-----------------------------------------------------------------&gt;为什么要引入线程池？new Thread()的缺点每次new Thread()耗费性能调用new Thread()创建的线程缺乏管理，被称为野线程...
线程池ExecutorService
小生不才的博客
01-14 533
1.创建方式 Executors ThreadPoolExecutor 2.七大参数 2.1.corePoolSize 核心线程数(一直存在除非设置allowCoreThreadTimeOut),线程池创建好就准备就绪的线程数量,就等待来接受异步任务去执行 2.2.maximumPoolSize 最大线程数 2.3.keepAliveTime 存活时间,如果线程数量大于核心线程数量,释放空闲线程(maximumPoolSize-corePoolSize) 2.4.unit 时间单位 2.5.workQu
java的线程池-ExecutorService
@@老胡的博客
09-17 693
目录结构ExecutorService继承树原理相关参数ThreadPoolExecutor参数corePoolSize、maximumPoolSize、RejectedExecutionHanderkeepAliveTime、TimeUnitworkQueneRejectedExecutionHander创建ExecutorService ExecutorService 继承树 ExecutorService是java对线程池定义的一个接口，也是java默认给我们的，它具有两个实现类： ThreadP
ExecutorService线程池的创建、钩子、销毁等相关操作
weixin_41590779的博客
08-05 2668
创建线程池 执行说明 图解 步骤 1、创建线程池对线时候不会创建线程，当有第一个线程任务时，才会创建线程。 2、如果线程数少于核心线程数时，当有新的线程来，不管之前的线程是否空闲，都会继续创建新的线程，直到达到核心线程数。 3、当线程数等于核心线程数时，当有新线程来，先放入任务队列中等待核心线程执行完毕之后取出任务队列中任务执行，直到线程队列达到最大容量。 4、当线程数大于队列最大容量时候，会创建非核心线程来执行任务，直到达到最大线程数（maximumPoolSize）。 5、当线程数等于最大线程数时，
关于线程池 ExecutorService 的总结
Eaphy's Blog
04-29 744
一 、Java通过Executors提供四种线程池： newCachedThreadPool创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。 newFixedThreadPool 创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。 newScheduledThreadPool 创建一个定长线程池，支持定时及周期性任务执行。...
多线程深入探索：构建高级生产者-消费者队列
"本文深入探讨了多线程编程中的生产者-消费者队列模型，通过使用Wait和Pulse方法来创建一个支持多个消费者的版本。这个队列允许每个消费者在线程中独立运行，确保了任务的并发处理。文章还介绍了如何使用Thread数组...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值