首先呢，肯定不会有那样的一个具体业务必须使用线程池，学编程一定不是学了什么知识点一定在什么场景下用的，而是能根据实际场景分析使用什么知识去解决才对。
课程里介绍过多线程的优势与风险，我也说过实际中每个接口天生都具有多线程并发的特点，这时候我们就不得不自己去处理好一些线程安全问题。这个时候我们属于被动的要接受多线程带来的好处之外的“麻烦”。
然而，总会有一些时候，我们会感觉一个任务、或者说一个方法，处理的“太慢”，我们希望能够提速！这时候我们就会考虑到使用多个线程一起处理，引入多线程的时候，很自然的要考虑一个问题，就是不能无限制的引入无数个线程，cpu和内存可能都会扛不住，创建线程的开销也很大（我们介绍过new thread的弊端），这时候就需要考虑主动引入多线程的时候，要使用线程池来管理线程。
说一下我自己遇到的实际场景来具体说明一下，我现在负责的股票系统，每天要去提供数据的第三方更新所有股票对应公司的基本信息，将近9000家，每个公司的基本数据的获取是互相没关系的，谁先更新谁后更新顺序也是无所谓的，如果方法里不引入多线程，单个线程执行一次需要10分钟左右，我感觉这个时间有点长，因此我就引入了线程池，控制同时执行的线程数为20，这样更新一次下来就在半分钟左右了。
再举一个例子好了。之前有一次项目重做，底层的表变化很大，项目上线时需要先清洗数据，将之前的数据按照新的逻辑清洗到新表里，直接sql不行，我们需要写代码做的清洗。我们需要遍历系统里几万的用户，从用户维度清洗每一个表数据，模拟清洗时我们发现按顺序每个人依次清洗需要半个小时左右，但是这个时间太长，对于系统而言风险很大，最后我们也是引入了线程池，并发在几十左右的，具体数字记不住了，最后也是控制清洗时间在半分钟前后。当然了，这个的前提是我们确认数据库能撑得住。
好了，鉴于以上这些，你再来理解一下线程池的使用吧
