并发线程池

Java中的线程池是运用场景最多的并发框架,几乎所有需要异步或并发执行任务的程序都可以使用线程池。线程池就像数据库连接池的作用类似,只是线程池是用来重复管理线程避免创建大量线程增加开销。

合理的使用线程池:

-  降低创建线程和销毁线程的性能开销
- 合理的设置线程池大小可以避免因为线程数超出硬件资源瓶颈带来的问题,类似起到了限流的作用;线程是稀缺资源,如果无线创建,会造成系统稳定性问题

线程池的使用:

JDK 为我们内置了几种常见线程池的实现,均可以使用 Executors 工厂类创建为了更好的控制多线程,JDK提供了一套线程框架Executor,帮助开发人员有效的进行线程控制。它们都在java.util.concurrent包中,
是JDK并发包的核心。其中有一个比较重要的类:Executors,他扮演着线程工厂的角色,我们通过Executors可以创建特定功能的线程池。

ThreadPoolExecutor

new ThreadPoolExecutor() 包含四种构造方法

参数最多的构造方法:

  public ThreadPoolExecutor(int corePoolSize, // 1
                               int maximumPoolSize,  // 2
                               long keepAliveTime,  // 3
                               TimeUnit unit,  // 4
                               BlockingQueue<Runnable workQueue, // 5
                               ThreadFactory threadFactory,  // 6
                               RejectedExecutionHandler handler ) //7

含义:

序号 名称 类型 含义
1 corePoolSize int 核心线程池大小
2 maximumPoolSize int 最大线程池大小
3 keepAliveTime long 线程最大空闲时间
4 unit TimeUnit 时间单位
5 workQueue BlockingQueue<Runnable 保存执行任务的队列
6 threadFactory ThreadFactory 线程创建工厂
7 handler RejectedExecutionHandler 拒绝策略

四种不同的线程池

FixedThreadPool

//该方法返回一个固定数量的线程池,线程数不变,当有一个任务提交时,若线程池中空闲,则立即执行,若没有,则会被暂缓在一个任务队列中,等待有空闲的线程去执行。
public static ExecutorService newFixedThreadPool(int nThreads) {
        return new ThreadPoolExecutor(nThreads, nThreads,
                                      0L, TimeUnit.MILLISECONDS,
                                      new LinkedBlockingQueue<Runnable());
    }
- corePoolSize与maximumPoolSize相等,即其线程全为核心线程,是一个固定大小的线程池,是其优势;

- keepAliveTime = 0 该参数默认对核心线程无效,而FixedThreadPool全部为核心线程;

- workQueue 为LinkedBlockingQueue(无界阻塞队列),队列最大值为Integer.MAX_VALUE。如果任务提交速度持续大余任务处理速度,会造成队列大量阻塞。因为队列很大,很有可能在拒绝策略前,内存溢出。是其劣势;

- FixedThreadPool的任务执行是无序的;

  适用场景:可用于Web服务瞬时削峰,但需注意长时间持续高峰情况造成的队列阻塞。 

CachedThreadPool

//返回一个可根据实际情况调整线程个数的线程池,不限制最大线程数量,若用空闲的线程则执行任务,若无任务则不创建线程。并且每一个空闲线程会在60秒后自动回收
public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                  60L, TimeUnit.SECONDS,
                                  new SynchronousQueue<Runnable());
}
- corePoolSize = 0,maximumPoolSize = Integer.MAX_VALUE,即线程数量几乎无限制;

- keepAliveTime = 60s,线程空闲60s后自动结束。

- workQueue 为 SynchronousQueue 同步队列,这个队列类似于一个接力棒,入队出队必须同时传递,因为CachedThreadPool线程创建无限制,不会有队列等待,所以使用SynchronousQueue;

SingleThreadExecutor

//创建一个线程的线程池,若空闲则执行,若没有空闲线程则暂缓在任务队列中
public static ExecutorService newSingleThreadExecutor() {
        return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                                    0L, TimeUnit.MILLISECONDS,
                                    new LinkedBlockingQueue<Runnable()));
 }

与FixedThreadPool(1)的比较

