1.1.1.多线程的发展--对cpu性能的压榨史

一.压榨历史

1.单进程人工切换。纸带机。只能解决简单的数学问题。

2.单道批处理。多进程批处理。多个任务批量执行。解决手动操作时需要人工切换作业导致的系统利用率低的问题

3.多进程并行处理。把程序写在不同的内存位置来回切换。当一个作业在等待I/O处理时，多批处理系统会通过相应调度算法调度另外一个作业让计算机执行

4.多线程。一个程序内部不同任务的来回切换。实现进程中任务的切换，又可以避免进程切换内存地址空间(将计算机实际调度的单元转到线程)。

5.纤程/协程与管程

二.相关含义介绍

什么是程序？什么是进程？什么是进程？什么是纤程/协程、管程？

1.程序-->抽象概念

操作系统可以执行的一个计算机文件。是一组计算机能识别和执行的指令序列。如QQ.exe

2.进程-->静态概念

进程是程序计算机(内存)中的一次运行活动。更通俗一点来说：进程是程序的实例化(类似于程序是class，进程是class的对象)。

进程是系统进行资源分配的基本单位，进程是线程的容器。

3.线程-->动态概念

一条线程指的是进程中一个单一顺序的执行路线（也可以说是执行流、控制流）。即进程中的实际运行单位。

资源调度的基本单位。

4.线程上下文

线程上下文是指某一时间点 CPU 寄存器和程序计数器的内容。

4.1.使用场景

上下文切换 (context switch) 。即任务切换, 或者CPU寄存器切换。

当多任务内核决定运行另外的任务时, 它保存正在运行任务的当前状态, 也就是CPU寄存器中的全部内容。这些内容被保存在任务自己的堆栈中, 入栈工作完成后就把下一个将要运行的任务的当前状况从该任务的栈中重新装入CPU寄存器, 并开始下一个任务的运行, 这一过程就是context switch。

4.2.上下文切换带来的问题

程序执行效率与线程并发数，从正相关变为负相关；

三.思考问题

1.单核的CPU设定多线程是否有意义？

其实个人的观点是，需要分析多线程的本质-->是对cpu性能的压榨。

那么，如果说单线程已经达到非常好的cpu利用率，则使用多线程意义不是太大。这种作业就称为cpu密集型（性能瓶颈是CPU运算）。

相对的，将性能瓶颈是IO（网络通信、硬盘读写、阻塞等待等）的作业称为io密集型。因为这种作业会造成cpu空闲，而使用多线程可显著减少此情况。

2.工作线程数是不是设置得越大越好？

a.先看一个示例：

package com.pavin.thread;
​
import java.text.DecimalFormat;
import java.util.Random;
import java.util.concurrent.CountDownLatch;
​
public class multiThread_01 {
​
    private static double[] nums = new double[1_0000_0000];
    private static Random r = new Random();
    private static DecimalFormat df = new DecimalFormat("0.00");
    static {
        for (int j = 0; j < nums.length; j++) {
            nums[j] = r.nextDouble();
        }
    }
​
    private static void singleThread() {
        long start = System.currentTimeMillis();
​
        double result = 0.0;
        for (int j = 0; j < nums.length; j++) {
            result += nums[j];
        }
​
        long end = System.currentTimeMillis();
        System.out.println("1   " + " singleThread: cost " + (end-start) + "ms result: " + df.format(result));
    }
​
    static double result1 = 0.0, result2 = 0.0, result3 = 0.0;
    private static void twoThreads() throws InterruptedException {
​
        Thread t1 = new Thread(() -> {
            for (int j = 0; j < nums.length / 2; j++) {
                result1 += nums[j];
            }
        });
​
        Thread t2 = new Thread(() -> {
            for (int j = nums.length / 2; j < nums.length; j++) {
                result2 += nums[j];
            }
        });
​
        long start = System.currentTimeMillis();
        t1.start();
        t2.start();
        t1.join();
        t2.join();
​
        result3 = result1 + result2;
        long end = System.currentTimeMillis();
        System.out.println("2   " + " Threads: cost " + (end-start) + "ms result: " + df.format(result3));
    }
​
    private static void multiThreads(int threadCount) throws InterruptedException {
​
        Thread[] threads = new Thread[threadCount];
        double[] results = new double[threadCount];
        final int segmentCount = nums.length / threadCount;
        CountDownLatch latch = new CountDownLatch(threadCount);
​
        for (int i = 0; i < threadCount; i++) {
            int m = i;
​
            threads[i] = new Thread(() -> {
                for (int j = m * segmentCount; j < (m+1) * segmentCount && j < nums.length; j++) {
                    results[m] += nums[j];
                }
            });
​
            latch.countDown();
        }
​
        double result = 0.0;
        long start = System.currentTimeMillis();
        for (Thread t : threads) {
            t.start();
        }
​
        latch.await();
        for (double v : results) {
            result += v;
        }
​
        long end = System.currentTimeMillis();
        System.out.println(threadCount + " Threads: cost " + (end-start) + "ms result: " + df.format(result));
    }
​
    public static void main(String[] args) throws InterruptedException {
        singleThread();
        twoThreads();
​
        multiThreads(10000);
    }
}

输出结果：

1    singleThread: cost 134ms result: 49997084.08
2    Threads: cost 78ms result: 49997084.08
10000 Threads: cost 1012ms result: 49997084.08

由此可见，使用两个线程时明显比一个线程更快，但是使用10000个线程时，非常慢。所以线程并不是越大越好。

b.造成效率下降的原因

见线程上下文

3.工作线程数（线程池中的线程数量）设置为多少合适？

公式+压测

a.公式

CPU密集型：理论上线程的数量=CPU核数最合适。

不过实际中一般会设为CPU核数+1。此时当线程因为偶尔的内存页失效或其他原因导致阻塞时，这个额外的线程可以顶上，从而保证CPU的利用率

IO密集型 ：线程数 = CPU核心数 * 目标CPU利用率 *（1+平均等待时间/平均工作时间）

b.实际中的问题

i.环境开销

比如一个普通的SpringBoot 为基础的业务系统，默认Tomcat容器+HikariCP连接池+G1回收器。

Tomcat有自己的线程池，HikariCP也有自己的后台线程，JVM也有一些编译的线程，连G1都有自己的后台线程。这些线程也是运行在当前进程、当前主机上的，也会占用CPU的资源。

ii.测算"平均等待时间"、“平均工作时间”

方法1，通过日志和统计的方式得出。

方法2，第三方工具：profiler/Jprofiler

c.实际策略

一般情况下，内部业务系统相对于性能，更注重稳定好用、符合需求。实际生产推荐的线程数：CPU核心数+1