线程数

进程-线程-多线程-异步 一、多线程的本质 1、并发多线程的启动、结束顺序 a、如何控制多线程的调用顺序 b、阻塞主线程等待子线程 二、异步操作的本质 三、线程 1、Thread 2、ThreadPool 3、Task 4、TaskFactory 5、Parallel 6、async await 语法糖 四、异常处理 五、线程取消 六、线程安全 一、多线程的本质 cpu的计算速度太快了导致硬件跟不上，就是木桶原理（盛水多少取决于最短板）。 cpu的计算能力很强，所以cpu可以分“时间片”，一个cpu可以分N+个时间片，每个时间片上跑一个线程（代码流）。cpu按顺序执行时间片，因为cpu太强，线程切换的太快，导致人感觉不出执行的卡顿，感觉上是多线程并发的。 微观角度：一个核同一时刻只能执行一个线程； 宏观角度： 是多线程并发的。 cpu分时间片执行线程，线程所需资源的不同会导致有 上下文的切换 ，其实上下文的切换会有性能的损失，但因为cpu计算能力超过其它硬件太多，不损失也是浪费。 扩展：4核8线程—核是物理的核，这里的线程是指虚拟核（一个核虚拟出2个核）。 1、并发多线程的启动、结束顺序 并发线程的启动是无序。 执行相同代码的并发线程的运行时间也不相同，所以结束时间也不同。 a、如何控制多线程的调用顺序 可以用委托提供的BeginInvoke方法，它是异步线程方法，并支持回调函数

一、setup thread group和teardown thread group 对于setup thread group 和 teardown thread group 来说，从字面意思上来看就是安装线程组和卸载线程组，所以可以理解为对于线程组的初始化和完成时处理，set thread group是所有我们真正开始线程并发之前的准备工作，必须是在线程组开始之前完成的并且拥有自己独立的线程设置 setUp Thread Group & tearDown Thread Group： 继续：如果取样器里的执行出现错误失败的时候，请求不会停止，继续执行。 Start Next Thread Loop : 忽略错误，线程当前循环错误，执行下一个循环。 停止线程 ： 只限当前线程停止，不影响其他线程执行 停止测试 ： 当前执行的线程全部执行完毕后结束 Stop Test Now： 立刻停止 6、线程数=10（设置线程数），Ramp-Up Period(in seconds)=5（设置过渡时期）,循环次数=2（设置执行测试的次数） 也就是说： 一共10个线程数，每1S执行2个线程数2个循环，也就是1S并发4个请求 二、线程组 每个线程将完全独立的执行测试计划，完全独立于其他测试线程，多个线程用于模拟与服务器应用程序的并发连接 这个过渡时期告诉JMeter要花多长时间才能“加速

对于cpu，目前比较关心的是cpu的利用率还有cpu的load，或者还有cpu运行队列。 cpu利用率 cpu利用率分为sys，us。分别为操作系统和用户进程所占用的cpu利用率。sys的占用，一般是进行内核操作，比如线程的调度，网络请求等操作。cpu利用率是指一段时间内，对cpu占用的时间比。比如30% ，如果是已1m为单位统计的，就是说1m内有60*0.3s的cpu占用。 通常来说，cpu利用率是越高越好，因为这意味着cpu资源可以充分被利用，计算任务可以快速被计算完成。当然这不是绝对的，也有可能是程序有问题，在空吃cpu，所以还是需要具体分析cpu到底在执行什么任务。放在线上服务的场景下，也并不意味着我们要把cpu的利用率达到很高，因为这意味着空闲cpu资源很少，如果线上有大的请求波动的话，会造成故障。 cpu的空闲可能有三个原因造成： 1. 线程在等待外部资源，比如网络返回。 2.线程被阻塞，比如在等锁的释放等。 3.线程真的很闲 查看cpu利用率方法：top , vmstat 1， top -p pid -H （可以查看一个进程下的线程的cpu占用） cpu Load cpuLoad是指一段时间内，cpu正在处理和等待处理的任务的总和（我认为至少不是进程维度的）。 一般来说，cpu的load不宜过大，最大不应该操作系统的内核数（逻辑cpu数， 逻辑cpu数=物理CPU个数

