Java线程池参数详解、线程池创建、状态、任务执行剖析 附(Demo) 线程池使用之CountDownLatch & Executor、ExecutorService和Executors的区别
何为浅析线程池 ？
与数据库连接池原理类似，线程池是将线程对象放入一个"池子" 中，之后向该池子中获取、使用、回收线程
注意：
-
每个线程在一个时间片只执行一个任务
-
线程可重复使用
如果线程池的状态是运行中，可控制运行线程的数量，处理过程中将任务放入队列，然后在线程创建后启动这些任务，如果任务量超出corePoolSize，在workQueue中等待。否则，corePoolSize满，等待队列未满，等待队列等候，等待核心线程的其他线程执行完毕，再从等待队列中取任务执行。corePoolSize 满且等待队列满，非核心线程执行任务；如果线程池中的提交任务量已满(maximumPoolSize + workQueue.size())，程序抛出异常(视拒绝策略而定)。
线程池优势：
-
线程复用(降低资源消耗——通过重复利用已创建的线程，降低线程创建和销毁的消耗)
-
提高响应速度 当线程仍有空闲线程时(向线程池中提交的任务量 < corePoolSize)，任务不需要等待线程创建就能立即执行
-
提高线程的可管理性(线程是稀缺资源，无限制的创建，不仅消耗系统资源，还会降低系统的稳定性，而使用线程池可以进行统一分配、调优、监控)
线程池的特点
-
线程复用
-
控制最大并发数
-
管理线程
线程池创建方式
根据具体的业务需求，通过 JUC 提供的 Executors 类来创建各种类型的线程池。
-
1、Executors.newSingleThreadExecutor(): 任务顺序执行
-
2、Executors.newCachedThreadPool() : 创建一个可缓存线程的线程池，线程可同时执行，默认情况下，空闲时间超过60s ，线程会被终止运行并从池中删除corePoolSize = 0，maximumPoolSize为Integer_MAX_VALUE,同步队列。
-
3、Executors.newFixedThreadPool(int) : 池中的线程数是固定的，控制并发数，线程不会从池中删除。一般情况下，int 为本机cpu核数一致。
-
4、Executors.newSingleThreadScheduleExecutor(): 创建一个可用于“任务调度”的线程池，用户指定的时间执行！
-
5、Executors.newScheduleThreadPool (): 创建一个可用于“任务调度”的线程池，并且池中有多个线程
1-3 创建ExecutorService类型的线程池，4-5创建ScheduleExecutorService类型的线程池(继承ExecutorService)
线程池使用方法
ExecutorService类型的线程池
可以通过submit向ExecutorService中提交Callable或者Runnable类型的任务，任务提交后被线程池中的线程领取并执行。执行完毕后返回到Future对象中：
(1) 如果是Callable类型的线程任务，通过Callable中 call() 方法执行，并用Future对象接收call() 的返回值
(2) 如果是Runnable类型的线程任务，通过Runnable方法中的 run() 方法执行，而 run() 方法没有返回值，Future接收的值是NULL
shutDown() 等待执行的任务全部执行完毕后，线程池退出
shutDownNow() 将线程池中的线程状态立刻变成STOP状态，立刻停止所有正在执行任务的线程，不处理等待的任务
ScheduleExecutorService类型的线程池
通过schedule() 方法想ScheduleExecutorService中提交Callable或者Runnable类型的任务，特殊的是，用户可设置线程池中任务的执行时间。
线程池使用步骤
1、创建线程池
2、将任务通过submit() 或者 schedule() 提交到线程池中的线程
3、任务通过 call() 或者 run() 方法执行，将结果返回到Future对象
4、Future对象通过 get() 方法以封闭的方式拿到处理结果
任务执行示意图
说明： 当任务刚来时，直接创建核心线程去执行任务，核心线程未完成且任务量多于核心线程数，则放到队列中，等待执行，若放不下，则会创建非核心线程去执行，若达到Maximum，则按拒绝策略处理任务！
线程池构造方法中各个参数的意义
corePoolSize: 核心线程数最大值，一旦有任务提交，核心线程立即执行
maximumPoolSize: 线程池中最多可容纳的线程总数。 如果有任务提交，先交给核心线程执行，核心线程无空闲，任务放到workQueue中，如果等待队列也满了，才将任务交给非核心线程去执行。
keepAliveTime: 非核心线程最大空闲时间，如果非核心空闲超过该时间，线程将会被从线程池中删除，如果设置 allowCoreThreadTimeOut = true，那么keepAliveTime也会作用于核心线程！
unit: keepAliveTime的时间单位
workQueue: 等待提交到核心线程中的任务队列。
threadFactory: 创建线程的方式，一般默认
handler: 拒绝策略 拒绝超额(提交的任务大于(maximumPoolSize))，默认AbortPolicy,丢掉超额任务并抛出RejectExecutionException
拒绝策略的上级接口RejectExecutionHandler
1、AbortPolicy: 拒绝超额(提交的任务大于(maximumPoolSize + workQueue.size()))，默认AbortPolicy, 丢掉超额任务并抛出RejectExecutionException
2、DiscardPolicy: 提交的任务大于(maximumPoolSize + workQueue.size())，直接丢弃，不抛异常
3、DiscardOldestPolicy: 队列是FIFO结构，任务饱和，丢掉队列中最早的等待任务
4、CallRunsPolicy: 调用者（当前线程）处理任务 该策略并没有抛弃任何异常，由于线程池中已经没有对于线程来分配该任务，该策略是在当前线程（调用者线程）中直接执行该任务。
提交任务对比
submit() 有返回值
execute() 无返回值
线程池与多线程应用
/**
* @Author： Be.insighted
* Description：
* @date Create on 2020/8/29 11:16
**/
public class MultiThreadTest {
public static void main(String[] args) throws IOException, InterruptedException {
File file = new File("D:/test.txt");
if (file.exists()) {
file.delete();
file.createNewFile();
}
FileWriter fw = new FileWriter(file.getAbsoluteFile(), true);
BufferedWriter bw = new BufferedWriter(fw);
//记录条数
final int count = 10000000;
final int batch = 1000;
final int lop = count / batch;
final CountDownLatch countDown = new CountDownLatch(lop);
int i1 = Runtime.getRuntime().availableProcessors();
System.out.println("CPU 共" + i1 + "个");
long startTime = System.currentTimeMillis();
ThreadPoolExecutor service = new ThreadPoolExecutor(i1, 1000, 1, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>());
for (int start = 0; start < lop; start++) {
StringBuffer stringBuffer = new StringBuffer();
service.execute(() -> {
for (int i = 0; i < batch; i++) {
stringBuffer.append(getRandomString(4) + "," + (int) (Math.random() * 9000 + 1000) + "," + (int) (Math.random() * 9000 + 1000)).append("\r\n");
}
try {
synchronized (bw) {
bw.write(stringBuffer.toString());
bw.flush();
countDown.countDown();
}
} catch (IOException e) {
e.printStackTrace();
}
});
}
countDown.await();
bw.close();
service.shutdown();
long insertEndTime = System.currentTimeMillis();
System.out.println("插入耗时： " + (insertEndTime - startTime) + " ms");
FileReader reader = new FileReader(file);
BufferedReader br = new BufferedReader(reader);
Map<String, Integer> map = new HashMap<>();
Map<String, Long> countMap = new HashMap<>();
int lineCount = 0;
String line = null;
while ((line = br.readLine()) != null) {
final String[] infos = line.split("[,]");
String start = infos[0].substring(0, 2);
int salaryByYear = Integer.parseInt(infos[1]) + Integer.parseInt(infos[2]);
Integer s = map.get(start);
if (s != null) {
map.put(start, salaryByYear + s);
countMap.put(start, countMap.get(start) + 1);
} else {
map.put(start, salaryByYear);
countMap.put(start, 1L);
}
++lineCount;
}
List<Map.Entry<String, Integer>> list = new ArrayList<>(map.entrySet());
Collections.sort(list, new Comparator<Map.Entry<String, Integer>>() {
@Override
public int compare(Map.Entry<String, Integer> o1, Map.Entry<String, Integer> o2) {
return o1.getValue() - o2.getValue();
}
});
System.out.println("共计：" + lineCount + "行," + "是" + String.valueOf(lineCount).length() +"位数");
for (int i = 0; i < 10; i++) {
String key = list.get(i).getKey();
System.out.println(key + "," + list.get(i).getValue() + "万," + countMap.get(key) + "人");
}
System.out.println("装载内存处理耗时:" + (System.currentTimeMillis() - insertEndTime) + " ms");
service.shutdown();
}
static String getRandomString(int length) {
String str = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
Random random = new Random();
StringBuffer sb = new StringBuffer();
for (int i = 0; i < length; i++) {
int number = random.nextInt(5);
sb.append(str.charAt(number));
}
return sb.toString();
}
}
多线程与parallelStream
/**
* @Author： Be.insighted
* Description：
* @date Create on 2020/8/29 16:50
**/
public class MultiThreadExecuteTest {
/**
* 使用jdk8新特性并行处理 数据
*
* @param list
*/
public static void processList(List<Object> list) {
Random random = new Random(47);
Map<Integer, List<Object>> group = list.stream().collect(Collectors.groupingBy(e -> random.nextInt(100)));
group.values().parallelStream().forEach(e -> e.forEach(i ->
//这里可以根据自己的需要做处理
System.out.println("使用jdk8新特性打印处理数据" + i)));
}
/**
* 使用多线程处理数据
*
* @param list
* @param nThreads
* @throws Exception
*/
static void processList2(List<Object> list, final int nThreads) throws Exception {
// 存最后的结果
StringBuffer ret = new StringBuffer();
if (list == null || list.isEmpty()) {
//这里可以根据自己的业务需要去做处理
System.out.println("要处理的数据为空");
}
int size = list.size();
ExecutorService executorService = Executors.newFixedThreadPool(nThreads);
List<Future<Object>> futures = new ArrayList<>(nThreads);
//根据线程 进行数据的拆分
for (int i = 0; i < nThreads; i++) {
final List<Object> subList = list.subList(size / nThreads * i, size / nThreads * (i + 1));
Callable<Object> task = new Callable<Object>() {
@Override
public Object call() throws Exception {
//存当前线程处理的数据，最后统一汇总打印
StringBuffer sb = new StringBuffer();
for (Object str : subList) {
sb.append(str + "\t");
}
return sb.toString();
}
};
futures.add(executorService.submit(task));
}
// 汇总处理的结果
for (Future<Object> future : futures) {
ret.append(future.get());
}
executorService.shutdown();
System.out.println("并发处理结果: " + ret.toString());
}
public static void main(String[] args) throws Exception {
List<Object> list = new ArrayList<>();
for (int i = 0; i < 100; i++) {
list.add(String.valueOf(i));
}
processList2(list, 5);
processList(list);
}
}
Executor、ExecutorService和Executors的区别:
* The {@code Executor} implementations provided in this package
* implement {@link ExecutorService}, which is a more extensive
* interface. The {@link ThreadPoolExecutor} class provides an
* extensible thread pool implementation. The {@link Executors} class
* provides convenient factory methods for these Executors.
*
* <p>Memory consistency effects: Actions in a thread prior to
* submitting a {@code Runnable} object to an {@code Executor}
* <a href="package-summary.html#MemoryVisibility"><i>happen-before</i></a>
* its execution begins, perhaps in another thread.
*
* @since 1.5
* @author Doug Lea
*/
public interface Executor {
/**
* Executes the given command at some time in the future. The command
* may execute in a new thread, in a pooled thread, or in the calling
* thread, at the discretion of the {@code Executor} implementation.
*
* @param command the runnable task
* @throws RejectedExecutionException if this task cannot be
* accepted for execution
* @throws NullPointerException if command is null
*/
void execute(Runnable command);
}
Java里面线程池的顶层接口是Executor，Executor是执行线程任务的工具！
Executors、ExecutorService、ThreadPoolExecutor三者区别
ExecutorService 继承了Executor提供更多控制线程、任务的方法！而Executor仅有execute方法接收一个Runnable接口的对象，不返回任何结果！
ExecutorService、Executor二者皆为接口，ExecutorService是Executor的子接口。
Executors 类， 是一个工具类，通常不适用！可根据用户需求，创建不同的线程池，来满足业务的需求。
Executors工具类实现线程池的底层实现是使用 new ThreadPoolExecutor去创建线程池的！
线程池具有5种状态
五种状态的流转
阿里巴巴：不建议使用工具类创建线程池！！！
了解更多多线程知识
以下来自https://mp.weixin.qq.com/s/caiVVZwU883WjuYwO9jfng
线程数和CPU利用率的小测试
抛开一些操作系统，计算机原理不谈，说一个基本的理论（不用纠结是否严谨，只为好理解）：一个CPU核心，单位时间内只能执行一个线程的指令 那么理论上，我一个线程只需要不停的执行指令，就可以跑满一个核心的利用率。
来写个死循环空跑的例子验证一下：
测试环境：AMD Ryzen 5 3600, 6 - Core, 12 - Threads
public class CPUUtilizationTest {
public static void main(String[] args) {
//死循环，什么都不做
while (true){
}
}
}
运行这个例子后，来看看现在CPU的利用率：
从图上可以看到，我的3号核心利用率已经被跑满了
那基于上面的理论，我多开几个线程试试呢？
public class CPUUtilizationTest {
public static void main(String[] args) {
for (int j = 0; j < 6; j++) {
new Thread(new Runnable() {
@Override
public void run() {
while (true){
}
}
}).start();
}
}
}
此时再看CPU利用率，1/2/5/7/9/11 几个核心的利用率已经被跑满：
那如果开12个线程呢，是不是会把所有核心的利用率都跑满？答案一定是会的：
如果此时我把上面例子的线程数继续增加到24个线程，会出现什么结果呢？
从上图可以看到，CPU利用率和上一步一样，还是所有核心100%，不过此时负载已经从11.x增加到了22.x（load average解释参考scoutapm.com/blog/unders…），说明此时CPU更繁忙，线程的任务无法及时执行。
现代CPU基本都是多核心的，比如我这里测试用的AMD 3600，6核心12线程（超线程），我们可以简单的认为它就是12核心CPU。那么我这个CPU就可以同时做12件事，互不打扰。
如果要执行的线程大于核心数，那么就需要通过操作系统的调度了。操作系统给每个线程分配CPU时间片资源，然后不停的切换，从而实现“并行”执行的效果。
但是这样真的更快吗？从上面的例子可以看出，一个线程就可以把一个核心的利用率跑满。如果每个线程都很“霸道”，不停的执行指令，不给CPU空闲的时间，并且同时执行的线程数大于CPU的核心数，就会导致操作系统更频繁的执行切换线程执行，以确保每个线程都可以得到执行。
不过切换是有代价的，每次切换会伴随着寄存器数据更新，内存页表更新等操作。虽然一次切换的代价和I/O操作比起来微不足道，但如果线程过多，线程切换的过于频繁，甚至在单位时间内切换的耗时已经大于程序执行的时间，就会导致CPU资源过多的浪费在上下文切换上，而不是在执行程序，得不偿失。
上面死循环空跑的例子，有点过于极端了，正常情况下不太可能有这种程序。
大多程序在运行时都会有一些 I/O操作，可能是读写文件，网络收发报文等，这些 I/O 操作在进行时时需要等待反馈的。比如网络读写时，需要等待报文发送或者接收到，在这个等待过程中，线程是等待状态，CPU没有工作。此时操作系统就会调度CPU去执行其他线程的指令，这样就完美利用了CPU这段空闲期，提高了CPU的利用率。
上面的例子中，程序不停的循环什么都不做，CPU要不停的执行指令，几乎没有啥空闲的时间。如果插入一段I/O操作呢，I/O 操作期间 CPU是空闲状态，CPU的利用率会怎么样呢？先看看单线程下的结果：
public class CPUUtilizationTest {
public static void main(String[] args) throws InterruptedException {
for (int n = 0; n < 1; n++) {
new Thread(new Runnable() {
@Override
public void run() {
while (true){
//每次空循环 1亿 次后，sleep 50ms，模拟 I/O等待、切换
for (int i = 0; i < 100_000_000l; i++) {
}
try {
Thread.sleep(50);
}
catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
}
}
哇，唯一有利用率的9号核心，利用率也才50%，和前面没有sleep的100%相比，已经低了一半了。现在把线程数调整到12个看看：
单个核心的利用率60左右，和刚才的单线程结果差距不大，还没有把CPU利用率跑满，现在将线程数增加到18：
此时单核心利用率，已经接近100%了。由此可见，当线程中有 I/O 等操作不占用CPU资源时，操作系统可以调度CPU可以同时执行更多的线程。
现在将I/O事件的频率调高看看呢，把循环次数减到一半，50_000_000，同样是18个线程：
此时每个核心的利用率，大概只有70%左右了。
线程数和CPU利用率的小总结
上面的例子，只是辅助，为了更好的理解线程数/程序行为/CPU状态的关系，来简单总结一下：
-
一个极端的线程（不停执行“计算”型操作时），就可以把单个核心的利用率跑满，多核心CPU最多只能同时执行等于核心数的“极端”线程数
-
如果每个线程都这么“极端”，且同时执行的线程数超过核心数，会导致不必要的切换，造成负载过高，只会让执行更慢
-
I/O 等暂停类操作时，CPU处于空闲状态，操作系统调度CPU执行其他线程，可以提高CPU利用率，同时执行更多的线程
-
I/O 事件的频率频率越高，或者等待/暂停时间越长，CPU的空闲时间也就更长，利用率越低，操作系统可以调度CPU执行更多的线程
线程数规划的公式
前面的铺垫，都是为了帮助理解，现在来看看书本上的定义。《Java 并发编程实战》介绍了一个线程数计算的公式：
Ncpu=CPU核心数Ncpu=CPU 核心数Ncpu=CPU核心数
Ucpu=目标CPU利用率，0<=Ucpu<=1Ucpu=目标CPU利用率，0<=Ucpu<=1Ucpu=目标CPU利用率，0<=Ucpu<=1
WC=等待时间和计算时间的比例\frac{W}{C}=等待时间和计算时间的比例CW=等待时间和计算时间的比例
如果希望程序跑到CPU的目标利用率，需要的线程数公式为：
Nthreads=Ncpu∗Ucpu∗(1+WC)Nthreads=NcpuUcpu(1+\frac{W}{C})Nthreads=Ncpu∗Ucpu∗(1+CW)
公式很清晰，现在来带入上面的例子试试看：
如果我期望目标利用率为90%（多核90），那么需要的线程数为：
核心数12 * 利用率0.9 * (1 + 50(sleep时间)/50(循环50_000_000耗时)) ≈ 22
现在把线程数调到22，看看结果：
现在CPU利用率大概80+，和预期比较接近了，由于线程数过多，还有些上下文切换的开销，再加上测试用例不够严谨，所以实际利用率低一些也正常。
把公式变个形，还可以通过线程数来计算CPU利用率：
Ucpu=NthreadsNcpu∗(1+WC)Ucpu=\frac{Nthreads}{Ncpu*(1+\frac{W}{C})}Ucpu=Ncpu∗(1+CW)Nthreads
线程数22 / (核心数12 * (1 + 50(sleep时间)/50(循环50_000_000耗时))) ≈ 0.9
虽然公式很好，但在真实的程序中，一般很难获得准确的等待时间和计算时间，因为程序很复杂，不只是“计算”。一段代码中会有很多的内存读写，计算，I/O 等复合操作，精确的获取这两个指标很难，所以光靠公式计算线程数过于理想化。
真实程序中的线程数
那么在实际的程序中，或者说一些Java的业务系统中，线程数（线程池大小）规划多少合适呢？
先说结论：没有固定答案，先设定预期，比如我期望的CPU利用率在多少，负载在多少，GC频率多少之类的指标后，再通过测试不断的调整到一个合理的线程数
比如一个普通的，SpringBoot 为基础的业务系统，默认Tomcat容器+HikariCP连接池+G1回收器，如果此时项目中也需要一个业务场景的多线程（或者线程池）来异步/并行执行业务流程。
此时我按照上面的公式来规划线程数的话，误差一定会很大。因为此时这台主机上，已经有很多运行中的线程了，Tomcat有自己的线程池，HikariCP也有自己的后台线程，JVM也有一些编译的线程，连G1都有自己的后台线程。这些线程也是运行在当前进程、当前主机上的，也会占用CPU的资源。
所以受环境干扰下，单靠公式很难准确的规划线程数，一定要通过测试来验证。
流程一般是这样：
-
分析当前主机上，有没有其他进程干扰
-
分析当前JVM进程上，有没有其他运行中或可能运行的线程
-
设定目标
-
目标CPU利用率 - 我最高能容忍我的CPU飙到多少？
-
目标GC频率/暂停时间 - 多线程执行后，GC频率会增高，最大能容忍到什么频率，每次暂停时间多少？
-
执行效率 - 比如批处理时，我单位时间内要开多少线程才能及时处理完毕
-
……
-
-
梳理链路关键点，是否有卡脖子的点，因为如果线程数过多，链路上某些节点资源有限可能会导致大量的线程在等待资源（比如三方接口限流，连接池数量有限，中间件压力过大无法支撑等）
-
不断的增加/减少线程数来测试，按最高的要求去测试，最终获得一个“满足要求”的线程数**
而且而且而且！不同场景下的线程数理念也有所不同：
-
Tomcat中的maxThreads，在Blocking I/O和No-Blocking I/O下就不一样
-
Dubbo 默认还是单连接呢，也有I/O线程（池）和业务线程（池）的区分，I/O线程一般不是瓶颈，所以不必太多，但业务线程很容易称为瓶颈
-
Redis 6.0以后也是多线程了，不过它只是I/O 多线程，“业务”处理还是单线程
所以，不要纠结设置多少线程了。没有标准答案，一定要结合场景，带着目标，通过测试去找到一个最合适的线程数。
可能还有同学可能会有疑问：“我们系统也没啥压力，不需要那么合适的线程数，只是一个简单的异步场景，不影响系统其他功能就可以”
很正常，很多的内部业务系统，并不需要啥性能，稳定好用符合需求就可以了。那么我的推荐的线程数是：CPU核心数
附录
Java 获取CPU核心数
Runtime.getRuntime().availableProcessors()//获取逻辑核心数，如6核心12线程，那么返回的是12
Linux 获取CPU核心数
# 总核数 = 物理CPU个数 X 每颗物理CPU的核数
# 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数
# 查看物理CPU个数
cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l
# 查看每个物理CPU中core的个数(即核数)
cat /proc/cpuinfo| grep "cpu cores"| uniq
# 查看逻辑CPU的个数
cat /proc/cpuinfo| grep "processor"| wc -l
554
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
