业务场景：
打开微信要查询、转账、发红包等，后台要处理相关业务时就需要前台发送数据
当前服务端要处理很多业务，先通过网络把客户端 (请求类型和请求数据) 请求发送给服务端，发送时明确该请求是做什么业务和所提交的数据
同一时刻有多个客户端去访问服务端，
- 方法1.服务端就挨个创建线程处理请求，但是这并不现实，
- 方法2.服务端有一个接收线程(只接收不处理)和一个发送线程，
—客户端发送所有的数据都是接收线程拿到，然后放入线程安全队列中；
—业务线程处理数据，将结果放入另一个线程安全队列中
—发送线程将新线程安全队列中的数据拿走并发送给客户端
客户端的请求数量和时间是不固定的，所以为了节约资源需要判断初始化业务线程的数量
（分布式系统：服务器数量不够就扩充，会导致部分机器空闲，部分很忙）
本质：一个线程安全队列+一堆线程(执行的是同一个入口函数)
线程池要想处理广泛的业务，其类型就是通用的，
线程池:一种线程使用模式。
- 线程过多会带来调度开销，进而影响缓存局部性和整体性能。而线程池维护着多个线程，等待着监督管理者分配可并发执行的任务。这避免了在处理短时间任务时创建与销毁线程的代价。
- 线程池不仅能够保证内核的充分利用，还能防止过分调度。可用线程数量应该取决于可用的并发处理器、处理器内核、内存、网络sockets等的数量。
线程池的应用场景：
- 需要大量的线程来完成任务，且完成任务的时间比较短。 WEB服务器完成网页请求这样的任务，使用线程池技术是非常合适的。因为单个任务小，而任务数量巨大，你可以想象一个热门网站的点击次数。 但对于长时间的任务，比如一个Telnet连接请求，线程池的优点就不明显了。因为Telnet会话时间比线程的创建时间大
多了。- 对性能要求苛刻的应用，比如要求服务器迅速响应客户请求。
- 接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。突发性大量客户请求，在没
有线程池情况下，将产生大量线程，虽然理论上大部分操作系统线程数目最大值不是问题，短时间内产生大量线程
可能使内存到达极限，出现错误
