Backend Development 24 min read

Optimizing High‑Concurrency Java Applications with WebFlux and Quasar: Reactive Programming and Fibers

This article examines the performance challenges of high‑concurrency Java services and demonstrates how applying reactive programming with Spring WebFlux and lightweight fibers via Quasar can dramatically reduce thread and memory overhead, improve throughput, and simplify asynchronous code.

Beike Product & Technology
Beike Product & Technology
Beike Product & Technology
Optimizing High‑Concurrency Java Applications with WebFlux and Quasar: Reactive Programming and Fibers

The author, a senior engineer at Beike AI Center, introduces the limits of traditional multithreaded Java servers in high‑concurrency scenarios, where increasing thread counts leads to higher memory usage and costly CPU context switches.

To address these issues, the article proposes using reactive programming with Spring WebFlux and the Quasar fiber library. It explains the principles of reactive streams, the difference between imperative and declarative programming, and why event‑driven, non‑blocking architectures improve CPU utilization.

Key concepts such as Mono, Flux, back‑pressure, and the event‑loop model are described, followed by concrete code comparisons. The traditional callback‑heavy approach is shown, then rewritten using Reactor operators to achieve concise, non‑blocking pipelines.

userService.getFavorites(userId, new Callback >() { ... })

is replaced by the reactive version:

userService.getFavorites(userId) .flatMap(favoriteService::getDetails) .switchIfEmpty(suggestionService.getSuggestions()) .take(5) .publishOn(UiUtils.uiThreadScheduler()) .subscribe(uiList::show, UiUtils::errorPopup);

The article also covers WebClient configuration for non‑blocking HTTP calls, Maven/Gradle dependencies for WebFlux and Quasar, and the required JavaAgent instrumentation.

Quasar’s fiber model is explained, including stackful vs. stackless implementations, the use of SuspendExecution , and how fibers dramatically reduce per‑task memory compared to OS threads.

Sample fiber creation:

new Fiber ((SuspendableRunnable) () -> { /* your code */ }).start();

Performance results from a production migration are presented: TPS increased by roughly 3× (up to 294 % of the original), latency and error rates remained stable, demonstrating the practical benefits of the approach.

The article concludes with a discussion of migration costs, learning curve, and the importance of ensuring end‑to‑end non‑blocking behavior, while providing references for further reading.

JavaperformanceconcurrencyReactive ProgrammingWebFluxFiberQuasar
Beike Product & Technology
Written by

Beike Product & Technology

As Beike's official product and technology account, we are committed to building a platform for sharing Beike's product and technology insights, targeting internet/O2O developers and product professionals. We share high-quality original articles, tech salon events, and recruitment information weekly. Welcome to follow us.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.