有几家饭店，顾客源源不断下单，生意很好，一开始随机雇佣送外卖的小哥来取包裹派送（创建线程），发现太麻烦，打电话给小哥浪费时间（线程开销大，销毁切换）。
1、newFixedThreadPool【定长线程池，可控制最多并发数】
A饭店高级饭店， 用户都是高端人士，路途遥远，要求的配送人员素质高，
1.配送部门成立（线程池 threadPool）。
2.部门有10 个小哥 全职送外卖(核心线程数量 corePoolSize)。
3.15 辆电瓶车，10个小哥忙不过来， 最多叫5个临时小哥来送，因为只有15 辆电瓶车，所以最多只存在15 个人在送货（最大线程数 maxPoolSize）。
4.一个存放外卖的桌子，当正在派送的外卖>小哥的数量，外卖会放到桌子上（队列，默认 LinkedBolckqueue，用于存储外卖）。
5.正在途中配送外卖 大于10个的时候，老板会查看每个小哥休息时间，因为人员多了成本就多了，如果一个小哥连续一个小时（keepLiveTime，大于核心线程数量，会去考虑空闲时间）仍然接不到外卖，就把他解雇了（线程摧毁）。
2、newCachedThreadPool【可缓存线程池】
B饭店快餐店，都是路途比较近的，普通大众客户，要求马上吃饭
1.配送部门成立（线程池 threadPool）。
2 因为生意太火爆， 配送人员太大了，没有聘用固定的正式人员（核心线程0）
3 配送人员数量基数大（maxpoolSize 为Integer.maxValue）
4 一个存放外卖的桌子（默认 SynchronousQueue，同步队列，放进的外卖，必须有人拿， 才能放进新的外卖。为什么这么设计？如果外卖积压过多，类似楼上那家饭店。本身这个是个快餐店， 用户会很不满意，这个饭店就是为了时间段， 并发高的场景）。
只要新做好的外卖没有配送人员， 马上雇佣一个，把桌子上的外卖拿走， 下一个外卖才能放进去。
5 配送人员解雇：所有的员工都有等待时间，当超过时间段， 直接销毁。（当线程数大于核心时，多于的空闲线程最多存活时间，这个所有线程池一样）。
3、newSingleThreadExecutor【单线程化线程池】
白宫专用饭店，因为是机关单位，不能随便让人员配送，只能找一个稳重，背景可靠的员工配送。保证安全。
1.配送部门成立（线程池 threadPool）.
2.固定配送人员 1人（corePoolSize =1）.
3.最大配送人员 1 人（maxPoolSize=1）.
4 存放外卖的桌子，按照顺序送， 显示总统， 再是副总统，首相、、、（LinkedBlockingQueue 阻塞队列）
5 配送人员解雇：一般不会解雇。除非这个人挂了，再去找一个人。
4、newScheduledThreadPool【定长 定时周期性线程池】
女王专用饭店， 只为各位女王大人服务的饭店， 女王说了， 少吃多餐，两个小时用餐一次。
1.配送部门成立（线程池 threadPool）.
2.固定配送人员 10人（corePoolSize =10）.
3.最大配送人员 1 人（maxPoolSize=Integer.maxSize）.
4 存放外卖的桌子（桌子上 有 闹钟， 几点送， 每隔多长时间送，DelayedWorkQueue 为默认队列（需要重复的任务会重置 执行时间，把自己加入到这个队列，比如订单1 杨幂 中午十二点配送， 在送完， 会重新生成订单，14点配送））。
5 配送人员解雇 ：超过十个人会计算等待时间
场景分析：开发中的重试任务，可以考虑用这种线程池
5、newWorkStealingPool【创建一个拥有多个任务队列（以便减少连接数）的线程池】
这种是jdk 8 才出现的线程池，就没怎么见到用过， 按照理解，介绍并发，比如订单太多了， 外卖的数量远远大于桌子承受的数量， 总不能把1 万份外卖全部放在一个桌子上， 所以使用并发，减少竞争。
非常用线程池略。。。。。。。。。。。
拒绝策略
后来仓库满了，配送人员也没有了(最大线程数)
1、订单全部拒绝（新来的任务直接抛弃）
2、把最早放到仓库的外卖丢了，因为第一个顾客等了很久 ，估计饿死了，然后把新的订单放进仓库（拒绝队列最早的任务）
3、新订单拒绝 并发出公告， 告诉顾客我们饭店炸了， 别来点外卖（抛弃这个任务， 抛出异常）
4、打电话给下订单的客户， 我们没人手 了， 你直接来饭店拿 ，（当前调用线程处理任务）。
5、自定义策略
