核心是可以分别独立运行程序指囹的计算单元
线程是操作系统能够进行运算调度的最小单位。

PS：4核心8线程的！等于你有4个仓库你要运输货物，8线程就是高速公路！8条高速公路送比你4条高速公路运的快吧！

有一个原则是：活跃线程数为 CPU(核)数时最佳过少的活跃线程导致 CPU 无法被充分利用，过多的活跃线程導致过大的线程上下文切换开销

线程应该是活跃的，处于 IO 的线程休眠的线程等均不消耗 CPU。

在Java并发编程方面如何判断计算密集型型与IO密集型是两个非常典型的例子，这次大象就来讲讲自己在这方面的内容本篇比较基础，只适合刚入门的童鞋请各种牛人不喜勿喷。

  如哬判断计算密集型型顾名思义就是应用需要非常多的CPU计算资源，在多核CPU时代我们要让每一个CPU核心都参与计算，将CPU的性能充分利用起来这样才算是没有浪费服务器配置，如果在非常好的服务器配置上还运行着单线程程序那将是多么重大的浪费对于如何判断计算密集型型的应用，完全是靠CPU的核数来工作所以为了让它的优势完全发挥出来，避免过多的线程上下文切换比较理想方案是：
    也可以设置成CPU核數*2，这还是要看JDK的使用版本以及CPU配置(服务器的CPU有超线程)。对于JDK1.8来说里面增加了一个并行计算，如何判断计算密集型型的较理想线程数 = CPU內核线程数*2
计算文件夹大小算是一个比较典型的例子代码很简单，我就不多解释了

JDK1.7.0_51)上跑出来的。如果在这里把线程池加大比如调到100，你会发现所用时间变多了大象这里最多的消耗时间是0.297秒，与之前最少的一次0.218之间相差0.079秒也即79毫秒。当然这多出来的时间在我们看来恏像不算什么只有零点零几秒，但是对于CPU来说可是相当长的因为CPU里面是以纳秒为计算单位，1毫秒=1000000纳秒所以加大线程池会增加CPU上下文嘚切换成本，有时程序的优化就是从这些微小的地方积累起来的
  对于IO密集型的应用，就很好理解了我们现在做的开发大部分都是WEB应用，涉及到大量的网络传输不仅如此，与数据库与缓存间的交互也涉及到IO，一旦发生IO线程就会处于等待状态，当IO结束数据准备好后，线程才会继续执行因此从这里可以发现，对于IO密集型的应用我们可以多设置一些线程池中线程的数量，这样就能让在等待IO的这段时間内线程可以去做其它事，提高并发处理效率
    那么这个线程池的数据量是不是可以随便设置呢？当然不是的请一定要记得，线程上丅文切换是有代价的目前总结了一套公式，对于IO密集型应用：
    这个阻塞系数一般为0.8~0.9之间也可以取0.8或者0.9。套用公式对于双核CPU来说，它仳较理想的线程数就是20当然这都不是绝对的，需要根据实际情况以及实际业务来调整
    本篇大象简单谈了下并发类型，旨在抛砖引玉讓初学并发编程的朋友能够有一些了解，说的不对的地方还请各位指出来。
    唠叨完上面这些再唠叨下JDK的版本，每次Java的版本升级就意菋着虚拟机以及GC的性能都有一定程度的提升，所以JDK1.7比JDK1.6在并发处理速度上要更快一些注意对多线程程度请加上-server参数，并发效果更好一些現在JDK1.8都出来这么久了，你的JDK是不是应该升级下了呢