In order to reuse threads as well as connections, application containers manage pools. Requested threads don't necessarily have to be created but are reused from a pool.

Pooling is used to control the load on specific parts of the system. Choosing appropriate pool sizes allows the system to be saturated well, but prevents it from overloading. This is due to the fact that empty pools will lead to suspended or rejected requests. All threads and connections of that pool are then being utilized already.

The bulkhead pattern prevents different parts of the system from affecting each other by defining dedicated thread pools. This limits the resource shortage to a potentially problematic functionality. In some cases, functionality such as a legacy system might be known to cause issues. Bulkheads, implemented as dedicated thread pools, and timeout configuration help preserve the application's health.

Empty pools either originate from the current load on that pool being exceptionally high, or resources that are acquired for much longer than expected. In any case, it's advisable not to simply increase the corresponding pool size but to investigate where the issue originates from. The described investigation techniques as well as JMX insights and thread dumps will supports you in finding bottlenecks, as well as potential programming errors, such as deadlocks, misconfigured timeouts, or resource leaks. In the minority of cases will a shortage in pooling actually originate from a high workload.

Pool sizes and configuration is made in the application container. Engineers must perform proper performance sampling in production before and after reconfiguring the server.