线程池大小的设置，判断 CPU 密集任务还是 IO 密集任务？G1 收集器有哪些特点？

今天来谈谈Java的几个少见到，而且还比较重要的几个问题；

线程池大小如何设置？

• CPU 密集型任务(N+1)： 这种任务消耗的主要是 CPU 资源，可以将线程数设置为 N（CPU 核心数）+1，比 CPU 核心数多出来的一个线程是为了防止线程偶发的缺页中断， 或者其它原因导致的任务暂停而带来的影响。一旦任务暂停，CPU 就会处于空闲状态，而在这种情况下多出来的一个线程就可以充分利用 CPU 的空闲时间。
• I/O 密集型任务(2N)： 这种任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理 I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在 I/O 密集型任务的应用中，我们可以多配置一些线程，具体的计算方法是
  2N。

如何判断是 CPU 密集任务还是 IO 密集任务？

• CPU 密集型简单理解就是利用 CPU 计算能力的任务比如你在内存中对大量数据进行排序。单凡涉及到网络读取，文件读取这类都是 IO 密集型，这类任务的特点是 CPU 计算耗费时间相比于等待 IO 操作完成的时间来说很少，大部分时间都花在了等待 IO 操作完成上。

IO 密集=Ncpu*2 是怎么计算出来？

• I/O 密集型任务任务应用起来，系统会用大部分的时间来处理 I/O 交互，而线程在处理
• I/O 的时间段内不会占用 CPU 来处理，这时就可以将 CPU 交出给其它线程使用。因此在
• I/O 密集型任务的应用中，我们可以多配置一些线程。例如：数据库交互，文件上传下载，网络传输等。IO 密集型，即该任务需要大量的 IO，即大量的阻塞，故需要多配置线程数。

G1 收集器有哪些特点？

• G1 的全称是 Garbage-First，意为垃圾优先，哪一块的垃圾最多就优先清理它。
• G1 GC 最主要的设计目标是：将 STW 停顿的时间和分布，变成可预期且可配置的。被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备一下特点：
• 并行与并发：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者
• CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。
• 分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。
• 空间整合：与 CMS 的“标记-清理”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器；从局部上来看是基于“标记-复制”算法实现的。
• 可预测的停顿：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。
• G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的
• Region（这也就是它的名字 Garbage-First 的由来）