Real Life Example;
- Facility: Operating system
- Sections: Applications
- People: Threads
You have a facility there 12 people are working. There are 3 sections of this facility. Kitchen, restrooms and security. If you do not use thread pool technique, that's how it works: All 12 people will be standing in a meeting room, if new customers come by facility and ask for tasks, then you will separate people in groups and send them to do their work, and come back to meeting room. But, before they go to their duty, there is a preparation phase. They need to wear correct uniform, equip certain devices and walk to that section, finish work and come back. So, once every time they finish their job (thread ends), they need to walk back to meeting room, undress uniform, take out equipment and wait for next job. These refer to creating thread context, it's memory allocation and tracking information by OS. It is too much time consuming for OS to re-organize new thread needs.
If you are using thread pooling, then, in the early morning, you will assign 6 people to kitchen, 2 people to restroom and 4 people to security. So, they will only do their preparation once in a day. Even if there is no customers at the kitchen, those 4 people will be there, idling, for any upcoming tasks. They do not need to go back to meeting room until kitchen closes (app ends). These 4 people are in the Kitchen app pool, and ready to serve quickly. But, you cannot promise they are working all day along, since kitchen may become idle time to time. Same logic applies for restrooms and security as well.
In first scenario, you do not waste any thread for any task, BUT it will take good amount of time to prepare every single thread for each task. In second one, you prepare threads in advance, so you cannot guarantee you will be using all threads for all tasks but, OS mostly makes great optimization on it, so you can safely rely on it.