大家好，我是十年程序员架构师小A。
序言
Java Jdk中的线程池问题，小A出去面试被问过四五次（前些年理解也不透彻）。而我面试别人也问过几十次，完全答对的几乎没有，多数候选人只能答对一半。
所以，小A准备花4篇短文，把线程池以及池化技术讲透。
（不要担心，每一篇都很短、很简单）
上一篇 我面试别人问线程池，很少全答对。不难，4篇短文讲透（1）里：
我们讲了线程数的设置分两步，第一步区分IO还是CPU计算，第二步分别得出了两种超级简单的计算方式。
今天是“讲透线程池系列4篇文章”的第二篇：
IO、CPU密集型分别指什么，有哪些例子。
正文
第2篇，计算
宏观上先说两句首先，电脑（计算机）可以简单抽象为这么一种模式：
输入（键盘） -> 计算（CPU） -> 输出 (显示器)
输入和输出是IO的范畴，计算是CPU
其次，单机程序是由多个方法（函数）串并行组合而成，可以抽象为：
入参 -> 计算 -> 返回值
最后，分布式服务是由多个，单机服务（集群）串并行组合而成，服务间交互可抽象为：
网络请求（入参） -> 计算 -> 网络响应（返回值）
请求和响应是IO的范畴，计算是CPU
综上所述：
宏观上看，无论从硬件还是软件层面来看，它们都是由IO和计算（CPU）组成的，理解这两个概念不仅对线程池，对编程领域方方面面都是非常有用的。
当然，硬件和软件（程序、架构）层面的，IO和CPU的概念，比线程池技术涉及到的要更复杂一些，跟本文关系不大，不过多表示。不太理解，也没任何关系。
下面，回归正题，讲线程池技术讲业务逻辑分成的两类：IO密集型和CPU密集型。
IO密集型我们需要从三个角度来描述（CPU密集型刚好相反）
表现：我发送请求，等别人计算完成后返回给我；站在自己业务逻辑的角度，就是在等待。
耗时：指从发送请求到接收返回值这期间的耗时。通常耗时很高，至少是毫秒ms级别，比如数据库10ms、远程缓存2ms、服务调用50ms。
机器：负载很低，CPU在等待，很空闲、不占用CPU资源。
定义：
IO密集型业务逻辑（代码块），指的是当前需要使用线程池的这一段业务逻辑，主要就是发请求给别人，自己等待响应（返回值），这种业务逻辑就叫IO密集型业务逻辑。
类比一下，如果这个系统服务，整体也是主要发请求给别人，那么我们也称这个服务叫IO密集型应用。
注意：
线程池技术主要用在一个服务的，各个业务逻辑（代码块）里，所以通常情况，一个服务里，某几个业务逻辑是IO密集，另外几个是CPU密集型。
实际举例：
服务收到一个请求，入口方法开始处理，调用了一个子方法queryData()，这个方法负责读取数据，需要从多个地方读取数据后汇总，再继续执行别的代码。
这个queryData()方法，如果是需要读取多张数据库数据表、或者读取多个redis缓存、或者请求多个远程服务（RPC或者http）、或者需要读取多个本地文件，这些都是典型的IO密集型。
提个问题：如果是写数据呢，写到多个数据表、多个缓存、多个远程服务，这个是IO密集型的吗？
CPU密集型类似的，三个角度
表现：收到参数后，自己本地（本机）计算，最终算出结果；全靠自己计算。
耗时：指计算完成的耗时。通常耗时很低，是纳米ns级别，比如压缩解压缩20ns、加减乘除5ns、循环判断2ns。
机器：负载高，CPU在密集计算，占用较大CPU资源。
定义：
CPU密集型业务逻辑（代码块），指的是当前需要使用线程池的这一段业务逻辑，主要就是自己充分使用CPU机器资源来完成本地计算任务，这种业务逻辑就叫IO密集型业务逻辑。
实际举例：
一个方法内部的逻辑，主要是需要序列化反序列化、加密解密、向量计算、大量循环判断和加减乘除运算，这些都是典型的CPU密集型场景。（Jvm垃圾回收器也是）
也可以说，大量用到了计算机的CPU硬件资源的业务逻辑，就是CPU密集型场景。还可以说，除了IO以外的，都是CPU密集型。
注意：
一个前提是，密集二字。需要有密集的（大量的）IO或CPU计算。
总结从上述IO和CPU三个角度的描述来看，我们也可以看出为什么CPU密集型的线程数要相对小很多（线程核数的量级），为什么IO密集型可以远大于核数。就是因为：
CPU密集型已经在不断地计算了，再开更多的线程也是得等CPU空闲出来，没意义，不会算得更快了；
而IO密集型是大量的再等待，CPU是空闲的，开启更多的线程可以让并发的请求更多，从而降低对外接口（方法）耗时，提升吞吐量。
本文完。
后续两篇会继续解释：线程池流转（运行方式）和验证、池化技术。（也都非常简单）
提示：希望持续关注本系列及其他编程、职场、北漂相关文章的，也可以关注我的同名程序员Artist。
讲透线程池系列，已发历史文章：
我面试别人问线程池，很少全答对。不难，4篇短文讲透（1）
,
