俯瞰Java并发框架
译者：Emma
了解更多Java流行并发框架的相关信息 - RxJava，Akka，Disruptor和ExecutorService。
为什么？
几年前，当NoSQL像其他所有术语一样成为趋势时，我们的团队也热衷于新的和令人兴奋的事情;我们计划在其中一个应用程序中更改数据库。但是当我们深入了解实现的细节时，突然记得一位智者曾经说过的“细节决定成败”，最终，我们意识到NoSQL并不是解决所有问题的灵丹妙药，而且NoSQL VS RDMS的答案是：“视情况而定。”同样，在去年，像RxJava和Spring Reactor这样的并发库正在热情洋溢地发表声明，比如异步，使用非阻塞方法等等。为了不再犯同样的错误，我们试图测评ExecutorService，RxJava，Disruptor和Akka并发框架之间的差异性，以及如何为各个框架确定正确的用例。
本文中使用的术语在这里有更详细的描述。
并发框架的分析用例
快速刷新线程配置
在进行并发框架的比较之前，让我们快速回顾一下如何配置最佳线程数以提高并行任务的性能。该理论适用于所有框架，并且在所有框架中使用相同的线程配置来测量性能。
-
对于内存中任务，线程数大约等于具有最佳性能的内核数，尽管它可以根据相应处理器中的超线程功能进行一些更改。
- 例如，在8核机器中，如果应用程序的每个请求必须并行执行四个内存任务，则应该在ThreadPool中使用8个线程来维持机器上的负载为@ 2 req / sec。
-
对于I / O任务，ExecutorService中配置的线程数应基于外部服务的延迟。
- 与内存中任务不同，涉及I / O任务中线程将被阻塞，并且它将处于等待状态，直到外部服务响应或超时。因此，当涉及I / O任务时，由于线程被阻塞，应增加线程数以处理并发请求的额外负载。
- 应该以保守的方式增加I / O任务的线程数，因为许多处于活动状态的线程会带来上下文切换的成本，这将影响应用程序性能。为避免这种情况，应该按照涉及I / O任务和等待时间的线程的成比例地增加该机器的确切线程数和负载数。
参考: baddotrobot.com/blog/2013/0…
表现结果
性能测试在GCP中运行 - >处理器型号名称：Intel（R）Xeon（R）CPU @ 2.30GHz;架构：x86_64;核心线程数：8（注意：用例中的结果是主观的，单并不意味着一个框架比另一个框架更好）。
| 描述 | 请求数 | I / O任务的线程池大小 | 以ms为单位的平均延迟（50 req / sec） |
|---|---|---|---|
| 所有操作都按顺序排列 | ~10000 | NA | ~2100 |
| 使用Executor Service并行化IO任务，并使用HTTP线程处理内存任务 | ~10000 | 16 | ~1800 |
| 使用Executor Service并行化IO任务（Completable Future）并使用HTTP线程处理内存任务 | ~10000 | 16 | ~1800 |
| 使用ExecutorService并行化所有任务并使用@Suspended AsyncResponse以非阻塞方式发送响应 | ~10000 | 16 | ~3500 |
| 使用Rx-Java执行所有任务并使用@Suspended AsyncResponse以非阻塞方式发送响应 | ~10000 | NA | ~2300 |
| 使用Disruptor框架并行化所有任务（Http线程阻塞） | ~10000 | 11 | ~3000 |
| 使用Disruptor框架并行化所有任务并使用@Suspended AsyncResponse以非阻塞方式发送响应 | ~10000 | 12 | ~3500 |
| 使用Akka框架并行化所有任务（Http线程阻塞） | ~10000 | ~3000 |
使用Executor Service并行化IO任务
何时使用？
如果应用程序部署在多个节点中，并且如果每个节点中的req/sec小于可用核心数，则ExecutorService可用于并行化任务并更快地执行代码。
何时不使用？
如果应用程序部署在多个节点中，并且每个节点中的req/sec远远高于可用的核心数，那么使用ExecutorService进一步并行化只会使事情变得更糟。
当外部服务的延迟增加到400毫秒时，性能结果（8核机器的请求率@ 50 req/sec）。
| 描述 | 请求数 | I/O任务的线程池大小 | 以ms为单位的平均延迟（50 req/sec） |
|---|---|---|---|
| 所有操作都按顺序排列 | ~3000 | NA | ~2600 |
| 使用Executor Service并行化IO任务，并使用HTTP线程处理内存任务 | ~3000 | 24 | ~3000 |
示例按顺序执行所有任务时：
// I/O tasks : invoke external services
String posts = JsonService.getPosts();
String comments = JsonService.getComments();
String albums = JsonService.getAlbums();
String photos = JsonService.getPhotos();
// merge the response from external service
// (in-memory tasks will be performed as part this operation)
int userId = new Random().nextInt(10) + 1;
String postsAndCommentsOfRandomUser = ResponseUtil.getPostsAndCommentsOfRandomUser(userId, posts, comments);
String albumsAndPhotosOfRandomUser = ResponseUtil.getAlbumsAndPhotosOfRandomUser(userId, albums, photos);
// build the final response to send it back to client
String response = postsAndCommentsOfRandomUser + albumsAndPhotosOfRandomUser;
return response;
ExecutorService并行执行I/O任务的示例代码
这类似于上述情况：HTTP线程阻塞处理传入请求，CompletableFuture用于处理并行任务
何时使用？
没有AsyncResponse，性能与ExecutorService相同。如果多个API调用必须是异步的，并且必须进行链接，则这种方法更好（类似于Node中的Promises）。
// add I/O Tasks
List<Callable<String>> ioCallableTasks = new ArrayList<>();
ioCallableTasks.add(JsonService::getPosts);
ioCallableTasks.add(JsonService::getComments);
ioCallableTasks.add(JsonService::getAlbums);
ioCallableTasks.add(JsonService::getPhotos);
// Invoke all parallel tasks
ExecutorService ioExecutorService = CustomThreads.getExecutorService(ioPoolSize);
List<Future<String>> futuresOfIOTasks = ioExecutorService.invokeAll(ioCallableTasks);
// get results of I/O operation (blocking call)
String posts = futuresOfIOTasks.get(0).get();
String comments = futuresOfIOTasks.get(1).get();
String albums = futuresOfIOTasks.get(2).get();
String photos = futuresOfIOTasks.get(3).get();
// merge the response (in-memory tasks will be part of this operation)
String postsAndCommentsOfRandomUser = ResponseUtil.getPostsAndCommentsOfRandomUser(userId, posts, comments);
String albumsAndPhotosOfRandomUser = ResponseUtil.getAlbumsAndPhotosOfRandomUser(userId, albums, photos);
//build the final response to send it back to client
return postsAndCommentsOfRandomUser + albumsAndPhotosOfRandomUser;
使用Executor服务并行化IO任务（CompletableFuture）
ExecutorService ioExecutorService = CustomThreads.getExecutorService(ioPoolSize);
// I/O tasks
CompletableFuture<String> postsFuture = CompletableFuture.supplyAsync(JsonService::getPosts, ioExecutorService);
CompletableFuture<String> commentsFuture = CompletableFuture.supplyAsync(JsonService::getComments,
ioExecutorService);
CompletableFuture<String> albumsFuture = CompletableFuture.supplyAsync(JsonService::getAlbums,
ioExecutorService);
CompletableFuture<String> photosFuture = CompletableFuture.supplyAsync(JsonService::getPhotos,
ioExecutorService);
CompletableFuture.allOf(postsFuture, commentsFuture, albumsFuture, photosFuture).get();
// get response from I/O tasks (blocking call)
String posts = postsFuture.get();
String comments = commentsFuture.get();
String albums = albumsFuture.get();
String photos = photosFuture.get();
// merge response (in-memory tasks will be part of this operation)
String postsAndCommentsOfRandomUser = ResponseUtil.getPostsAndCommentsOfRandomUser(userId, posts, comments);
String albumsAndPhotosOfRandomUser = ResponseUtil.getAlbumsAndPhotosOfRandomUser(userId, albums, photos);
// Build final response to send it back to client
return postsAndCommentsOfRandomUser + albumsAndPhotosOfRandomUser;
ExecutorService 并行化任务
使用ExecutorService并行化所有任务，并使用@Suspended AsyncResponse响应方式是以非阻塞方式发送响应。
[io vs nio]
图片来自：ttp://tutorials.jenkov.com/java-nio/nio-vs-io.html
- 传入请求将通过事件池处理，请求将传递到Executor池进行进一步处理，当所有任务完成后，来自事件池的另一个HTTP线程将响应发送回客户端。 （异步和非阻塞）。
- 性能下降的原因：
- 在同步通信中，尽管涉及I / O任务中的线程被阻塞，但只要有额外的线程来处理并发请求的加载，该进程仍将处于运行状态。
- 因此，以非阻塞方式保持线程所带来的好处非常少，并且以这种模式处理请求所涉及的成本似乎很高。
- 通常，对于本文中讨论的用例使用异步非阻塞方式会降低应用程序性能。
何时使用？
如果用例类似于服务器端聊天应用程序，其中线程无需保持连接直到客户端响应，这种情况下异步，非阻塞方式优于同步通信;在这些用例中，系统资源可以通过异步，非阻塞方式被更好地利用，而不仅仅是等待。
// submit parallel tasks for Async execution
ExecutorService ioExecutorService = CustomThreads.getExecutorService(ioPoolSize);
CompletableFuture<String> postsFuture = CompletableFuture.supplyAsync(JsonService::getPosts, ioExecutorService);
CompletableFuture<String> commentsFuture = CompletableFuture.supplyAsync(JsonService::getComments,
ioExecutorService);
CompletableFuture<String> albumsFuture = CompletableFuture.supplyAsync(JsonService::getAlbums,
ioExecutorService);
CompletableFuture<String> photosFuture = CompletableFuture.supplyAsync(JsonService::getPhotos,
ioExecutorService);
// When /posts API returns a response, it will be combined with the response from /comments API
// and as part of this operation, some in-memory tasks will be performed
CompletableFuture<String> postsAndCommentsFuture = postsFuture.thenCombineAsync(commentsFuture,
(posts, comments) -> ResponseUtil.getPostsAndCommentsOfRandomUser(userId, posts, comments),
ioExecutorService);
// When /albums API returns a response, it will be combined with the response from /photos API
// and as part of this operation, some in-memory tasks will be performed
CompletableFuture<String> albumsAndPhotosFuture = albumsFuture.thenCombineAsync(photosFuture,
(albums, photos) -> ResponseUtil.getAlbumsAndPhotosOfRandomUser(userId, albums, photos),
ioExecutorService);
// Build the final response and resume the http-connection to send the response back to client.
postsAndCommentsFuture.thenAcceptBothAsync(albumsAndPhotosFuture, (s1, s2) -> {
LOG.info("Building Async Response in Thread " + Thread.currentThread().getName());
String response = s1 + s2;
asyncHttpResponse.resume(response);
}, ioExecutorService);
RxJava/RxNetty
- RxJava / RxNetty组合的主要区别在于，它可以通过使I / O任务以非阻塞方式来处理带有事件池的传入和传出请求。
- 此外，RxJava提供了更好的DSL以流畅的方式编写代码，这个例子可能看不到。
- 性能优于使用CompletableFuture处理并行任务
何时使用
如果异步，非阻塞方法适合用例，则可以优选RxJava或任何反应库。它具有额外的功能，如背压，可以平衡生产者和消费者之间的负荷。
// non blocking API call from Application - getPosts()
HttpClientRequest<ByteBuf, ByteBuf> request = HttpClient.newClient(MOCKY_IO_SERVICE, 80)
.createGet(POSTS_API).addHeader("content-type", "application/json; charset=utf-8");
rx.Observable<String> rx1ObservableResponse = request.flatMap(HttpClientResponse::getContent)
.map(buf -> getBytesFromResponse(buf))
.reduce(new byte[0], (acc, bytes) -> reduceAndAccumulateBytes(acc, bytes))
.map(bytes -> getStringResponse(bytes, "getPosts", startTime));
int userId = new Random().nextInt(10) + 1;
// Submit parallel I/O tasks for each incoming request.
Observable<String> postsObservable = Observable.just(userId).flatMap(o -> NonBlockingJsonService.getPosts());
Observable<String> commentsObservable = Observable.just(userId)
.flatMap(o -> NonBlockingJsonService.getComments());
Observable<String> albumsObservable = Observable.just(userId).flatMap(o -> NonBlockingJsonService.getAlbums());
Observable<String> photosObservable = Observable.just(userId).flatMap(o -> NonBlockingJsonService.getPhotos());
// When /posts API returns a response, it will be combined with the response from /comments API
// and as part of this operation, some in-memory tasks will be performed
Observable<String> postsAndCommentsObservable = Observable.zip(postsObservable, commentsObservable,
(posts, comments) -> ResponseUtil.getPostsAndCommentsOfRandomUser(userId, posts, comments));
// When /albums API returns a response, it will be combined with the response from /photos API
// and as part of this operation, some in-memory tasks will be performed
Observable<String> albumsAndPhotosObservable = Observable.zip(albumsObservable, photosObservable,
(albums, photos) -> ResponseUtil.getAlbumsAndPhotosOfRandomUser(userId, albums, photos));
// build final response
Observable.zip(postsAndCommentsObservable, albumsAndPhotosObservable, (r1, r2) -> r1 + r2)
.subscribe((response) -> asyncResponse.resume(response), e -> {
LOG.error("Error", e);
asyncResponse.resume("Error");
});
Disruptor
图1: tutorials.jenkov.com/java-concur…
图2: www.baeldung.com/lmax-disrup…
- 在此示例中，HTTP线程将被阻塞，直到disruptor完成任务并且已使用CountDownLatch将HTTP线程与ExecutorService中的线程同步。
- 该框架的主要特点是在没有任何锁的情况下处理线程间通信;在ExecutorService中，生产者和消费者之间的数据将通过队列传递，并且在生产者和消费者之间的数据传输过程中涉及锁定。 Disruptor框架在称为Ring Buffer的数据结构的帮助下处理此Producer-Consumer通信而没有任何Lock，这是一个循环阵列队列的扩展版本。
- 该库不适用于我们在此讨论的用例。它只是出于好奇而加入。
何时使用
当与事件驱动的体系结构模式一起使用时，以及当有一个生产者和多个消费者时，更侧重于关注内存中的任务，Disruptor框架的表现更好。
static {
int userId = new Random().nextInt(10) + 1;
// Sample Event-Handler; count down latch is used to synchronize the thread with http-thread
EventHandler<Event> postsApiHandler = (event, sequence, endOfBatch) -> {
event.posts = JsonService.getPosts();
event.countDownLatch.countDown();
};
// Disruptor set-up to handle events
DISRUPTOR.handleEventsWith(postsApiHandler, commentsApiHandler, albumsApiHandler)
.handleEventsWithWorkerPool(photosApiHandler1, photosApiHandler2)
.thenHandleEventsWithWorkerPool(postsAndCommentsResponseHandler1, postsAndCommentsResponseHandler2)
.handleEventsWithWorkerPool(albumsAndPhotosResponseHandler1, albumsAndPhotosResponseHandler2);
DISRUPTOR.start();
}
// for each request, publish an event in RingBuffer:
Event event = null;
RingBuffer<Event> ringBuffer = DISRUPTOR.getRingBuffer();
long sequence = ringBuffer.next();
CountDownLatch countDownLatch = new CountDownLatch(6);
try {
event = ringBuffer.get(sequence);
event.countDownLatch = countDownLatch;
event.startTime = System.currentTimeMillis();
} finally {
ringBuffer.publish(sequence);
}
try {
event.countDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
Akka
图片来自：blog.codecentric.de/en/2015/08/…
- Akka库的主要优点是它支持构建分布式系统。
- 它在一个名为Actor System的系统上运行，它抽象出Threads的概念，Actor系统中的Actors通过异步消息进行通信，这类似于Producer和Consumer之间的通信。
- 这种额外的抽象级别有助于Actor系统提供Fault Tolerance，Location Transparency等功能。
- 使用正确的Actor-to-Thread策略，可以优化此框架，使其性能优于上表中显示的结果。虽然它无法与单个节点上的传统方法的性能相匹配，但仍然可以优先考虑其构建分布式和弹性系统的能力。
示例代码
// from controller :
Actors.masterActor.tell(new Master.Request("Get Response", event, Actors.workerActor), ActorRef.noSender());
// handler :
public Receive createReceive() {
return receiveBuilder().match(Request.class, request -> {
Event event = request.event; // Ideally, immutable data structures should be used here.
request.worker.tell(new JsonServiceWorker.Request("posts", event), getSelf());
request.worker.tell(new JsonServiceWorker.Request("comments", event), getSelf());
request.worker.tell(new JsonServiceWorker.Request("albums", event), getSelf());
request.worker.tell(new JsonServiceWorker.Request("photos", event), getSelf());
}).match(Event.class, e -> {
if (e.posts != null && e.comments != null & e.albums != null & e.photos != null) {
int userId = new Random().nextInt(10) + 1;
String postsAndCommentsOfRandomUser = ResponseUtil.getPostsAndCommentsOfRandomUser(userId, e.posts,
e.comments);
String albumsAndPhotosOfRandomUser = ResponseUtil.getAlbumsAndPhotosOfRandomUser(userId, e.albums,
e.photos);
String response = postsAndCommentsOfRandomUser + albumsAndPhotosOfRandomUser;
e.response = response;
e.countDownLatch.countDown();
}
}).build();
}
特例 - 当线程之间的共享内存超过~8MB时 - 在本例中进一步讨论。
总结
- 根据计算机的负载确定Executor框架的配置，并检查是否可以根据应用程序中的并行任务数进行负载平衡。如果正确完成I / O任务的最佳线程数计算，那么这种方法通常会成为性能结果的赢家。
- 使用反应式或任何异步库会降低大多数传统应用程序的性能。仅当用例类似于服务器端聊天应用程序时，此模式才有用，其中线程在客户端响应之前不需要保留连接。
- 当与事件驱动的架构模式一起使用时，Disruptor框架的性能很好;但是当Disruptor模式与传统架构混合在一起时，对于我们在这里讨论过的用例，它并没有达到标准。值得注意的是，Akka和Disruptor库在使用事件驱动的架构模式时应该有单独介绍。
文章的源代码可以在GitHub上找到。
