本文主要是介绍CPU io-密集型 计算密集型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
核心是可以分别独立运行程序指令的计算单元。
线程是操作系统能够进行运算调度的最小单位。
有一个原则是：活跃线程数为 CPU(核)数时最佳。过少的活跃线程导致 CPU 无法被充分利用，过多的活跃线程导致过大的线程上下文切换开销。
线程应该是活跃的，处于 IO 的线程，休眠的线程等均不消耗 CPU。
在Java并发编程方面，计算密集型与IO密集型是两个非常典型的例子，这次大象就来讲讲自己在这方面的内容，本篇比较基础，只适合刚入门的童鞋，请各种牛人不喜勿喷。
计算密集型
计算密集型，顾名思义就是应用需要非常多的CPU计算资源，在多核CPU时代，我们要让每一个CPU核心都参与计算，将CPU的性能充分利用起来，这样才算是没有浪费服务器配置，如果在非常好的服务器配置上还运行着单线程程序那将是多么重大的浪费。对于计算密集型的应用，完全是靠CPU的核数来工作，所以为了让它的优势完全发挥出来，避免过多的线程上下文切换，比较理想方案是：
线程数 = CPU核数+1
也可以设置成CPU核数*2，这还是要看JDK的使用版本，以及CPU配置(服务器的CPU有超线程)。对于JDK1.8来说，里面增加了一个并行计算，计算密集型的较理想线程数 = CPU内核线程数*2
IO密集型
对于IO密集型的应用，就很好理解了，我们现在做的开发大部分都是WEB应用，涉及到大量的网络传输，不仅如此，与数据库，与缓存间的交互也涉及到IO，一旦发生IO，线程就会处于等待状态，当IO结束，数据准备好后，线程才会继续执行。因此从这里可以发现，对于IO密集型的应用，我们可以多设置一些线程池中线程的数量，这样就能让在等待IO的这段时间内，线程可以去做其它事，提高并发处理效率。
那么这个线程池的数据量是不是可以随便设置呢？当然不是的，请一定要记得，线程上下文切换是有代价的。目前总结了一套公式，对于IO密集型应用：
线程数 = CPU核心数/(1-阻塞系数)
这个阻塞系数一般为0.8~0.9之间，也可以取0.8或者0.9。套用公式，对于双核CPU来说，它比较理想的线程数就是20，当然这都不是绝对的，需要根据实际情况以及实际业务来调整。
final int poolSize = (int)(cpuCore/(1-0.9))
根据任务所需要的cpu和io资源的量可以分为
- CPU密集型任务: 主要是执行计算任务，响应时间很快，cpu一直在运行，这种任务cpu的利用率很高
- IO密集型任务：主要是进行IO操作，执行IO操作的时间较长，这是cpu出于空闲状态，导致cpu的利用率不高
为了合理最大限度的使用系统资源同时也要保证的程序的高性能，可以给CPU密集型任务和IO密集型任务配置一些线程数。
CPU密集型：线程个数为CPU核数。这几个线程可以并行执行，不存在线程切换到开销，提高了cpu的利用率的同时也减少了切换线程导致的性能损耗
IO密集型：线程个数为CPU核数的两倍。到其中的线程在IO操作的时候，其他线程可以继续用cpu，提高了cpu的利用率 。
有一个原则是：活跃线程数为 CPU(核)数时最佳。过少的活跃线程导致 CPU 无法被充分利用，过多的活跃线程导致过大的线程上下文切换开销。
常见的服务线程模型
1、IO线程与工作现场通过任务队列解耦
X:执行计算，占用CPU时间
Y：执行IO等待不占用CPU时间
工作线程池的个数：N*(1+y/x)
2、纯异步
2017-07-31 17:05:47
并发用户数：是指现实系统中操作业务的用户，在性能测试工具中，一般称为虚拟用户数(Virutal User)。
并发用户数和注册用户数、在线用户数的概念不同，
1、并发用户数一定会对服务器产生压力的，
2、而在线用户数只是 ”挂” 在系统上，对服务器不产生压力，
3、注册用户数一般指的是数据库中存在的用户数。
TPS：Transaction Per Second, 每秒事务数, 是衡量系统性能的一个非常重要的指标。
TPS就是每秒事务数，但是事务是基于虚拟用户数的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS明显就是1；如果 某笔业务响应时间是1ms,那么1个用户在1秒内能完成1000笔事务，TPS就是1000了；如果某笔业务响应时间是1s,那么1个用户在1秒内只能完 成1笔事务，要想达到1000TPS，至少需要1000个用户；因此可以说1个用户可以产生1000TPS，1000个用户也可以产生1000TPS，无非是看响应时间快慢。
也就是说，在评定服务器的性能时，应该结合TPS和并发用户数，以TPS为主，并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量的 话，需要一个前提，那就是交易在多长时间内完成，因为在系统负载不高的情况下，将思考时间(思考时间的值等于交易响应时间)加到脚本中，并发用户数基本可 以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。
在性能测试时并不需要用上万的用户并发去进行测试，如果只需要保证系统处理业务时间足够快，几百个用户甚至几十个用户就可 以达到目的。据他了解，很多专家做过的性能测试项目基本都没有超过5000用户并发。因此对于大型系统、业务量非常高、硬件配置足够多的情况下，5000 用户并发就足够了；对于中小型系统，1000用户并发就足够了。
系统吞吐量几个重要参数：TPS、并发数、响应时间
TPS：每秒钟事务数量
并发数： 系统同时处理的事务数
响应时间：一般取平均响应时间
TPS=并发用户数 / (响应时间+Thinktime)
并发用户如何计算
一、经典公式1：
一般来说，利用以下经验公式进行估算系统的平均并发用户数和峰值数据
1）平均并发用户数为 C = nL/T
2）并发用户数峰值 C‘ = C + 3*根号C
C是平均并发用户数，n是login session的数量，L是login session的平均长度，T是值考察的时间长度
C’是并发用户数峰值
举例1，假设系统A，该系统有3000个用户，平均每天大概有400个用户要访问该系统（可以从系统日志从获得），对于一个典型用户来说，一天之内用户从登陆到退出的平均时间为4小时，而在一天之内，用户只有在8小时之内会使用该系统。
那么，
平均并发用户数为：C = 400*4/8 = 200
并发用户数峰值为：C‘ = 200 + 3*根号200 = 243
举例2， 某公司为其170000名员工设计了一个薪酬系统，员工可进入该系统查询自己的薪酬信息，但并不是每个人都会用这个系统，假设只有50%的人会定期用改系统，这些人里面有70%是在每个月的最后一周使用一次该系统，且平均使用系统时间为5分钟。
则一个月最后一周的平均并发用户数为（朝九晚五）：
n = 170000*0.5*0.7/5 = 11900
C= 11900*5/60/8 = 124
吞吐量计算为：F = Vu * R / T 单位为个/s
F为事务吞吐量，Vu为虚拟用户数个数，R为每个虚拟用户发出的请求数，T为处理这些请求所花费的时间
二、通用公式2：
对绝大多数场景，我们用（用户总量/统计时间）*影响因子（一般为3）来进行估算并发量。
比如，以乘坐地铁为例子，每天乘坐人数为5万人次，每天早高峰是7到9点，晚高峰是6到7点，根据8/2原则，80%的乘客会在高峰期间乘坐地铁，则每秒到达地铁检票口的人数为50000*80%/（3*60*60）=3.7，约4人/S，考虑到安检，入口关闭等因素，实际堆积在检票口的人数肯定比这个要大，假定每个人需要3秒才能进站，那实际并发应为4人/s*3s=12，当然影响因子可以根据实际情况增大！
三、根据PV计算公式：
比如一个网站，每天的PV大概1000w，根据2/8原则，我们可以认为这1000w pv的80%是在一天的9个小时内完成的（人的精力有限），那么TPS为：
1000w*80%/(9*3600)=246.92个/s,取经验因子3，则并发量应为：
246.92*3=740
四、根据TPS估计：
公式为 C = (Think time + 1)*TPS
五、根据系统用户数计算：
并发用户数 = 系统最大在线用户数的8%到12%
这篇关于CPU io-密集型 计算密集型的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