公司有位大佬写下这么一段话 ①，FixedThreadPool任务队列的无边界会导致内存溢出以及高延迟 ②，CachedThreadPool线程数的无边界会导致并发高的时候创建的线程数不可控 建议因为两者都不是特别友好，所以推荐直接使用ThreadPoolExecutor，它提供了很多参数可以进行细粒度的控制， 然后我就找了个机会了解下，这是怎么回事 查看ThreadPoolExecutor#execute 方法 简介说，这可能启动新的线程或原有线程开启任务或拒绝任务，代码如下 public void execute(Runnable command) { if (command == null) throw new NullPointerException(); int c = ctl.get(); //如何工作的线程数小于核心线程数 if (workerCountOf(c) < corePoolSize) { if (addWorker(command, true))//新起一个线程并添加到工作队列,然后return return; c = ctl.get(); } //workQueue.offer将任务添加到工作队列中 if (isRunning(c) && workQueue.offer(command)) { int recheck = ctl.get(); if (!

一、线程池的创建和常用参数分析 先看一个线程池的创建 private static void testThreadPool ( ) { ExecutorService executorService = Executors . newFixedThreadPool ( 1 ) ; Future < ? > future = executorService . submit ( ( ) - > { System . out . println ( Thread . currentThread ( ) . getName ( ) + " running" ) ; } ) ; } 翻看newFixedThreadPool()的源码可以看到最终执行的时候有以下几个参数： public ThreadPoolExecutor ( int corePoolSize , int maximumPoolSize , long keepAliveTime , TimeUnit unit , BlockingQueue < Runnable > workQueue , ThreadFactory threadFactory , RejectedExecutionHandler handler ) { . . . } a) corePoolSize 核心线程数，保持在线程池中线程的数量 b)

本系列文章索引 《响应式Spring的道法术器》 前情提要 Spring WebFlux快速上手 | Spring WebFlux性能测试 | Spring WebClient性能测试 本文 源码 1.4.4 同步与异步数据库驱动的性能对比 许多数据库已陆续推出官方的异步驱动，在Spring Data Reactive中，已经集成了Mongo、Casandra、Redis、CouchDB的异步驱动。 在Spring WebFlux中使用 Reactive Mongo的示例见 Spring WebFlux快速上手 。 这一节我们通过使用YSCB对MongoDB的同步和异步驱动的性能基准测试，来观察异步驱动的优势。 YCSB（Yahoo! Cloud Serving Benchmark） 是雅虎开源的一款用于测试各类云服务/NoSQL/键值对存储的性能基准测试工具。YCSB很赞，使用起来很简单，我们就按照wiki介绍来操作即可。 1）准备YCSB 如果使用Windows，请参考 这里 来预先安装必要的软件和工具。 获取YCSB有两种方式，一种是直接下载压缩包： curl -O --location https://github.com/brianfrankcooper/YCSB/releases/download/0.12.0/ycsb-0.12.0.tar.gz tar xfvz

ThreadPoolExecutor public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) 一、ThreadPoolExecutor的重要参数 1、corePoolSize：核心线程数 * 核心线程会一直存活，及时没有任务需要执行 * 当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理 * 设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭 2、queueCapacity：任务队列容量（阻塞队列） * 当核心线程数达到最大时，新任务会放在队列中排队等待执行 3、maxPoolSize：最大线程数 * 当线程数>=corePoolSize，且任务队列已满时。线程池会创建新线程来处理任务 * 当线程数=maxPoolSize，且任务队列已满时，线程池会拒绝处理任务而抛出异常 4、 keepAliveTime：线程空闲时间 * 当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize * 如果allowCoreThreadTimeout=true，则会直到线程数量=0

