记CompletableFuture: 异步编程的一次生产优化

 

近期生产上报错

java.util.concurrent.TimeoutException：null
java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1771)

经过排查得出结论是由于使用异步编排获取异步执行结果时，异步任务还没有完全执行完成导致的，可为什么之前一直没问题，上线很久后才出现问题呢？其实导致这次报错的表面原因大致有两个：

• 由于业务的扩张，系统的提交量变大
• 高峰期异步操作中调用的远程接口处理时间过长 

而这两者是随着系统的访问量提升无法避免的问题，后来仔细看了一下整个系统中异步调用的代码，发现了一个致命的问题，也可以说是产生这个生产报错的根本原因，那就是在这个独立的系统中几乎所有的异步调用都是通过runAsync(Runnable runnable)方法来实现的，而在默认情况下 CompletableFuture 会使用公共的 ForkJoinPool 线程池，这个线程池默认创建的线程数是 CPU 的核数（也可以通过 JVM option:-Djava.util.concurrent.ForkJoinPool.common.parallelism 来设置 ForkJoinPool 线程池的线程数）。如果所有 CompletableFuture 共享一个线程池，那么一旦有任务执行一些很慢的 I/O 操作或者在等待远程接口时进行了阻塞，就会导致线程池中本就为数不多的默认线程数都阻塞在 I/O 操作或远程调用等待结果上，下次再有请求过来就会进入线程池队列进行等待，从而造成线程饥饿，进而影响整个系统的性能。