RxJava+Spring Boot线程使用咨询：最佳实践、上限及并发数

Hey there! Let's tackle your questions about RxJava threading in a high-concurrency Spring Boot production setup—this is a critical area to get right to avoid performance meltdowns.

a) Is using Schedulers.newThread() the best practice? #

Absolutely not. Here's why:

• Schedulers.newThread() creates a brand new thread for every single task. With 500 concurrent requests spawning 10 threads each, you're looking at 5,500 total threads (plus the 500 request threads themselves). That's way too many for any production system.
• Thread creation and destruction have significant overhead—each thread requires memory for its stack, thread object metadata, and OS-level resources.
• With thousands of threads, your CPU will spend most of its time switching between thread contexts instead of executing actual work. This leads to massive performance degradation, high latency, and even potential OutOfMemoryErrors (OOM) if the system runs out of memory for thread stacks.

The best practice here is to use a custom thread pool that reuses threads and enforces limits. This keeps resource usage predictable and efficient.

b) Can we set an upper limit on the number of threads generated? #

Yes, absolutely—and this is essential for production. Instead of relying on Schedulers.newThread(), you'll create a configurable ExecutorService and wrap it into an RxJava Scheduler.

Here's a practical example of setting up a bounded thread pool for RxJava:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
import com.google.common.util.concurrent.ThreadFactoryBuilder;
import io.reactivex.rxjava3.core.Scheduler;
import io.reactivex.rxjava3.schedulers.Schedulers;

// Define your custom thread pool
ExecutorService customThreadPool = new ThreadPoolExecutor(
    64,          // Core pool size: number of threads kept alive even when idle
    128,         // Maximum pool size: upper limit on total threads
    60L,         // Keep-alive time for excess threads
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(2000), // Queue for pending tasks
    new ThreadFactoryBuilder()
        .setNameFormat("rx-task-%d") // Named threads for easier debugging
        .build()
);

// Wrap the executor into an RxJava Scheduler
Scheduler customScheduler = Schedulers.from(customThreadPool);

// Use this scheduler in your RxJava code instead of Schedulers.newThread()
someObservable
    .subscribeOn(customScheduler)
    .subscribe(...);

This setup ensures you never exceed the maximum thread count you've defined. Pending tasks will wait in the queue instead of spawning new threads, preventing resource exhaustion.

c) How many concurrent threads can a 32GB Java environment support? #

There's no one-size-fits-all answer, but let's break down the factors:

• By default, each Java thread has a stack size of ~1MB (configurable via the -Xss JVM flag). In theory, 32GB of memory could support around 32,000 threads—but this is a theoretical maximum that ignores all other memory usage.
• In practice, your JVM will allocate most of that 32GB to the heap (e.g., 24GB for application data), leaving only 8GB for thread stacks, non-heap memory (metaspace, direct buffers), and system resources.
• Even if memory allows, 5,500 threads is way beyond what a system can handle efficiently. Context switching between thousands of threads will cripple CPU utilization—your system will spend more time switching threads than doing actual work.

For your 500-concurrent-request scenario, you don't need 5,500 threads. A well-tuned thread pool with 64-128 total threads (depending on your CPU core count—usually 2x the number of cores for CPU-bound tasks, or higher for I/O-bound tasks) will perform far better than thousands of short-lived threads. The queue will handle pending tasks, and thread reuse eliminates the overhead of constant thread creation.

内容的提问来源于stack exchange，提问作者Ankit Bansal