受Heinz Kabutz最近的时事通讯以及我在最近的书中研究的Scala的期货的启发，我着手使用Java 8编写了一个示例，该示例如何将工作提交给执行服务并异步地响应其结果，并使用了回调。无需阻止任何线程等待执行服务的结果。

理论认为，调用拦截方法，如get上java.util.concurrent.Future是坏的，因为系统会需要超过线程的最佳数量，如果它是不断做工作，并在浪费时间与结果上下文切换 。

在Scala世界中，像Akka这样的框架都使用编程模型，这意味着这些框架永远不会阻塞-线程阻塞的唯一时间是用户对阻塞的对象进行编程时，他们不愿意这样做。 通过永不阻塞，该框架可以避免每个内核使用大约一个线程，这比说说标准JBoss Java EE Application Server（在启动后最多拥有400个线程）要少得多。 很大程度上归功于Akka框架的工作，Scala 2.10添加了Futures和Promises ，但是Java中还不存在这些东西。

以下代码显示了我的预期目标。 它分为三个部分。 首先，使用在类ch.maxant.async.Future找到的static future方法将新任务添加到执行服务中。 它返回一个Future ，但不是从java.util.concurrent包中返回一个Future ，而是从ch.maxant.async包中返回其子类。 其次， Future具有一种名为map的方法，该方法遵循Scala或新的Java 8 Stream类的功能样式。 map方法允许您注册一个回调，或更准确地说，我们可以将第一个future包含的值映射（转换）为新值。 在第一个Future完成后，映射将在将来的其他时间执行，因此会产生新的Future 。 第三，我们在Future类中使用另一个方法来注册一个回调，一旦我们创建的所有期货都完成，该回调将运行。 任何时候都不会使用Future API的任何阻塞方法！

final Random random = new Random();
int numTasks = 10;
List<Future<Integer>> futures = new ArrayList<>();for(int i = 0; i < numTasks; i++){final int j = i;log("adding future " + i);// PART 1//start some work async / in the futureFuture<String> f = future(new Task<String>( () -> {sleep(random.nextInt(1000));if(j < 5){log("working success");return "20";}else{log("working failure");throw new Exception();}}));// PART 2//register a callback, to be called when the work is donelog("adding mapping callback to future");final Future<Integer> f2 = f.map( (Try<String> stringNumber) -> {return stringNumber.map( (String s) -> {log("mapping '" + s + "' to int");return Integer.parseInt(s);}).recover( (Exception e) -> {log("recovering");return -10;}).get(); //wont throw an exception, because we provided a recovery!});futures.add(f2);
}// PART 3
log("registering callback for final result");
Future.registerCallback(futures, (List<Try<Integer>> results) -> {Integer finalResult = results.stream().map( (Try<Integer> t) -> {log("mapping " + t);try {return t.get();} catch (Exception e) {return 0;}}).reduce(0, (Integer i1, Integer i2) -> {log("reducing " + i1 + " and " + i2);return i1 + i2;});log("final result is " + finalResult);Future.shutdown();if(finalResult != 50){throw new RuntimeException("FAILED");}else{log("SUCESS");}
});System.out.println("Completed submitting all tasks on thread " + Thread.currentThread().getId());//this main thread will now die, but the Future executor is still up and running.  the callback will shut it down and with it, the jvm.

第11行调用了future方法来注册一个新Task ，该Task是使用Work实例构造的，在这里是使用Java 8 lambda构造的。 工作会睡一会儿，然后要么返回数字20（作为字符串），要么抛出异常，以演示如何处理错误。

使用第11行从执行服务返回的Future ，第25行将其值从字符串映射到整数，从而生成Future<Integer>而不是Future<String> 。 该结果将添加到第35行的Future列表中，第3部分在第40行中使用该列表registerCallback方法将确保在完成最后一个future之后调用给定的回调。

第25-33行的映射使用传递给Try对象的lambda完成。 Try有点像Java 8 Optional ，它是Success和Failure类的抽象（超类），我是根据对Scala对应类的了解而实现的。 与必须显式检查错误相比，它可使程序员更轻松地处理故障。 我对Try接口的实现如下：

public interface Try<T> {/** returns the value, or throws an exception if its a failure. */T get() throws Exception;/** converts the value using the given function, resulting in a new Try */<S> Try<S> map(Function1<T, S> func);/** can be used to handle recovery by converting the exception into a {@link Try} */Try<T> recover(Recovery<T> r);}

发生的事情是Success和Failure的实现可以优雅地处理错误。 例如，如果第一个清单的第11行上的Future完成但有例外，则将第一个清单的第25行上的lambda传递给Failure对象，并且在Failure上调用map方法绝对没有任何作用。 没有例外，没有任何问题。 为了进行补偿，您可以在第一个清单的第29行上调用recover方法，该方法使您可以处理异常并返回程序可以继续使用的值，例如默认值。

