背景
Flume 是 Cloudera 提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统 。一个用来控制 Flume 采集任务的 Web 应用，需要对任务进行管理，主要操作「启动、停止、新建、编辑、删除」，本质就是对 Flume 进程进行管理。
任务控制流程：
- 任务启动：创建一个 Flume 进程。
- 任务停止：停止该 Flume 进程。
- 修改启动状态的任务：先停止正在执行的 Flume 进程、再创建一个 Flume 进程。
- 任务删除：启动状态的任务先停止 Flume 进程、再删除任务信息。
本文介绍近期对这个功能的优化操作：用 Executors.newSingleThreadExecutor() 单线程调度对任务的处理命令，保证异步任务能按页面提交的顺序顺次执行。
不间断地 在 CSDN 写博客十多年了，CSDN 有流量没收益，转场掘金，有收益，没流量。本文首发掘金， 《掘金金石计划投稿》求赞！
旧逻辑
任务管理类是个单例，用了 ThreadPoolExecutor 线程池去调度 Flume 进程的操作。但是线程池没法保证任务的执行顺序，所以加了很多 await 和 sleep 操作，等待任务执行完成后才返回响应结果给页面。
这个思路没问题，必要的等待可以保证后台的 Flume 进程按页面的操作指令执行，但用户体验很纠结。
异步任务管理过程中等待常量是 2秒，加上整个 Web 处理操作，以及 Controller 里面的 Sleep 操作，通过 Web 页面对 Flume 任务的管理操作响应时间平均 8 秒左右。
我在测试的时候编辑一个启用状态的任务，提交后需要心里默数到 20 才能看到页面操作结果，确实需要很大的耐心。现场也反馈过这个问题，怎么优化呢？
优化思路
既然都用异步了，为什么非要 await 和 sleep 呢？最初思路是，直接去掉这些代码，页面响应果然很快，但是操作结果总是不合理。
- 停止、启动连续操作时，Flume 进程并没有启动：点击 「停止」操作，立即点「启动」，Flume 进程并没有起来。
- 编辑启动状态的任务：先停止、再启动操作，进程也没有启动。
这是因为线程池调度任务的是多线程的，而停止操作为了保证进程能被 kill 掉，它的逻辑是：
先 kill 进程ID
休眠 2 秒
再 kill -9
启动操作命令和停止操作一起的时候，最终启动的进程 2秒后又被 kill 掉了，所以直接去掉休眠操作不行。除了休眠等待，怎么保证线程池提按 Runnable 的提交顺序执行呢？
解决办法
更换线程池类型，用 Executors.newSingleThreadExecutor() 保证按提交顺序执行 Runnable；前端只管提交操作命令，后台调度时去掉所有的 await /sleep 等阻塞操作，立即返回响应结果给页面。
优化前，修改一个启动状态的任务，耗时 11 秒：
优化后，相同操作耗时 700 毫秒：
启示录
除了休眠等待，怎么保证线程池提按 Runnable 的提交顺序执行呢？我甚至尝试了去更改 flume-ng 脚本，启动任务之前先 kill 掉之前的任务，结果直接把刚刚启动的 flume 任务又给 kill 掉了。
后来想到了还是要在线程池的调度顺序上，如何让Java的线程池顺序执行任务？这不就是 newSingleThreadExecutor 嘛？
他强任他强，清风拂山冈；任他前端怎么点，单线程调度按序走！
不搭题，就是想到了这句话而已。
不间断地 在 CSDN 写博客十多年了，CSDN 有流量没收益，转场掘金，有收益，没流量。本文首发掘金， 《掘金金石计划投稿》求赞！
-langchain核心组件)
