Java Reference
In-Depth Information
Under light to moderate load, the thread-per-task approach is an improvement over sequential
execution. As long as the request arrival rate does not exceed the server's capacity to handle
requests, this approach offers better responsiveness and throughput.
6.1.3. Disadvantages of Unbounded Thread Creation
For production use, however, the thread-per-task approach has some practical drawbacks, es-
pecially when a large number of threads may be created:
Thread lifecycle overhead.
Thread creation and teardown are not free. The actual over-
head varies across platforms, but thread creation takes time, introducing latency into
request processing, and requires some processing activity by the JVM and OS. If re-
quests are frequent and lightweight, as in most server applications, creating a new
thread for each request can consume significant computing resources.
Resource consumption.
Active threads consume system resources, especially memory.
When there are more runnable threads than available processors, threads sit idle. Hav-
ing many idle threads can tie up a lot of memory, putting pressure on the garbage col-
lector, and having many threads competing for the CPUs can impose other perform-
ance costs as well. If you have enough threads to keep all the CPUs busy, creating
more threads won't help and may even hurt.
Stability.
There is a limit on how many threads can be created. The limit varies by
platform and is affected by factors including JVM invocation parameters, the reques-
ted stack size in the
Thread
constructor, and limits on threads placed by the un-
OutOfMemoryError
. Trying to recover from such an error is very risky; it is far
easier to structure your program to avoid hitting this limit.
Up to a certain point, more threads can improve throughput, but beyond that point creating
more threads just slows down your application, and creating one thread too many can cause
your entire application to crash horribly. The way to stay out of danger is to place some bound
on how many threads your application creates, and to test your application thoroughly to en-
sure that, even when this bound is reached, it does not run out of resources.
The problem with the thread-per-task approach is that nothing places any limit on the number
of threads created except the rate at which remote users can throw HTTP requests at it. Like
other concurrency hazards, unbounded thread creation may
appear
to work just fine during
prototyping and development, with problems surfacing only when the application is deployed
and under heavy load. So a malicious user, or enough ordinary users, can make your web
