英协网
在Java并发编程方面，计算密集型与IO密集型是两个非常典型的例子，这次大象就来讲讲自己在这方面的内容，本篇比较基础，只适合刚入门的童鞋，请各种牛人不喜勿喷。
计算密集型
计算密集型，顾名思义就是应用需要非常多的CPU计算资源，在多核CPU时代，我们要让每一个CPU核心都参与计算，将CPU的性能充分利用起来，这样才算是没有浪费服务器配置，如果在非常好的服务器配置上还运行着单线程程序那将是多么重大的浪费。对于计算密集型的应用，完全是靠CPU的核数来工作，所以为了让它的优势完全发挥出来，避免过多的线程上下文切换，比较理想方案是：
线程数 = CPU核数+1
也可以设置成CPU核数*2，这还是要看JDK的使用版本，以及CPU配置(服务器的CPU有超线程)。对于JDK1.8来说，里面增加了一个并行计算，计算密集型的较理想线程数 = CPU内核线程数*2
计算文件夹大小算是一个比较典型的例子，代码很简单，我就不多解释了。
执行10次后结果如下：
在上面的例子中，线程池设置为CPU核心数+1个，这个运行结果是大象在工作电脑(CPU：G630 内存：4G JDK1.7.0_51)上跑出来的。如果在这里把线程池加大，比如调到100，你会发现所用时间变多了，大象这里最多的消耗时间是0.297秒，与之前最少的一次0.218之间相差0.079秒，也即79毫秒。当然这多出来的时间在我们看来好像不算什么，只有零点零几秒，但是对于CPU来说可是相当长的，因为CPU里面是以纳秒为计算单位，1毫秒=1000000纳秒。所以加大线程池会增加CPU上下文的切换成本，有时程序的优化就是从这些微小的地方积累起来的。
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))
本篇大象简单谈了下并发类型，旨在抛砖引玉，让初学并发编程的朋友能够有一些了解，说的不对的地方，还请各位指出来。
