共计 5667 个字符，预计需要花费 15 分钟才能阅读完成。
一、创立线程的形式
1 继承 Thread 类并重写 run 办法 。实现简略，但不合乎里氏替换准则，不能够继承其余类。 步骤：
（1）继承 Thread 类并重写 run 办法，该 run 办法的办法体就代表了线程要实现的工作。因而把 run()办法称为执行体。
（2）创立线程对象并调用 start 办法进行启动
2 实现 Runnable 接口并重写 run 办法 。防止了单继承局限性，编程更加灵便，实现解耦。 步骤：
（1）实现 Runnable 接口并重写 run 办法
（2）创立线程对象并调用 start 办法进行启动
3 实现 Callable 接口并重写 call 办法。能够获取线程执行后果的返回值，并且能够抛出异样。步骤：
（1）定义一个类实现 Callable 接口，并实现 call()办法，该 call()办法将作为线程执行体，并且有返回值。
（2）创立线程对象，应用 FutureTask 类来包装 Callable 对象，并调用 start 办法进行启动 FutureTask<Integer> ft = new FutureTask<>(mc);
（3）调用 FutureTask 对象的 get()办法来取得子线程执行完结后的返回值
4 应用 Executors 工具类创立线程池
二、为什么要有线程池
想想咱们之前没用线程池的时候，每次创立线程都是：new Thread(() -> {...})，再调 start() 办法来执行线程。这就会带来一系列问题，比方：线程的创立和销毁都是很耗时很节约性能的操作。再者，简略的 new 两三个 Thread 还好，但若须要上百个线程呢？而且用完再销毁掉时又要一个一个的进行销毁。那这上百个线程的创立和销毁的性能是很蹩脚的！
线程池诞生就是为了解决上述问题。其核心思想就是：线程复用。也就是说线程用完后不销毁，放到池子里等着新工作的到来，重复利用 N 个线程来执行所有新老工作。这带来的开销只会是那 N 个线程的创立，而不是每来一个申请都带来一个线程的从生到死的过程。
因而应用线程池的益处与长处：
- 升高资源耗费。通过反复利用已创立的线程升高线程创立和销毁造成的耗费。
- 进步响应速度。当工作达到时，工作能够不须要的等到线程创立就能立刻执行。
- 进步线程的可管理性。应用线程池能够对线程进行对立的调配，调优和监控。
三、创立线程池的办法
3.1 七大参数
能够通过 Executors 的动态工厂办法创立线程池：
不倡议应用 Executors 来创立，而是应用 ThreadPoolExceutor 的形式，这样的解决⽅式让写的同学更加明确线程池的运⾏规定，躲避资源耗尽的⻛险。
上源码（有七大参数）：
public ThreadPoolExecutor(
int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {}① corePoolSize：外围线程数
默认状况下，在创立了线程池后，线程池中的线程数为 0，当有工作来之后，就会创立一个线程去执行工作。核⼼线程数定义了最⼩能够同时运⾏的线程数量。当线程池中的线程数目达到 corePoolSize 后，就会把达到的工作放到工作队列当中。默认不会被回收掉，然而如果设置了 allowCoreTimeOut 为 true，那么当外围线程闲置时，也会被回收。
② maximumPoolSize：最大线程数
当队列中寄存的工作达到队列容量的时候，以后能够同时运行的线程数量变为最大线程数。如果与外围线程数设置雷同代表固定大小线程池。
③ workQueue：工作队列
当线程申请数大于等于 corePoolSize 时线程会进入工作队列。阻塞队列，用来存储期待执行的工作，新工作被提交后，会先进入到此工作队列中，任务调度时再从队列中取出工作。这里的阻塞队列有以下几种抉择：
ArrayBlockingQueue：基于数组的有界阻塞队列，按 FIFO 排序；LinkedBlockingQueue：基于链表的无界阻塞队列（其实最大容量为 Interger.MAX），依照 FIFO 排序；SynchronousQueue：一个不缓存工作的阻塞队列，也就是说新工作进来时，不会缓存，而是间接被调度执行该工作；PriorityBlockingQueue：具备优先级的无界阻塞队列，优先级通过参数 Comparator 实现。
④ unit：单位，keepAliveTime 的工夫单位。比方：TimeUnit.MILLISECONDS、TimeUnit.SECONDS
⑤ keepAliveTime：线程闲暇工夫
线程闲暇工夫达到该值后会被销毁，直到只剩下 corePoolSize 个线程为止，避免浪费内存资源。
⑥ threadFactory：线程工厂
当线程池须要新的线程时，会用 threadFactory 来生成新的线程
默认采纳的是 DefaultThreadFactory，次要负责创立线程。newThread() 办法。创立进去的线程都在同一个线程组且优先级也是一样的。即用来生产一组雷同工作的线程。能够给线程命名，有利于剖析谬误。
⑦ handler：回绝策略。
-
AbortPolicy抛弃工作并抛出异样；性能：当触发回绝策略时，间接抛出拒绝执行的异样，停止策略的意思也就是打断以后执行流程
应用场景：这个就没有非凡的场景了，然而一点要正确处理抛出的异样。
ThreadPoolExecutor 中默认的策略就是 AbortPolicy，ExecutorService 接口的系列 ThreadPoolExecutor 因为都没有显示的设置回绝策略，所以默认的都是这个。然而请留神，ExecutorService 中的线程池实例队列都是无界的，也就是说把内存撑爆了都不会触发回绝策略。当本人自定义线程池实例时，应用这个策略肯定要解决好触发策略时抛的异样，因为他会打断以后的执行流程。
-
CallerRunsPolicy调用执行本人的线程运行工作。然而这种策略会升高对于新工作提交速度，影响程序的整体性能。另外，这个策略喜爱减少队列容量。如果您的应用程序能够接受此提早并且你不能抛弃任何一个工作申请的话，你能够抉择这个策略；性能：当触发回绝策略时，只有线程池没有敞开，就由提交工作的以后线程解决。
应用场景：个别在不容许失败的、对性能要求不高、并发量较小的场景下应用，因为线程池个别状况下不会敞开，也就是提交的工作肯定会被运行，然而因为是调用者线程本人执行的，当屡次提交工作时，就会阻塞后续工作执行，性能和效率天然就慢了。
-
DiscardOldestPolicy示意摈弃队列里期待最久的工作并把当前任务退出队列；性能：间接静悄悄的抛弃这个工作，不触发任何动作
应用场景：如果你提交的工作无关紧要，你就能够应用它。因为它就是个空实现，会悄无声息的吞噬你的的工作。所以这个策略基本上不必了
-
DiscardPolicy示意间接摈弃当前任务但不抛出异样。性能：如果线程池未敞开，就弹出队列头部的元素，而后尝试执行
应用场景：这个策略还是会抛弃工作，抛弃时也是毫无声息，然而特点是抛弃的是老的未执行的工作，而且是待执行优先级较高的工作。基于这个个性，我能想到的场景就是，公布音讯，和批改音讯，当音讯公布进来后，还未执行，此时更新的音讯又来了，这个时候未执行的音讯的版本比当初提交的音讯版本要低就能够被抛弃了。因为队列中还有可能存在音讯版本更低的音讯会排队执行，所以在真正解决音讯的时候肯定要做好音讯的版本比拟。
3.2 示例
3.3 内置封装好的的几个线程池
能够这样来创立：ExecutorService MyExecutorService = Executors.newCachedThreadPool();
newFixedThreadPool，固定大小的线程池，外围线程数也是最大线程数，不存在闲暇线程，keepAliveTime = 0。该线程池应用的工作队列是无界阻塞队列 LinkedBlockingQueue，实用于负载较重的服务器。newSingleThreadExecutor，应用单线程，相当于单线程串行执行所有工作，实用于须要保障程序执行工作的场景。与单线程性能比拟：尽管同是一个线程在工作，然而应用单线程池效率高多了。newCachedThreadPool，该办法返回一个可依据理论状况调整线程数量的线程池。线程池的线程数量不确定，但若有闲暇线程能够复用，则会优先应用可复用的线程。若所有线程均在工作，又有新的工作提交，则会创立新的线程解决工作。所有线程在当前任务执行结束后，将返回线程池进行复用。-
newScheduledThreadPool：反对定期及周期性工作执行，实用须要多个后盾线程执行周期工作，同时须要限度线程数量的场景。与 newCachedThreadPool 的区别是不回收工作线程。原理：ScheduedThreadPoolExecutor 是先把工作放到一个 DelayQueue 提早队列中，而后再启动一个线程，再去队列中取周期时间离以后工夫最近的那个工作。ScheduedThreadPoolExecutor 保护了一个 DelayQueue 存储期待的工作，DelayQueue 外面有一个 PriorityQueue 优先级队列，他会依据 time 的工夫大小排序，工夫越小的越靠前。DelayQueue 也是一个无界队列，然而初始大小为 16，超过 16 会进行一次扩容。有三种提交工作的形式：- schedule，特定工夫延时后执行一次工作
- scheduledAtFixedRate，固定周期执行工作（与工作执行工夫无关，周期是固定的）
- scheduledWithFixedDelay，固定延时执行工作（与工作执行工夫无关，延时从上一次工作实现后开始）
四、线程池解决工作的流程
① 外围线程池未满，创立一个新的线程执行工作，此时 workCount < corePoolSize，须要获取全局锁。
② 如果外围线程池已满，工作队列未满，将工作存储在工作队列，此时 workCount >= corePoolSize。
③ 如果工作队列已满，线程数小于最大线程数就创立一个新线程解决工作，此时 workCount < maximumPoolSize，这一步也须要获取全局锁。
④ 如果超过最大线程数，依照回绝策略来解决工作，此时 workCount > maximumPoolSize。
线程池创立线程时，会将线程封装成工作线程 Worker，Worker 在执行完工作后还会循环获取工作队列中的工作来执行。
举例说明：
线程池参数配置：外围线程 5 个，最大线程数 10 个，队列长度为 100。
那么线程池启动的时候不会创立任何线程，假如申请进来 6 个，则会创立 5 个外围线程来解决五个申请，另一个没被解决到的进入到队列。这时候有进来 99 个申请，线程池发现外围线程满了，队列还在空着 99 个地位，所以会进入到队列里 99 个，加上方才的 1 个正好 100 个。这时候再次进来 5 个申请，线程池会再次开拓五个非核心线程来解决这五个申请。目前的状况是线程池里线程数是 10 个 RUNNING 状态的，队列里 100 个也满了。如果这时候又进来 1 个申请，则间接走回绝策略。
五、线程池的执行与敞开
5.1 执行工作
线程池中 submit() 和 execute() 办法有什么区别？
- 接管参数：execute()只能执行 Runnable 类型的工作。submit()能够执行 Runnable 和 Callable 类型的工作。
- 返回值：execute() ⽅法⽤于提交不须要返回值的工作，所以⽆法判断工作是否被线程池执⾏胜利与否；submit() ⽅法⽤于提交须要返回值的工作。线程池会返回⼀个 Future 类型的对象，通过这个 Future 对象能够判断工作是否执⾏胜利，并且能够通过 Future 的 get() ⽅法来获取返回值，get() ⽅法会阻塞以后线程直到工作实现，⽽使⽤ get（long timeout，TimeUnit unit）⽅法令会阻塞以后线程⼀段时间后⽴即返回，这时候有可能工作没有执⾏完。
- 异样解决：submit()不便 Exception 解决
5.2 敞开线程池
能够调用 shutdown() 或 shutdownNow() 办法敞开线程池，原理是遍历线程池中的工作线程，而后一一调用线程的 interrupt 办法中断线程，无奈响应中断的工作可能永远无奈终止。
二者区别
shutdownNow首先将线程池的状态设为 STOP，而后尝试进行正在执行或暂停工作的线程，并返回期待执行工作的列表。shutdown只是将线程池的状态设为 SHUTDOWN，而后中断没有正在执行工作的线程。通常调用 shutdown 来敞开线程池，如果工作不肯定要执行完可调用 shutdownNow。
六、线程池线程数如何设计？即线程池线程数与 (CPU 密集型工作和 I / O 密集型工作) 的关系
CPU 密集型: 这种工作个别不占用大量 IO，所以后盾服务器能够疾速解决，压力落在 CPU 上。
I/ O 密集型: 常有大数据量的查问和批量插入操作，此时的压力次要在 I / O 上。
- 与 CPU 密集型的关系：个别状况下，CPU 外围数 == 最大同时执行线程数 。在这种状况下(设 CPU 外围数为 n)，大量客户端会发送申请到服务器，然而服务器最多只能同时执行 n 个线程。所以这种状况下，无需设置过大的线程池工作队列，（ 工作队列长度 = CPU 外围数 || CPU 外围数 +1）即可。
- 与 I / O 密集型的关系：因为长时间的 I / O 操作，导致线程始终处于工作队列，但它又不占用 CPU，则此时有 1 个 CPU 是处于闲暇状态的。所以，这种状况下，应该加大线程池工作队列的长度，尽量不让 CPU 闲暇下来，进步 CPU 利用率。
一般说来，线程池的大小应该怎么设置（线程池初始的默认外围线程数大小？）（其中 N 为 CPU 的个数）。
- 如果是 CPU 密集型 利用，则线程池大小设置为
N+1， - 如果是 IO 密集型 利用，则线程池大小设置为
2N+1。