Mastering Asynchronous Java: From Threads to CompletableFuture

Asynchronous and Non-Blocking

What is Asynchronous?

Asynchronous execution

Not executed in a synchronous order

What is Non-Blocking?

Does not block

Does not cause thread blockage

Why need async?

Time‑consuming business methods

Network overhead

Encryption/decryption operations

File upload/download

…

Drawbacks of synchronous execution

Web services lose throughput when a thread is occupied for too long

Desktop or mobile apps may freeze while waiting for a request

Traditional blocking example

// 10 seconds
Image img1 = download();
render(img1);
// 12 seconds
Image img2 = download();
render(img2);

These business‑level codes are time‑consuming and hard to control.

Pre‑Java 8 approach

java.lang.Thread

JDK 1.0

Consumer‑based implementation (Java 8)

void downloadAsync(String url, Consumer<Image> c) {
  new Thread(() -> {
    Image result = download(url);
    c.accept(result);
  }).start();
}

Problems with raw Thread usage

Often requires synchronized, wait, notify, join

Sharing data between threads is difficult

Hard to manage and compose business methods

Dependency handling example

fetchDataAsync(data -> {
  downloadAsync(data, image -> render(image));
});

This works but leads to callback hell.

Alternative thread‑wrapping approach

new Thread(() -> {
  final Data result = fetchData();
  Image img = download(result.imageURL);
  Bitmap bitmap = decode(img);
}).start();

Wrapping several operations in a single large thread is still inelegant.

Java 1.5+ Future

java.util.concurrent.Future

Available since Java 5

ExecutorService service = Executors.newCachedThreadPool();
Future<Image> f = service.submit(() -> downloadImage(xxx));
// do other work
// f.get() obtains result

Future exception handling:

try {
  renderImage(future.get());
} catch (Exception e) {
  e.printCause(); // print execution error
}

Other useful methods: cancel, isCancelled, isDone.

Drawbacks: callback‑style API, only five methods, blocking get(), hard to compose.

Java 8 CompletableFuture

java.util.concurrent.CompletableFuture

Implements Future and CompletionStage

CompletableFuture<String> cf = CompletableFuture.completedFuture("Value");
String result = cf.get(); // blocking
String result2 = cf.join(); // non‑blocking
cf.thenAccept(s -> System.out.println(s));

Chaining examples:

CompletableFuture<?> cf1 = findUser(1L).thenApply(user -> download(user));
CompletableFuture<File> cf2 = findUser(1L).thenCompose(user -> download(user));

Further composition:

CompletableFuture<File> cf = findUser(1L)
    .thenCompose(user -> download(user))
    .thenCompose(img -> save(img));

Handling exceptions:

findUser(1L)
    .thenApply(...)
    .thenApply(...)
    .thenCompose(...)
    .whenComplete((s, t) -> {
      if (s != null) System.out.println(s);
      else System.err.println(t);
    });

CompletableFuture.allOf

CompletableFuture<String> api1 = ...;
CompletableFuture<String> api2 = ...;
CompletableFuture<String> api3 = ...;
CompletableFuture<Void> all = CompletableFuture.allOf(api1, api2, api3);
CompletableFuture<List<String>> result = all.thenApply(v ->
    Arrays.asList(api1.get(), api2.get(), api3.get()));

CompletableFuture.anyOf

CompletableFuture<Object> any = CompletableFuture.anyOf(api1, api2, api3);

Common API patterns

CompletableFuture<User> findUser(String id);
CompletableFuture<User> saveUser(String id);
CompletableFuture<User> downloadAvatar(String id);
findUser(...)
    .thenCompose(user -> saveUser(user.id))
    .thenCompose(user -> downloadAvatar(user.id))
    .thenAccept(img -> render(img));

Pros of CompletableFuture

Event‑driven

Easy to compose

Control can be handed to the caller

Reduces thread waste

Cons of CompletableFuture

Mixes Future and Promise concepts, unlike many languages

Large number of methods (60+)

Notes

cancel cannot stop a running task

Prefer APIs ending with Async

Web frameworks supporting async

Servlet 3.x+ AsyncContext

Spring MVC controllers returning CompletableFuture

Play Framework

Other asynchronous web frameworks

play.libs.F.Promise

Considerations for web applications

Should HTTP handling threads perform work?

Tomcat max‑threads setting

Play separates HTTP and workers

Work duration varies

Resource limits for long‑running tasks

Synchronous vs asynchronous benchmark

Job: 1500 ms ≈ 30 %, 100 ms ≈ 70 %

Tomcat max‑threads 200

ab -n 1000 -c 400

Async ≈ 375 requests/second

Sync ≈ 300 requests/second – if methods are fast, sync may be better

Reactive programming

Data‑flow model

Java 9 Flow API support