1. 线程和硬件
1.1. 给CPU增加超线程并不能使应用程序性能翻倍
2. 线程池
2.1. 任务被提交到一个队列（可能有不止一个队列），然后一定数量的线程会从队列中取出任务并执行它们
2.2. 线程池的大小对获取最佳性能至关重要
- 2.2.1. 在某些情况下，过大的线程池会对性能造成损害
2.3. 线程池有最小线程数和最大线程数
2.3.1. 以最小数量的线程等待分配给它们的任务
2.3.2. 最大线程数可以起到必要的限流作用，防止线程同时执行过多的任务
2.4. CPU不是瓶颈，外部资源是，此时向线程池添加线程是有害的
2.4.1. 适用于向CPU密集型或I/O密集型的数据库发送请求的REST服务器
2.4.2. 增加线程数实际上会降低总体吞吐量
2.5. 如果给瓶颈处增加负载，性能将大幅下降
2.6. 如果当前瓶颈的负载减少了，性能很可能会提升
2.7. 设置线程池的最大线程数往往是艺术性多于科学性
2.7.1. 高估线程池中需要的线程数可能也只造成了很小的性能损失
2.7.2. 一旦线程池的设置出现问题，应用程序就会出大问题
2.8. 设置最小线程数
2.8.1. 几乎在所有的情况下，都可以将最小线程数设置成和最大线程数一样的值
2.8.2. 设置为另一个值（例如设置成1）的理由是，它可以防止系统创建过多的线程，从而节省资源
2.8.3. 最好是创建最终可能需要的所有线程，同时要确保系统能够处理预期的最大负载
2.8.4. 假设一个线程池的任务队列预计平均有20个任务，那么对它来说20就是合适的最小线程数
2.9. 在批处理应用程序中，无论是在创建线程池时分配线程（将最小线程数和最大线程数设置为相同的值，就会出现这种情况），还是按需分配线程，都不重要，因为执行应用程序所需的时间是一样的
2.10. 线程的空闲时间
3. ThreadPoolExecutor
3.1. 设置ThreadPoolExecutor的大小
3.2. 队列类型
-
3.2.1. 并发队列
3.2.1.1. 适用于管理少量任务，其他情况不适用
3.2.1.2. 你需要一个易于优化线程数的线程池，那么这个队列类型是更好的选择
3.2.1.3. 如果所有线程都在忙碌，而且池中的线程数小于最大线程数，那么新任务会启动一个新线程
3.2.1.4. 这个队列类型无法保留待处理的任务
3.2.1.5. 核心池大小是最小池大小，也就是空闲时也会保持运行的线程数
3.2.1.6. 最大池大小是池中的最大线程数
-
3.2.2. 无界队列
3.2.2.1. 任何任务都不会被拒绝（因为队列大小不受限制）
3.2.2.2. 执行器使用的线程数最多等于核心池大小，即最大池大小会被忽略
3.2.2.3. 由于队列是无界的，因此如果任务的提交速度超过了运行速度，那么会有内存消耗过多的风险
-
3.2.3. 有界队列
3.2.3.1. 采用了复杂的算法来决定何时启动新线程
3.2.3.2. 使得线程池可以作为一个限流器
-
3.2.3.3. 如果任务积压得太多，线程池就会运行更多的线程来清理积压的任务
3.2.3.3.1. 此时最大线程数可以作为第二个限流器
3.3. 不要使用Executors类来提供默认无界的线程池，这样你无法控制应用程序的内存使用情况
3.4. 应该设置ThreadPoolExecutor，让其有相同的核心线程数和最大线程数，并利用ArrayBlockingQueue来限制内存中待处理任务的数量
3.5. 父任务必须等待其子任务完成，而线程池执行器中的线程不能向队列中添加另一个任务并等待任务完成，一旦其线程处于等待状态，它就不能用来执行任何子任务了
3.6. 当任务很容易被分割成均衡的集合时，使用分区的ThreadPoolExecutor会有更好的性能
4. ForkJoinPool
4.1. 当任务不均衡时，使用ForkJoinPool会有更好的性能
4.2. 允许它的线程创建新的任务，然后挂起当前任务。当任务被挂起时，其线程可以执行其他待处理任务
4.3. 为配合分治算法设计的
4.3.1. 要确保拆分任务是有意义的
4.3.2. 应该用于递归、分治算法，它不适用于可以简单分割处理的情况
4.4. 内部会使用一个无界任务列表，运行这些任务的线程数由其构造方法指定
4.5. 如果没有向构造方法传递参数，那么线程池会基于机器上的（或Docker容器的）可用CPU数量来确定线程数
4.6. 实现了工作窃取
4.6.1. 意味着池中的每个线程都有一个自己所派生任务的队列。线程会优先处理自己队列中的任务，如果自己的队列是空的，那么它们会从其他线程的队列中窃取任务
-
4.6.2. ForkJoinPool中的其他线程也可以完成剩余的所有任务
- 4.6.2.1. ThreadPoolExecutor就不是这样的了
4.7. 确定公共的ForkJoinTask池的大小，和确定任何其他线程池的大小一样重要
4.7.1. 默认情况下，公共池的线程数和目标机器的CPU数一样
4.7.2. 如果你在一台机器上运行多个JVM，限制公共池的大小是有意义的，这样JVM之间就不会相互争夺CPU
4.8. -Djava.util.concurrent.ForkJoinPool.common.parallelism=N来设置公共池的大小
4.9. 如果你需要优化公共池的大小，可以考虑将所需的值减1
4.10. 创建太多任务会降低性能，但如果任务所需的时间不一样，太少的任务也会降低性能