前言 在我们平时自己写线程的测试demo时，一般都是用new Thread的方式来创建线程。但是，我们知道创建线程对象，就会在内存中开辟空间，而线程中的任务执行完毕之后，就会销毁。 单个线程的话还好，如果线程的并发数量上来之后，就会频繁的创建和销毁对象。这样，势必会消耗大量的系统资源，进而影响执行效率。 所以，线程池就应运而生。 线程池ThreadPoolExecutor 可以通过idea先看下线程池的类图，了解一下它的继承关系和大概结构。 它继承自AbstractExecutorService类，这是一个抽象类，不过里边的方法都是已经实现好的。然后这个类实现了ExecutorService接口，里边声明了各种方法，包括关闭线程池，以及线程池是否已经终止等。此接口继承自父接口Executor，里边只声明了一个execute方法。 线程池就是为了解决单个线程频繁的创建和销毁带来的性能开销。同时，可以帮我们自动管理线程。并且不需要每次执行新任务都去创建新的线程，而是重复利用已有的线程，大大提高任务执行效率。 我们打开 ThreadPoolExecutor的源码，可以看到总共有四个构造函数。 但是，前三个最终都会调用到最后一个构造函数。我们来看下这个构造函数都有哪些参数。（其实，多看下参数的英文解释就能明白其中的含义，看来英语对程序员来说是真的重要呀） //核心构造函数 public

作者：范欣欣 本次测试主要评估线上HBase的整体性能，量化当前HBase的性能指标，对各种场景下HBase性能表现进行评估，为业务应用提供参考。本篇文章主要介绍此次测试的基本条件，HBase在各种测试场景下的性能指标（主要包括单次请求平均延迟和系统吞吐量）以及对应的资源利用情况，并对各种测试结果进行分析。 测试环境 测试环境包括测试过程中HBase集群的拓扑结构、以及需要用到的硬件和软件资源，硬件资源包括：测试机器配置、网络状态等等，软件资源包括操作系统、HBase相关软件以及测试工具等。 集群拓扑结构 本次测试中，测试环境总共包含4台SA5212H2物理机作为数据存储。生成数据的YCSB程序与数据库并不运行在相同的物理集群。 单台机器主机硬件配置 软件版本信息 测试工具 YCSB全称Yahoo! Cloud Serving Benchmark，是Yahoo公司开发的专门用于NoSQL测试的基准测试工具。github地址：https://github.com/brianfrankcooper/YCSB YCSB支持各种不同的数据分布方式 1. Uniform：等概论随机选择记录 2. Zipfian：随机选择记录，存在热记录 3. Latest：近期写入的记录为热记录 测试场景 YCSB为HBase提供了多种场景下的测试，本次测试中，我们导入10亿条数据，并对如下场景进行测试:

作者：范欣欣 本次测试主要评估线上HBase的整体性能，量化当前HBase的性能指标，对各种场景下HBase性能表现进行评估，为业务应用提供参考。本篇文章主要介绍此次测试的基本条件，HBase在各种测试场景下的性能指标（主要包括单次请求平均延迟和系统吞吐量）以及对应的资源利用情况，并对各种测试结果进行分析。 测试环境 测试环境包括测试过程中HBase集群的拓扑结构、以及需要用到的硬件和软件资源，硬件资源包括：测试机器配置、网络状态等等，软件资源包括操作系统、HBase相关软件以及测试工具等。 集群拓扑结构 本次测试中，测试环境总共包含4台SA5212H2物理机作为数据存储。生成数据的YCSB程序与数据库并不运行在相同的物理集群。 单台机器主机硬件配置 软件版本信息 测试工具 YCSB全称Yahoo! Cloud Serving Benchmark，是Yahoo公司开发的专门用于NoSQL测试的基准测试工具。github地址：https://github.com/brianfrankcooper/YCSB YCSB支持各种不同的数据分布方式 1. Uniform：等概论随机选择记录 2. Zipfian：随机选择记录，存在热记录 3. Latest：近期写入的记录为热记录 测试场景 YCSB为HBase提供了多种场景下的测试，本次测试中，我们导入10亿条数据，并对如下场景进行测试: