编写血案总结 第1篇
自从最近的某年某月某天起，线上服务开始变得不那么稳定。在高峰期，时常有几台机器的内存持续飙升，并且无法回收，导致服务不可用。
例如GC时间采样曲线：
和内存使用曲线：
图中所示，18:50-19:00的阶段，已经处于服务不可用的状态了。上游服务的超时异常会增加，该台机器会触发熔断。熔断触发后，改台机器的流量会打到其他机器，其他机器发生类似的情况的可能性会提高，极端情况会引起所有服务宕机，曲线掉底。
因为线上内存过大，如果采用 jmap dump的方式，这个任务可能需要很久才可以执行完，同时把这么大的文件存放起来导入工具也是一件很难的事情。再看JVM启动参数，也很久没有变更过 Xms, Xmx, -XX:NewRatio, -XX:SurvivorRatio, 虽然没有仔细分析程序使用内存情况，但看起来也无大碍。
于是开始找代码，某年某天某月～ 嗯，注意到一段这样的代码提交：
相关代码的完整功能是，每次线上调用，都会把计算结果的日志打到 Kafka，Kafka消费方再继续后续的逻辑。内存被耗尽可能有一个原因是，因为使用了 newFixedThreadPool 线xxx，而它的工作机制是，固定了N个线程，而提交给线xxx的任务队列是不限制大小的，如果Kafka发消息被阻塞或者变慢，那么显然队列里面的内容会越来越多，也就会导致这样的问题。
为了验证这个想法，做了个小实验，把 newFixedThreadPool 线xxx的线程个数调小一点，例如 1。果然压测了一下，很快就复现了内存耗尽，服务不可用的悲剧。
最后的修复策略是使用了自定义的线xxx参数，而非 Executors 默认实现解决了问题。下面就把线xxx相关的原理和参数总结一下，避免未来踩坑。
编写血案总结 第2篇
虽然Java线xxx理论，以及构造线xxx的各种参数，以及 Executors 提供的默认实现之前研读过，不过线上还没有发生过线xxx误用引发的事故，所以有必要把这些参数再仔细琢磨一遍。
优先补充一些线xxx的工作理论，有助于展开下面的内容。线xxx顾名思义，就是由很多线xxx的池子，来一个任务，就从池子中取一个线程，处理这个任务。这个理解是我在第一次接触到这个概念时候的理解，虽然整体基本切入到核心，但是实际上会比这个复杂。例如线xxx肯定不会无限扩大的，否则资源会耗尽；当线程数到达一个阶段，提交的任务会被暂时存储在一个队列中，如果队列内容可以不断扩大，极端下也会耗尽资源，那选择什么类型的队列，当队列满如何处理任务，都有涉及很多内容。线xxx总体的工作过程如下图：
线xxx内的线程数的大小相关的概念有两个，一个是核心池大小，还有最大池大小。如果当前的线程个数比核心池个数小，当任务到来，会优先创建一个新的线程并执行任务。当已经到达核心池大小，则把任务放入队列，为了资源不被耗尽，队列的最大容量可能也是有上限的，如果达到队列上限则考虑继续创建新线程执行任务，如果此刻线程的个数已经到达最大池上限，则考虑把任务丢弃。
在 包中，提供了 ThreadPoolExecutor 的实现。
既然有了刚刚对线xxx工作原理对概述，这些参数就很容易理解了：
corePoolSize- 核心池大小，既然如前原理部分所述。需要注意的是在初创建线xxx时线程不会立即启动，直到有任务提交才开始启动线程并逐渐时线程数目达到corePoolSize。若想一开始就创建所有核心线程需调用prestartAllCoreThreads方法。
maximumPoolSize-池中允许的最大线程数。需要注意的是当核心线程满且阻塞队列也满时才会判断当前线程数是否小于最大线程数，并决定是否创建新线程。
keepAliveTime
unit
workQueue
threadFactory
handler
编写血案总结 第3篇
在重复一下新任务进入时线xxx的执行策略： 如果运行的线程少于corePoolSize，则 Executor始终首选添加新的线程，而不进行排队。（如果当前运行的线程小于corePoolSize，则任务根本不会存入queue中，而是直接运行） 如果运行的线程大于等于 corePoolSize，则 Executor始终首选将请求加入队列，而不添加新的线程。 如果无法将请求加入队列，则创建新的线程，除非创建此线程超出 maximumPoolSize，在这种情况下，任务将被拒绝。 主要有3种类型的BlockingQueue：
无界队列
队列大小无限制，常用的为无界的LinkedBlockingQueue，使用该队列做为阻塞队列时要尤其当心，当任务耗时较长时可能会导致大量新任务在队列中堆积最终导致OOM。阅读代码发现， 采用就是 LinkedBlockingQueue，而楼主踩到的就是这个坑，当QPS很高，发送数据很大，大量的任务被添加到这个无界LinkedBlockingQueue 中，导致cpu和内存飙升服务器挂掉。
有界队列
常用的有两类，一类是遵循FIFO原则的队列如ArrayBlockingQueue与有界的LinkedBlockingQueue，另一类是优先级队列如PriorityBlockingQueue。PriorityBlockingQueue中的优先级由任务的Comparator决定。 使用有界队列时队列大小需和线xxx大小互相配合，线xxx较小有界队列较大时可减少内存消耗，降低cpu使用率和上下文切换，但是可能会限制系统吞吐量。
在我们的修复方案中，选择的就是这个类型的队列，虽然会有部分任务被丢失，但是我们线上是排序日志搜集任务，所以对部分对丢失是可以容忍的。
同步移交队列
如果不希望任务在队列中等待而是希望将任务直接移交给工作线程，可使用SynchronousQueue作为等待队列。SynchronousQueue不是一个真正的队列，而是一种线程之间移交的机制。要将一个元素放入SynchronousQueue中，必须有另一个线程正在等待接收这个元素。只有在使用无界线xxx或者有饱和策略时才建议使用该队列。
编写血案总结 第4篇
或