Loading...

Java多线程(三)——FutureTask/CompletableFuture

  iwehdio的博客园:https://www.cnblogs.com/iwehdio/

学习自:

1、FutureTask

  • 无论是Runnable还是Callable,它们其实和线程没半毛钱关系,它们是任务类,只有Thread是线程类。

  • JDK那么多类,有且仅有Thread类能通过start0()方法向操作系统申请线程资源(本地方法)。

    image-20210114210703219

  • 并且,在JVM的设定中Java的线程和操作系统的线程是一一对应的:

    image-20210114210741531

  • 而Runnable和Callable如果没有线程或线程池去执行它们,就什么也不是,只是一坨普通的代码。

    public class AsyncAndWaitTest {
    
        public static void main(String[] args) throws ExecutionException, InterruptedException {
            // 方式1:重写Thread#run()
            Thread thread = new Thread() {
                @Override
                public void run() {
                    System.out.println(Thread.currentThread().getName() + "========>正在执行");
                }
            };
            thread.start();
    
            // 方式2:构造方法传入Runnable实例
            new Thread(() -> {
                System.out.println(Thread.currentThread().getName() + "========>正在执行");
            }).start();
    
            // 方式3:线程池 + Callable
            ExecutorService executorService = Executors.newSingleThreadExecutor();
            Future<String> submit = executorService.submit(() -> {
                System.out.println(Thread.currentThread().getName() + "========>正在执行");
                Thread.sleep(3 * 1000L);
                return "success";
            });
            String result = submit.get();
            System.out.println("result=======>" + result);
            // 关闭线程池
            executorService.shutdown();
        }
    }
    
  • FutureTask = 任务 + 结果。

    • 第四种方法:通过Thread的构造器传入Runnable实例(FutureTask,内部包装了Runnable/Callable)。
    • 基本使用:
    public class AsyncAndWaitTest {
    
        public static void main(String[] args) throws ExecutionException, InterruptedException {
    
            // FutureTask实现了Runnable,可以看做是一个任务
            FutureTask<String> futureTask = new FutureTask<>(new Callable<String>() {
                @Override
                public String call() throws Exception {
                    System.out.println(Thread.currentThread().getName() + "========>正在执行");
                    try {
                        Thread.sleep(3 * 1000L);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    return "success";
                }
            });
            
            System.out.println(Thread.currentThread().getName() + "========>启动任务");
    
            // 传入futureTask,启动线程执行任务
            new Thread(futureTask).start();
    
            // 但它同时又实现了Future,可以获取异步结果(会阻塞3秒)
            String result = futureTask.get();
            System.out.println("任务执行结束,result====>" + result);
        }
    
    }
    
  • FutureTask这个名字!它既是一个任务,又能存储任务执行的结果。反映在程序上就是既能传入Thread执行,又能通过futureTask.get()获取任务执行结果。

image-20210114211605350

  • FutureTask有以下2个特征:

    • 能包装Runnable和Callable(构造器传入),但本身却又实现了Runnable接口,即本质是Runnable。
    • 既然是Runnable,所以FutureTask能作为任务被Thread执行,但诡异的是FutureTask#get()可以获取结果。
  • FutureTask如何包装Runnable/Callable:

    • 使用:

      image-20210114211841491

    • 通过FutureTask构造器传入Runnable/Callable的,所以我们去看看FutureTask的构造器:

      image-20210114211941786

    • FutureTask内部维护Callable类型的成员变量,对于Callable任务,直接赋值即可:

      image-20210114212020753

    • 而对于Runnable任务,需要先调用Executors#callable()把Runnable先包装成Callable:

      image-20210114212109758

    • Executors#callable()用到了适配器模式:

      image-20210114212158174

    • 而RunnableAdapter实现了Callable接口,所以包装后的RunnableAdapter可以赋值给FutureTask.callable。

      image-20210114212212182

    • 也就是说:

      • Runnable --> Executors.callable() --> RunnableAdapter implements Callable --> FutureTask.callable
      • Callable --> FutureTask.callable
  • Runnable和Callable的返回值问题:

    • Callable#call()是有返回值的,而Runnable#run()没有。它们都包装成FutureTask后,一个有返回值,一个没返回值,怎么处理呢。

    • 设计成有返回值的,毕竟Callable.call()明明有返回值,你总不能硬生生丢掉吧。至于Runnable.run()确实没返回值,但也好办,搞个假的返回即可。

      image-20210114212450677

    • 等到Thread执行FutureTask时,会先取出FutureTask.callable,然后调用callable.call():

      • 如果是真的Callable,调用Callable.call()会返回真实的result
      • 如果是Runnable包装的RunnableAdapter,会返回事先传入的result
      • 这也是上面的程序中,为什么Runnable要多传一个参数的原因
  • FutureTask是如何被Thread执行的:

    • thread执行自己的run方法。这里的target是FutureTask,所以target.run()就是FutureTask#run()。

      image-20210114212942670

    • 结果最终存哪呢?

      image-20210114213058867

    • 也是FutureTask的一个成员变量:

      image-20210114213115890

    • 进一步印证了说 FutureTask = 任务 + 结果。

  • 为什么get()是阻塞的?

    • 在FutureTask中定义了很多任务状态:

      image-20210114213239662

      • 刚创建
      • 即将完成
      • 完成
      • 抛异常
      • 任务取消
      • 任务即将被打断
      • 任务被打断
    • 这些状态的设置意义在哪?

      • 一个任务,有时可能非常耗时。而当用户使用futureTask.get()时,必然是希望获取最终结果的。如果FutureTask不帮我们阻塞,就有可能获取空结果。此时为了获取最终结果,用户不得不在外部自己写阻塞程序。
      • 所以,get()内部会判断当前任务的状态,只有当任务完成才返回。
    • 线程从阻塞到获取结果,中间必然经历类似唤醒的操作,怎么做到的?

      • 秘密就在awaitDone():核心的就是 for循环 + LockSupport。
      • LockSupport是一个线程阻塞工具类,所有的方法都是静态方法,可以让线程在任意位置阻塞,当然也有唤醒的方法。
      • LockSupport主要有两类方法:parkunpark。即让线程停下和启动。

      image-20210114213403621

      • 类似于:

        public class ParkTest {
        
            @Test
            public void testPark() throws InterruptedException {
                // 存储线程
                List<Thread> threadList = new ArrayList<>();
        
                // 创建5个线程
                for (int i = 0; i < 5; i++) {
                    Thread thread = new Thread(() -> {
                        System.out.println("我是" + Thread.currentThread().getName() + ", 我开始工作了~");
                        LockSupport.park(this);
                        System.out.println("我是" + Thread.currentThread().getName() + ", 我又活过来了~");
                    });
                    thread.start();
                    threadList.add(thread);
                }
        
                Thread.sleep(3 * 1000L);
                System.out.println("====== 所有线程都阻塞了,3秒后全部恢复了 ======");
        
                // unPark()所有线程
                for (Thread thread : threadList) {
                    LockSupport.unpark(thread);
                }
        
                // 等所有线程执行完毕
                Thread.sleep(3 * 1000L);
            }
        
        }
        
    • 也就是说,调用get()后,如果当前没有结果,就会被park(),等有了结果再unpark()并往下走:

      image-20210114213807726

    • 取出outcome返回:

      image-20210114213822669

  • FutureTask如何异步返回结果:

    image-20210114214552476

    • 往线程池submit了一个Callable,结果马上返回了result(FutureTask):

      image-20210114214746646

    • 观察:

      • 返回的FutureTask里包含刚才丢进去的Callable
      • result.outcome目前还是null
    • 实际上,返回的futureTask并不是真正的结果,它内部持有outcome引用,它才指向真正的结果。而在任务完成之前,outcome引用指向的是null。

      image-20210114214843951

  • 何时调用futureTask.get()?

    • 用户调用get()必然是想到得到最终结果的,所以为了保证一定能得到结果,JDK把FutureTask#get()设计成阻塞的。

    • 建议不要立即调用get(),否则程序完全没有发挥异步优势,由异步阻塞变成同步阻塞。

      image-20210114215039393

    • 开启多线程,当然应该发挥多线程的优势:

      image-20210114215102247

      image-20210114215154400

  • isDone() + get():

    • 但是实际开发时,异步线程具体会耗时多久有时很难预估,受网络、数据库等各方面影响。所以很难做到在合适的地方get()然后一击即中。
    • FutureTask提供了isDone()方法:

    image-20210114215310620

    • 当然,这种做法也不是很优雅。JDK1.8提供了CompletableFuture解决这个问题。

2、CompletableFuture

  • FutureTask#get()本身是阻塞的,假设当前有三个下载任务在执行:

    • task1(预计耗时5秒)
    • task2(预计耗时1秒)
    • task3(预计耗时1秒)
  • 如果阻塞获取时不凑巧把task1.get()排在最前面,那么会造成一定的资源浪费,因为task2和task3早就已经准备好了,可以先拿出来处理,以获得最佳的用户体验。

    image-20210115192952604

  • 虽然可以结合轮询+isDone()的方式改进,但仍存在以下问题:

    • 轮询间隔多少合适?
    • 为了避免while(true)阻塞主线程逻辑,可能需要开启单独的线程轮询,浪费一个线程。
    • 仍然无法处理复杂的任务依赖关系。
  • CompletableFuture的简单使用:

    @Test
    public void testCallBack() throws InterruptedException, ExecutionException {
        // 提交一个任务,返回CompletableFuture
        CompletableFuture<String> completableFuture = CompletableFuture.supplyAsync(new Supplier<String>() {
            @Override
            public String get() {
                System.out.println("=============>异步线程开始...");
                System.out.println("=============>异步线程为:" + Thread.currentThread().getName());
                try {
                    TimeUnit.SECONDS.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("=============>异步线程结束...");
                return "supplierResult";
            }
        });
        
    	// 阻塞获取结果
        System.out.println("异步结果是:" + completableFuture.get());
        System.out.println("main结束");
    }
    
    • 整个过程看起来和同步没啥区别,因为我们在main线程中使用了CompletableFuture#get(),直接阻塞了。

    image-20210115193510981

    • CompletableFuture和FutureTask的异同点:

      • 相同:都实现了Future接口,所以都可以使用诸如Future#get()、Future#isDone()、Future#cancel()等方法

      • 不同:

        • FutureTask实现了Runnable,所以它可以作为任务被执行,且内部维护outcome,可以存储结果
        • CompletableFuture没有实现Runnable,无法作为任务被执行,所以你无法把它直接丢给线程池执行,相反地,你可以把Supplier#get()这样的函数式接口实现类丢给它执行
        • CompletableFuture实现了CompletionStage,支持异步回调
    • FutureTask和CompletableFuture最大的区别在于,FutureTask需要我们主动阻塞获取,而CompletableFuture支持异步回调。

    • CompletableFuture好像承担的其实是线程池的角色,而Supplier#get()则对应Runnable#run()、Callable#call()。

  • CompletionStage的基本使用:

    @Test
    public void testCallBack() throws InterruptedException, ExecutionException {
        // 提交一个任务,返回CompletableFuture(注意,并不是把CompletableFuture提交到线程池,它没有实现Runnable)
        CompletableFuture<String> completableFuture = CompletableFuture.supplyAsync(new Supplier<String>() {
            @Override
            public String get() {
                System.out.println("=============>异步线程开始...");
                System.out.println("=============>异步线程为:" + Thread.currentThread().getName());
                try {
                    TimeUnit.SECONDS.sleep(10);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("=============>异步线程结束...");
                return "supplierResult";
            }
        });
    
        // 异步回调:上面的Supplier#get()返回结果后,异步线程会回调BiConsumer#accept()
        completableFuture.whenComplete(new BiConsumer<String, Throwable>() {
            @Override
            public void accept(String s, Throwable throwable) {
                System.out.println("=============>异步任务结束回调...");
                System.out.println("=============>回调线程为:" + Thread.currentThread().getName());
            }
        });
    
        // CompletableFuture的异步线程是守护线程,一旦main结束就没了,为了看到打印结果,需要让main休眠一会儿
        System.out.println("main结束");
        TimeUnit.SECONDS.sleep(15);
    }
    
    • 结果:

      =============>异步线程开始...
      =============>异步线程为:ForkJoinPool.commonPool-worker-9
      main结束
      =============>异步线程结束...
      =============>异步任务结束回调...
      =============>回调线程为:ForkJoinPool.commonPool-worker-9
      
  • 主线程调用了CompletableFuture#whenComplete():

    • 这个方法定义在CompletionStage接口中:

      public interface CompletionStage<T> {
          public CompletionStage<T> whenComplete
              (BiConsumer<? super T, ? super Throwable> action);
          
          // 省略其他方法...
      }
      
    • 而CompletableFuture实现了whenComplete():

      public class CompletableFuture<T> implements Future<T>, CompletionStage<T> {
          // 省略其他方法...
          
          public CompletableFuture<T> whenComplete(
              BiConsumer<? super T, ? super Throwable> action) {
              return uniWhenCompleteStage(null, action);
          }
          
          private CompletableFuture<T> uniWhenCompleteStage(Executor e, BiConsumer<? super T, ? super Throwable> f) {
              if (f == null) throw new NullPointerException();
              CompletableFuture<T> d = new CompletableFuture<T>();
              if (e != null || !d.uniWhenComplete(this, f, null)) {
                  UniWhenComplete<T> c = new UniWhenComplete<T>(e, d, this, f);
                  push(c);
                  c.tryFire(SYNC);
              }
              return d;
          }
          
          // 省略其他方法...
      }
      
    • CompletionStage是什么呢?

      • 是一个“很简单”的接口。完全独立,没有继承任何其他接口,所有方法都是它自己定义的。
      public interface CompletionStage<T> {
          // 定义了超级多类似whenComplete()的方法
      }
      
      • 是个不简单的接口。因为CompletableFuture实现Future的同时,还实现了它。Future方法就6、7个,而CompletionStage的方法超级多,所以如果你打开CompletableFuture的源码,目之所及几乎都是它对CompletionStage的实现。
      public class CompletableFuture<T> implements Future<T>, CompletionStage<T> {
          // 一些字段
          // 实现Future的方法
          
          // 实现CompletionStage的方法
          // 一些私有方法,配合CompletionStage
          // 一些内部类,配合CompletionStage
      }
      
      • 异步回调其实和CompletionStage有着很大的关系。
    • 总而言之,CompletionStage是一个接口,定义了一些方法,CompletableFuture实现了这些方法并设计出了异步回调的机制

  • 异步线程会回调BiConsumer#accept(),而CompletableFuture#whenComplete()是主线程调用的。即CompletionStage中定义的诸如whenComplete()等方法虽然和异步回调有关系,但并不是最终被回调的方法,最终被回调的其实是whenComplete(BiConsumer)传进去的BiConsumer#accept()。

    image-20210115195319241

  • 异步线程哪来的,Supplier如何被执行?

    • 跟随主线程进入CompletableFuture#supplyAsync():

      image-20210115195959491

    • 注释:返回一个新的CompletableFuture,该future是由运行在{@link ForkJoinPool#commonPool()}中的任务异步完成的,其值是通过调用给定的Supplier获得的。

      • 即异步线程来自ForkJoinPool线程池。
      • 通过CompletableFuture#supplyAsync(supplier)传入Supplier,返回CompletableFuture对象,它包含一个未来的value,且这个value会在稍后由异步线程执行Supplier#get()产生。
    • CompletableFuture#supplyAsync(supplier)内部调用了asyncSupplyStage(asyncPool, supplier),此时传入了一个线程池asyncPool,它是CompletableFuture的成员变量:

      image-20210115200409657

      image-20210115200335107

    • useCommonPool为true时会使用ForkJoinPool,而useCommonPool取决于运行当前程序的硬件是否支持多核CPU。

    • 主线程传进来的Supplier压根没有实现Runnable/Callable接口,怎么被异步线程执行呢?

      image-20210115200651552

    • 和ExecutorService#submit()一样的套路:包装成Task再执行。只不过这次被包装成了AsyncSupply,而不是FutureTask:

      image-20210115200746525

    • AsyncSupply和当初的FutureTask颇为相似,都实现了Future和Runnable,具备 任务+结果 双重属性:

      image-20210115200809769

    • 最终就是把Supplier包装好,传入线程池的execute()中运行。等线程池分配出线程,最终会执行AsyncSupply#run()。

    • AsyncSupply#run()在方法内调用f.get(),也就是Supplier#get(),阻塞获取结果并通过d.completeValue(v)把值设置到CompletableFuture中,而CompletableFuture d已经在上一步asyncSupplyStage()中被返回。最终效果和线程池+FutureTask是一样的,先返回Future实例,再通过引用把值放进去。

    image-20210115201646593

    • 从这个层面上来看,CompletableFuture相当于一个自带线程池的Future,而CompletableFuture#supplyAsync(Supplier)倒像是ExecutorService#submit(Runnable/Callable),内部也会包装任务,最终丢给Executor#execute(Task)。
    • 只不过ExecutorService是把Runnable#run()/Callable#call()包装成FutureTask,而CompletableFuture则把乱七八糟的Supplier#get()等函数式接口的方法包装成ForkJoinTask。
  • 回调机制的原理:

    • CompletableFuture的回调机制,其实本质上是对多个CompletableFuture内部函数的顺序执行,只不过发起者是异步线程而不是主线程

    • CompletableFuture#thenApply(),与CompletableFuture#whenComplete()本质是一样的(也是CompletableFuture对CompletionStage的实现):

      @RunWith(SpringRunner.class)
      @SpringBootTest
      public class CompletableFutureTest {
      
          @Test
          public void testCallBack() throws InterruptedException {
              // 任务一:把第一个任务推进去,顺便开启异步线程
              CompletableFuture<String> completableFuture1 = CompletableFuture.supplyAsync(new Supplier<String>() {
                  @Override
                  public String get() {
                      System.out.println("=============>异步线程开始...");
                      try {
                          TimeUnit.SECONDS.sleep(10);
                      } catch (InterruptedException e) {
                          e.printStackTrace();
                      }
                      System.out.println("=============>completableFuture1任务结束...");
                      System.out.println("=============>执行completableFuture1的线程为:" + Thread.currentThread().getName());
                      return "supplierResult";
                  }
              });
              System.out.println("completableFuture1:" + completableFuture1);
      
              // 任务二:把第二个任务推进去,等待异步回调
              CompletableFuture<String> completableFuture2 = completableFuture1.thenApply(new Function<String, String>() {
                  @Override
                  public String apply(String s) {
                      try {
                          TimeUnit.SECONDS.sleep(10);
                      } catch (InterruptedException e) {
                          e.printStackTrace();
                      }
                      System.out.println("=============>completableFuture2任务结束 result=" + s);
                      System.out.println("=============>执行completableFuture2的线程为:" + Thread.currentThread().getName());
                      return s;
                  }
              });
              System.out.println("completableFuture2:" + completableFuture2);
      
              // 任务三:把第三个任务推进去,等待异步回调
              CompletableFuture<String> completableFuture3 = completableFuture2.thenApply(new Function<String, String>() {
                  @Override
                  public String apply(String s) {
                      try {
                          TimeUnit.SECONDS.sleep(10);
                      } catch (InterruptedException e) {
                          e.printStackTrace();
                      }
                      System.out.println("=============>completableFuture3任务结束 result=" + s);
                      System.out.println("=============>执行completableFuture3的线程为:" + Thread.currentThread().getName());
                      return s;
                  }
              });
              System.out.println("completableFuture3:" + completableFuture3);
      
              System.out.println("主线程结束");
              TimeUnit.SECONDS.sleep(40);
          }
      }
      
    • 分析主线程的主干:

      • CompletableFuture#supplyAsync(Supplier):包装Supplier为AsyncSupply,调用executor.execute(),等待异步线程回调Supplier#get()
      • CompletableFuture#thenApply(Function)
      • CompletableFuture#thenApply(Function)
    • 主线程在执行“任务一”的CompletableFuture#supplyAsync(Supplier)时,将Supplier包装成AsyncSupply任务,并开启了异步线程,此后异步线程会阻塞在Supplier#get():

      image-20210115212049077

      image-20210115212056600

    • Supplier#get()是异步线程开启后执行的第一站!

    • 与此同时,主线程继续执行后面的“任务二”、“任务三”,并且都会到达uniApply(),且都返回false,因为a.result==null。

    • 当主线程从任务二进来,调用thenApply()。最终会到达uniApply(),通过控制台的日志,我们发现a其实就是completableFuture1。因为uniApply()的上一步传入的this:

      image-20210115212144996

    • 也就是说:

      • 主线程 ---> completableFuture1.thenApply(Function#apply) ---> !d.uniApply(this, f#apply, null)
      • a.result就是completableFuture1.result,而completableFuture1的值来自Supplier#get(),此时确实还是null(异步线程阻塞设定的秒数秒后才会)。
    • 所以此时d.uniApply(this, f, null) 为false,那么!d.uniApply(this, f, null) 为true,就会进入if语句:

      image-20210115212301773

    • 主要做了3件事:

      • 传入Executor e、新建的CompletableFuture d、当前completableFuture1、Function f,构建UniApply
      • push(uniApply)
      • uniApply.tryFire(SYNC)
    • 任务一做了两件事:

      • 开启异步线程
      • 等待回调
    • 由于要开启线程,自己也要作为任务被执行,所以Supplier#get()被包装成AsyncSupply,是一个Task。而后续的几个任务其实只做了一件事:等待回调。只要能通过实例执行方法即可,和任务一有所不同,所以只是被包装成UniApply对象。

    • push(uniApply)姑且认为是把任务二的Function#apply()包装后塞到任务栈中。

    • 但uniApply.tryFire(SYNC)是干嘛的呢?里面又调了一次uniApply():

      image-20210115212533531

    • SYNC=0,所以最终判断!d.uniApply(this, f, this) ==true,tryFire(SYNC)返回null,后面的d.postFire(a, mode)此时并不会执行,等后面异步线程复苏后,带着任务一的结果再次调用时,效果就截然不同了。

    • 总结一下,“任务二”、“任务三”操作都是一样的,都做了3件事:

      • 主线程调用CompletableFuture#thenApply(Function f)传入f,构建UniApply对象,包装Function#apply()
      • 把构建好的UniApply对象push到栈中
      • 返回CompletableFuture d

      image-20210115212633923

      image-20210115212734838

    • 等过了100秒,supplyAsync(Supplier)中的Supplier#get()返回结果后,异步线程继续往下走:

      • postComplete()也会走uniApply(),但这次已经有了异步结果result,所以流程不会被截断,最终会调用Function#apply(s),而这个s是上一个函数的执行结果
      • 也就是说,新的CompletableFuture对象调用Function#apply()处理了上一个CompletableFuture产生的结果。

      image-20210115212939769

  • CompletableFuture与FutureTask线程数对比:

    • CompletableFuture和FutureTask耗费的线程数是一致的,但对于FutureTask来说,无论是轮询还是阻塞get,都会导致主线程无法继续其他任务,又或者主线程可以继续其他任务,但要时不时check FutureTask是否已经完成任务,比较糟心。而CompletableFuture则会根据我们编排的顺序逐个回调,是按照既定路线执行的。

      image-20210115213205392

    • 其实无论是哪种方式,异步线程其实都需要阻塞等待结果,期间不能处理其他任务。但对于FutureTask而言,在异步线程注定无法复用的前提下,如果想要获取最终结果,需要主线程主动查询或者额外开启一个线程查询,并且可能造成阻塞,而CompletableFuture的异步任务执行、任务结果获取都是异步线程独立完成。

    • 即,1个异步线程阻塞执行任务 + 回调异步结果 > 1个异步线程阻塞执行任务 + 1个线程阻塞查询任务。


posted @ 2021-01-16 11:13  iwehdio  阅读(3619)  评论(1编辑  收藏  举报