背景

Flume 是 Cloudera 提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统 。一个用来控制 Flume 采集任务的 Web 应用，需要对任务进行管理，主要操作「启动、停止、新建、编辑、删除」，本质就是对 Flume 进程进行管理。

任务控制流程：

1. 任务启动：创建一个 Flume 进程。
2. 任务停止：停止该 Flume 进程。
3. 修改启动状态的任务：先停止正在执行的 Flume 进程、再创建一个 Flume 进程。
4. 任务删除：启动状态的任务先停止 Flume 进程、再删除任务信息。

本文介绍近期对这个功能的优化操作：用 Executors.newSingleThreadExecutor() 单线程调度对任务的处理命令，保证异步任务能按页面提交的顺序顺次执行。

不间断地 在 CSDN 写博客十多年了，CSDN 有流量没收益，转场掘金，有收益，没流量。本文首发掘金， 《掘金金石计划投稿》求赞！

旧逻辑

任务管理类是个单例，用了 ThreadPoolExecutor 线程池去调度 Flume 进程的操作。但是线程池没法保证任务的执行顺序，所以加了很多 await 和 sleep 操作，等待任务执行完成后才返回响应结果给页面。

这个思路没问题，必要的等待可以保证后台的 Flume 进程按页面的操作指令执行，但用户体验很纠结。

异步任务管理过程中等待常量是 2秒，加上整个 Web 处理操作，以及 Controller 里面的 Sleep 操作，通过 Web 页面对 Flume 任务的管理操作响应时间平均 8 秒左右。

我在测试的时候编辑一个启用状态的任务，提交后需要心里默数到 20 才能看到页面操作结果，确实需要很大的耐心。现场也反馈过这个问题，怎么优化呢？

优化思路

既然都用异步了，为什么非要 await 和 sleep 呢？最初思路是，直接去掉这些代码，页面响应果然很快，但是操作结果总是不合理。

1. 停止、启动连续操作时，Flume 进程并没有启动：点击 「停止」操作，立即点「启动」，Flume 进程并没有起来。
2. 编辑启动状态的任务：先停止、再启动操作，进程也没有启动。

这是因为线程池调度任务的是多线程的，而停止操作为了保证进程能被 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 有流量没收益，转场掘金，有收益，没流量。本文首发掘金， 《掘金金石计划投稿》求赞！