Java Reference
In-Depth Information
Setting the Minimum Number of Threads
Once the maximum number of threads in a thread pool has been determined, it's time to de-
termine the minimum number of threads needed. To cut to the chase, in almost all cases, set
the minimum number of threads to the same value as the maximum.
The argument for setting the minimum number of threads to some other value (e.g., 1) is that
it prevents the system from creating too many threads, which saves on system resources. It is
true that each thread requires a certain amount of memory, particularly for its stack (which is
discussed later in this chapter). Again, though, following one of the general rules from
Chapter 2 , the system needs to be sized to handle the maximum expected throughput, at
which point it will need to create all those threads. If the system can't handle the maximum
number of threads, then choosing a small minimum number of threads doesn't really help: if
the system does hit the condition that requires the maximum number of threads (and which it
cannot handle), the system will certainly be in the weeds. Better to create all the threads that
might eventually be needed and ensure that the system can handle the maximum expected
load.
On the other hand, the downside to specifying a minimum number of threads is fairly minim-
al. That downside occurs the first time there are multiple tasks to execute: then the pool will
need to create a new thread. Creating threads is detrimental to performance—which is why
thread pools are needed in the first place—but this one-time cost for creating the thread is
likely to be unnoticed in performance testing (as long as it then remains in the pool).
In a batch application, it does not matter whether the thread is allocated when the pool is cre-
ated (which is what will occur if you set the minimum and maximum number of threads to
the same value) or whether the thread is allocated on demand: the time to execute the applic-
ation will be the same. In other applications, the new threads are likely allocated during the
warm-up period (and again the total time to allocate the threads is the same); the effect on the
performance of an application will be negligible. Even if the thread creation occurs during
the measurement cycle, as long as the thread creation is limited, it will likely not be noticed.
One other tuning that applies here is the idle time for a thread. Say that the pool is sized with
a minimum of one thread and a maximum of four. Now suppose there is usually one thread
executing a task, and then the application starts a cycle where every 15 seconds, the work-
load has on average two tasks to execute. The first time through that cycle, the pool will cre-
ate the second thread—and now it makes sense for that second thread to stay in the pool for
at least some period of time. You want to avoid the situation where that second thread is cre-
ated, finishes its task in 5 seconds, is idle for 5 seconds, and then exits—since 5 seconds
later, a second thread will be needed for the next task. In general, once a thread is created in a
Search WWH ::




Custom Search