另一方面， Success类以不同的方式实现Try接口的map和recover方法，这样，调用map会导致给定的函数被调用，但是调用recover绝对不会执行任何操作。 map和recover方法无需显式编码try / catch块，而是提供了一种更好的语法，该语法在读取或查看代码时更容易验证（与编写相比，这种情况在代码中更常见）。

由于map和recover方法将函数的结果包装在Try s中，因此可以将调用链接在一起，例如第Try和32行。Scala的Try API具有比我在这里实现的三种方法更多的方法。 请注意，我选择在Try API java.util.function.Function不使用java.util.function.Function ，因为它的apply方法不会throw Exception ，这意味着第一个清单中显示的代码不像现在那样好。 相反，我写了
Function1接口。

难题的第3部分是如何使程序在所有Future完成之后做一些有用的事情，而又不会像对Future#get()方法那样讨厌调用。 解决方案是注册一个回调，如第40行所示。该回调与此处显示的所有其他回调一样，都已提交给执行服务。 这意味着我们无法保证哪个线程可以运行它，这会带来副作用，即线程本地存储（TLS）不再起作用-某些框架（（的较旧版本？）Hibernate依赖TLS，而它们只会胜任）。在这里工作。 Scala有一个很好的方法可以使用implicit关键字来解决该问题，而Java还没有（但…？），因此需要使用其他机制。 我在提到它，只是为了让您知道它。

因此，当最后一个Future完成时，将调用40-60行，并传递包含Integer而不是Future的Try的List 。 registerCallback方法将期货转换为适当的Success或Failure 。 但是我们如何将它们转换为有用的东西呢？ 幸运的是，Java 8现在有了一个简单的map / reduce，就支持了Stream类，该类通过调用stream()方法从第42行的Try集合中Try了。 首先，我将Try映射（转换）为它们的值，然后在第49行上将流减少为单个值。我本可以使用而不是传递自己的求和值的lambda实现。
Integer::sum ，例如someStream.reduce(0, Integer::sum) 。

我上次运行该程序时，它输出以下内容：

Thread-1 says: adding future 0
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 1
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 2
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 3
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 4
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 5
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 6
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 7
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 8
Thread-1 says: adding mapping callback to future
Thread-1 says: adding future 9
Thread-1 says: adding mapping callback to future
Thread-1 says: registering callback for final result
Thread-10 says: working success
Completed submitting all tasks on thread 1
Thread-14 says: working success
Thread-10 says: working failure
Thread-14 says: working failure
Thread-12 says: working success
Thread-10 says: working failure
Thread-10 says: mapping '20' to int
Thread-10 says: mapping '20' to int
Thread-10 says: recovering
Thread-10 says: recovering
Thread-10 says: mapping '20' to int
Thread-10 says: recovering
Thread-11 says: working success
Thread-11 says: mapping '20' to int
Thread-13 says: working success
Thread-10 says: mapping '20' to int
Thread-12 says: working failure
Thread-12 says: recovering
Thread-14 says: working failure
Thread-14 says: recovering
Thread-14 says: mapping Success(20)
Thread-14 says: mapping Success(20)
Thread-14 says: mapping Success(20)
Thread-14 says: mapping Success(20)
Thread-14 says: mapping Success(20)
Thread-14 says: mapping Success(-10)
Thread-14 says: mapping Success(-10)
Thread-14 says: mapping Success(-10)
Thread-14 says: mapping Success(-10)
Thread-14 says: mapping Success(-10)
Thread-14 says: final result is 50
Thread-14 says: SUCESS

如您所见，主线程添加了所有任务并注册了所有映射功能（第1-20行）。 然后，它注册回调（输出的第21行，与清单的第39行相对应），最后从清单中的第63行输出文本，此后它死了，因为它无事可做。 然后，输出的第22行和第24-42行显示了池中的各个线程（包含5个线程），这些线程处理工作以及从String到Integer的映射或从异常中恢复。 这是第一个清单的第1部分和第2部分中的代码。 您可以看到它是完全异步的，在所有初始工作完成之前会发生一些映射/恢复（将第38行或第40行分别映射到输出的第41行，并将其映射到输出的第41行，此行是最后的输出）最初的工作）。 第43-52行是map / reduce的输出，它是主列表的第3部分。 请注意，没有记录reduce，因为我运行的代码（位于Github上）使用上面提到的Integer::sum快捷方式，而不是上面显示的第一个清单的第50-51行。

尽管使用Java 6（甚至5？）可以实现所有这些功能，例如，通过获取提交到池中的任务来自己提交回调，但是一旦完成，执行该操作所需的代码量就会更大，并且代码本身将比此处显示的代码丑陋。 可以使用回调进行映射的Java 8 lambda， Future以及具有简洁错误处理功能的Try API都可以使此处所示的解决方案更具可维护性。

上面显示的代码以及ch.maxant.async包中类的代码在Apache License Version 2.0下可用，并且可以从我的Github帐户下载。

翻译自: https://www.javacodegeeks.com/2013/10/non-blocking-asynchronous-java-8-and-scalas-trysuccessfailure.html