Page History

Many programs must address the problem of handling a series of incoming requests. TheOne simple concurrency strategy is the Thread-Per-Message design pattern, iswhich the simplest concurrency strategy, wherein uses a new thread is created for each request \[[Lea 2000|AA. Bibliography#Lea 00]\]. This pattern is generally preferred toover sequential executions of time-consuming, I/O-bound, session-based, or isolated tasks.

However, thisthe pattern also has several pitfallsintroduces additional overheads not seen in sequential execution, including overheads of the time and resource required for thread-creation and scheduling, for task processing, for resource allocation and deallocation, and for frequent context switching \[[Lea 2000|AA. Bibliography#Lea 00]\]. Furthermore, an attacker can cause a denial of service by overwhelming the system with too many requests all at once. Instead of, causing the system to become unresponsive rather than degrading gracefully,. theThis systemcan becomes unresponsive, causinglead to a denial of service. From a safety perspective, one component can exhaust all resources becausedue ofto somean intermittent error, consequently starving all other components.

This compliant solution uses a fixed-thread pool that places an upper bound on the number of concurrently executing threads. Tasks submitted to the pool are stored in an internal queue. This prevents the system from being overwhelmed when tryingattempting to respond to all incoming requests and allows it to degrade gracefully by serving a fixed maximum number of simultaneous clients at a particular time \[[Tutorials 2008|AA. Bibliography#Tutorials 08]\].

The choice of the unbounded {{newFixedThreadPool}} ismay notbe always optimalinappropriate. Refer to the Java API documentation for guidance on choosing between the following  to meet specific design requirements \[[API 2006|AA. Bibliography#API 06]\]: