对《Java 8实战》的笔记(2)

  同步API与异步API
同步API其实只是对传统方法调用的另一种称呼：你调用了某个方法，调用方在被调用方
运行的过程中会等待，被调用方运行结束返回，调用方取得被调用方的返回值并继续运行。即
使调用方和被调用方在不同的线程中运行，调用方还是需要等待被调用方结束运行，这就是阻
塞式调用这个名词的由来。
与此相反， 异步API会直接返回，或者至少在被调用方计算完成之前，将它剩余的计算任
务交给另一个线程去做，该线程和调用方是异步的——这就是非阻塞式调用的由来。执行剩余
计算任务的线程会将它的计算结果返回给调用方。返回的方式要么是通过回调函数，要么是由
调用方再次执行一个“等待，直到计算完成”的方法调用。这种方式的计算在I/O系统程序设
计中非常常见：你发起了一次磁盘访问，这次访问和你的其他计算操作是异步的，你完成其他
的任务时，磁盘块的数据可能还没载入到内存，你只需要等待数据的载入完成。
  

2018-10-02 01:53:05 回应

  并行——使用流还是CompletableFutures？
目前为止，你已经知道对集合进行并行计算有两种方式：要么将其转化为并行流，利用map
这样的操作开展工作，要么枚举出集合中的每一个元素，创建新的线程，在CompletableFuture内对其进行操作。后者提供了更多的灵活性，你可以调整线程池的大小，而这能帮助
你确保整体的计算不会因为线程都在等待I/O而发生阻塞。
我们对使用这些API的建议如下。
❑如果你进行的是计算密集型的操作，并且没有I/O，那么推荐使用Stream接口，因为实
现简单，同时效率也可能是最高的（如果所有的线程都是计算密集型的，那就没有必要
创建比处理器核数更多的线程）。
❑反之，如果你并行的工作单元还涉及等待I/O的操作（包括网络连接等待），那么使用
CompletableFuture灵活性更好，你可以像前文讨论的那样，依据等待/计算，或者
W/C的比率设定需要使用的线程数。这种情况不使用并行流的另一个原因是，处理流的
流水线中如果发生I/O等待，流的延迟特性会让我们很难判断到底什么时候触发了等待。
  

2018-10-02 02:10:04 回应