//添加**FinalizableDelegatedExecutorService**方法
   public static void main(String[] args) {
          ExecutorService fixedExecutorService = Executors.newFixedThreadPool(1);
          ThreadPoolExecutor threadPoolExecutor = (ThreadPoolExecutor) fixedExecutorService;
          System.out.println(threadPoolExecutor.getMaximumPoolSize());
          threadPoolExecutor.setCorePoolSize(8);  
          ExecutorService singleExecutorService = Executors.newSingleThreadExecutor();
  //      运行时异常 java.lang.ClassCastException
  //      ThreadPoolExecutor threadPoolExecutor2 = (ThreadPoolExecutor) singleExecutorService;
}

结论: FxedThreadPool可以向下转型为ThreadPoolExecutor,并对其线程池进行配置,而SingleThreadExecutor被包装后,无法成功向下转型。因此,SingleThreadExecutor被定以后,无法修改,做到了真正的Single。

ScheduledThreadPool

//创建一个可以指定线程的数量的线程池,但是这个线程池还带有延迟和周期性执行任务的功能,类似定时器。
public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
        return new ScheduledThreadPoolExecutor(corePoolSize);
    }

结论:newScheduledThreadPool调用的是ScheduledThreadPoolExecutor的构造方法,而ScheduledThreadPoolExecutor继承了ThreadPoolExecutor,构造是还是调用了其父类的构造方法。

  public ScheduledThreadPoolExecutor(int corePoolSize) {
       super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
             new DelayedWorkQueue());
  }

自定义线程池

扩展:

submit和execute的区别

执行一个任务,可以使用submit和execute,这两者有什么区别呢?

  • execute只能接受Runnable类型的任务
  • submit不管是Runnable还是Callable类型的任务都可以接受,但是Runnable返回值均为void,所以使用Future的get()获得的还是null

线程池的源码分析

  • 线程数量和线程池状态管理

    线程池用一个AtomicInteger来保存 [线程数量] 和 [线程池状态] ,一个int数值一共有32位,高3位用于保存运行状态,低29位用于保存线程数量

  private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0)); //一个原子操作类
  execute
  通过线程池的核心方法了解线程池中这些参数的含义
  private static final int COUNT_BITS = Integer.SIZE - 3; //32-3
  private static final int CAPACITY  = (1 << COUNT_BITS) - 1; //将1的二进制向右位移29位,再减
  1表示最大线程容量
  //运行状态保存在int值的高3位 (所有数值左移29位)
  private static final int RUNNING   = -1 << COUNT_BITS;// 接收新任务,并执行队列中的任务
  private static final int SHUTDOWN  =  0 << COUNT_BITS;// 不接收新任务,但是执行队列中的任务
  private static final int STOP    =  1 << COUNT_BITS;// 不接收新任务,不执行队列中的任务,中
  断正在执行中的任务
  private static final int TIDYING   =  2 << COUNT_BITS; //所有的任务都已结束,线程数量为0,处
  于该状态的线程池即将调用terminated()方法
  private static final int TERMINATED =  3 << COUNT_BITS;// terminated()方法执行完成
  // Packing and unpacking ctl
  private static int runStateOf(int c)   { return c & ~CAPACITY; } //获取运行状态
  private static int workerCountOf(int c) { return c & CAPACITY; } //获取线程数量
  • execute
  public void execute(Runnable command) {
        if (command == null)
          throw new NullPointerException();
         int c = ctl.get();
        if (workerCountOf(c) < corePoolSize) {//1.当前池中线程比核心数少,新建一个线程执行任务
          if (addWorker(command, true))
            return;
          c = ctl.get();
       }
      if (isRunning(c) && workQueue.offer(command)) {//2.核心池已满,但任务队列未满,添加到队列中
      int recheck = ctl.get();
  	//任务成功添加到队列以后,再次检查是否需要添加新的线程,因为已存在的线程可能被销毁了
      if (! isRunning(recheck) && remove(command))
        reject(command);//如果线程池处于非运行状态,并且把当前的任务从任务队列中移除成功,则拒绝该任务
      else if (workerCountOf(recheck) == 0)//如果之前的线程已被销毁完,新建一个线程
        addWorker(null, false);
   }
    else if (!addWorker(command, false)) //3.核心池已满,队列已满,试着创建一个新线程
      reject(command);  //如果创建新线程失败了,说明线程池被关闭或者线程池完全满了,拒绝任务
  }

流程图

原文地址:https://www.cnblogs.com/snail-gao/p/11761671.html