0
0

从零搭建xxl-job(四)：xxljob进行一些性能优化

之前的代码这部分并没有补充完毕，假如调度中心如果判断有定时任务要执行了，该怎么远程通知给执行定时任务的程序呢？当定时任务要把自己的信息发送给调度中心时，是通过一个RegistryParam对象发送的。该对象内部封装了定时任务相关的信息。

  1. public class RegistryParam implements Serializable {
  2.     private static final long serialVersionUID = 42L;
  4.     //定时任务方法的名称
  5.     private String registryKey;
  6.     //定时任务程序部署的服务器的ip地址
  7.     private String registryValue;
  9.     public RegistryParam() {
  10.     }
  12.     public RegistryParam(String registryKey, String registryValue) {
  14.         this.registryKey = registryKey;
  15.         this.registryValue = registryValue;
  16.     }
  18.     public String getRegistryKey() {
  19.         return registryKey;
  20.     }
  22.     public void setRegistryKey(String registryKey) {
  23.         this.registryKey = registryKey;
  24.     }
  26.     public String getRegistryValue() {
  27.         return registryValue;
  28.     }
  30.     public void setRegistryValue(String registryValue) {
  31.         this.registryValue = registryValue;
  32.     }
  34.     @Override
  35.     public String toString() {
  36.         return "RegistryParam{" +
  37.                 "registryKey='" + registryKey + '\'' +
  38.                 ", registryValue='" + registryValue + '\'' +
  39.                 '}';
  40.     }
  41. }

那么，调度中心通知定时任务程序执行的时候，该用什么对象封装什么信息呢?封装的这个信息是我最关心的。什! 么信息可以成为调度中心和定时任务执行程序中判别唯一定时任务的标准呢?其实很简单，就是定时任务方法的名 字。虽然啊一个定时任务程序中可能会定义多个定时任务，但是每个定时任务方法的名称是唯一的，所以，调度中 心只要把要执行的定时任务方法的名称发送给定时任务执行程序即可。并且这个方法名称同样可以封装在一个对象 中，既然是要触发定时任务了，这个对象就可以定义为TriggerParam，意思就是触发参数。请看下面的代码块。

  1. public class TriggerParam implements Serializable{
  2.     private static final long serialVersionUID = 42L;
  4.     // 定时任务方法的名字
  5.     private String executorHandler;
  7.     public String getExecutorHandler() {
  8.         return executorHandler;
  9.     }
  11.     public void setExecutorHandler(String executorHandler) {
  12.         this.executorHandler = executorHandler;
  13.     }
  14. }

这样一来，调度中心只要通过网络把封装着要执行的定时任务名字的TriggerParam对象发送给定时任务执行程序，这样，定时任务程序接收到消息后，就可以从TriggerParam对象中获得要执行的任务名称，然后直接去执行即可。当然，这个过程也很复杂，在后面的章节再给大家细讲。总之，现在我的调度中心终于有了可以向定时任务执行器发送的消息了。所以，我现在就想再次把我的调度中心的核心类重构一下，也就是重构JobScheduleHelper类中的start方法，请看下面的代码块。

  1. @Component
  2. public class JobScheduleHelper {
  4.     // 调度定时任务的线程
  5.     private Thread scheduleThread;
  7.     // 创建当前类的对象
  8.     private static JobScheduleHelper instance = new JobScheduleHelper();
  10.     // 把当前类的对象暴露出去
  11.     public static JobScheduleHelper getInstance(){
  12.         return instance;
  13.     }
  15.     // 启动调度线程工作的方法
  16.     public void start(){
  17.         scheduleThread = new Thread(new Runnable() {
  18.             @Override
  19.             public void run() {
  20.                 while (true){
  21.                     // 从数据库中查询所有定时任务信息
  22.                     List<YyJobInfo> yyJobInfoList =  YyJobAdminConfig.getAdminConfig().getYyJobInfoDao().findAll();
  23.                     // 得到当前时间
  24.                     long time = System.currentTimeMillis();
  25.                     // 遍历所有定时任务信息
  26.                     for (YyJobInfo yyJobInfo : yyJobInfoList) {
  27.                         if (time > yyJobInfo.getTriggerNextTime()){
  28.                             // 如果大于就执行定时任务，就调用下面这个方法，开始远程通知定时任务程序
  29.                             // 执行定时任务
  30.                             // 注意，这里引入了一个新的类，JobTriggerPoolHelper
  31.                             JobTriggerPoolHelper.trigger(yyJobInfo);
  32.                             // 计算定时任务下一次的执行时间
  33.                             Date nextTime = null;
  34.                             try {
  35.                                  nextTime = new CronExpression(yyJobInfo.getScheduleConf()).getNextValidTimeAfter(new Date());
  36.                             } catch (ParseException e) {
  37.                                 e.printStackTrace();
  38.                             }
  39.                             // 下面就是更新数据库中定时任务的操作
  40.                             YyJobInfo job = new YyJobInfo();
  41.                             job.setTriggerNextTime(nextTime.getTime());
  42.                             System.out.println("保存job信息");
  43.                         }
  44.                     }
  45.                 }
  46.             }
  47.         });
  48.         scheduleThread.start();
  49.     }

在上面的代码块中，我在远程通知执行定时任务的程序的操作处做了一点变动，引入了一个新的名为JobTriggerPoolHelper的新类，这个类中的trigger方法，就是用来远程通知定时任务执行器执行定时任务的。所以现在请大家看一看JobTriggerPoolHelper这个类内部的构造。

  1. public class JobTriggerPoolHelper {
  3.     private static final Logger logger = LoggerFactory.getLogger(JobTriggerPoolHelper.class);
  5.     private static JobTriggerPoolHelper helper = new JobTriggerPoolHelper();
  7.     public static void trigger(YyJobInfo yyJobInfo){
  8.         // helper其实就是该类的单例对象
  9.         helper.addTrigger(yyJobInfo);
  10.     }
  12.     public void addTrigger(YyJobInfo yyJobInfo){
  13.         // 这是我引入的新的类
  14.         YyJobTrigger.trigger(yyJobInfo);
  15.     }
  16. }

上面的代码就目前来说很简单，因为我的调度中心要去触发定时任务，让定时任务执行了，所有我就又搞了一个触发任务的类，这个类就负责把定时任务的信息向程序内部继续传递下去。在JobScheduleHelper类中调用了JobTriggerPoolHelper.trigger(yyJobInfo)方法后，程序就会来到JobTriggerPoolHelper类中，调用该类的trigger方法，接着又会调用该类的addTrigger方法，在该方法中，程序就来到了我又引入新的YyJobTrigger类中，这个类就是用来真正触发定时任务远程调用的。这个类就是用来真正触发定时任务远程调用的。请大家看下面的代码块。

  1. public class YyJobTrigger {
  3.     private static Logger logger = LoggerFactory.getLogger(YyJobTrigger.class);
  5.     public static void trigger(YyJobInfo jobInfo) {
  6.         processTrigger(jobInfo);
  7.     }
  9.     private static void processTrigger(YyJobInfo jobInfo) {
  10.         // 初始化触发器参数，这里的这个出发参数，是要在远程调用的另一端，也就是定时任务执行程序的那一端使用的
  11.         TriggerParam triggerParam = new TriggerParam();
  12.         // 设置执行器要执行的任务的方法名称
  13.         triggerParam.setExecutorHandler(jobInfo.getExecutorHandler());
  14.         // 选择具体的定时任务执行器地址，这里默认使用集合汇总的第一个。
  15.         String address = jobInfo.getRegistryList().get(0);
  16.         // 在这里执行远程调用，也就是要把执行的定时任务的执行信息发送给定时任务
  17.         // 定时任务程序执行完毕后，返回一个执行结果信息，封装在ReturnT对象中
  18.         ReturnT<String> triggerResult = runExecutor(triggerParam, address);
  19.         // 输出一下状态码，根据返回的状态码判断任务是否执行成功
  20.         logger.info("返回的状态码" + triggerResult.getCode());
  21.     }
  23.     public static ReturnT<String> runExecutor(TriggerParam triggerParam, String address) {
  24.         // 在这个方法中把消息发送给定时任务执行程序
  25.         HttpURLConnection connection = null;
  26.         BufferedReader bufferedReader = null;
  28.         try {
  29.             // 创建连接
  30.             URL realUrl = new URL(address);
  31.             // 得到连接
  32.             connection = (HttpURLConnection) realUrl.openConnection();
  33.             // 设置连接属性
  34.             // post请求
  35.             connection.setRequestMethod("POST");
  36.             connection.setDoOutput(true);
  37.             connection.setDoInput(true);
  38.             connection.setUseCaches(false);
  39.             connection.setReadTimeout(3 * 1000);
  40.             connection.setConnectTimeout(3 * 1000);
  41.             connection.setRequestProperty("connection", "Keep-Alive");
  42.             connection.setRequestProperty("Content-Type", "application/json;charset=UTF-8");
  43.             connection.setRequestProperty("Accept-Charset", "application/json;charset=UTF-8");
  44.             // 进行连接
  45.             connection.connect();
  46.             // 判断请求题是否为null
  47.             if (triggerParam != null) {
  48.                 // 序列化请求体，也就是要发送的触发参数
  49.                 String requestBody = GsonTool.toJson(triggerParam);
  50.                 // 下面就开始正式发送消息了
  51.                 DataOutputStream dataOutputStream = new DataOutputStream(connection.getOutputStream());
  52.                 dataOutputStream.write(requestBody.getBytes(StandardCharsets.UTF_8));
  53.                 // 刷新缓冲区
  54.                 dataOutputStream.flush();
  55.                 // 释放资源
  56.                 dataOutputStream.close();
  57.             }
  58.             // 获取响应码
  59.             int statusCode = connection.getResponseCode();
  60.             if (statusCode != 200) {
  61.                 // 设置失败结果
  62.                 return new ReturnT<String>(ReturnT.FAIL_CODE, "yy-job remoting fail, StatusCode(" + statusCode + ") invalid. for url：" + address);
  63.             }
  64.             // 下面就开始接受返回的结果了
  65.             bufferedReader = new BufferedReader(new InputStreamReader(connection.getInputStream(), "UTF-8"));
  66.             StringBuilder result = new StringBuilder();
  67.             String line;
  68.             // 接受返回消息
  69.             while ((line = bufferedReader.readLine()) != null) {
  70.                 result.append(line);
  71.             }
  72.             // 转换为字符串
  73.             String resultJson = result.toString();
  74.             try {
  75.                 // 转换为ReturnT对象，返回给用户
  76.                 ReturnT returnT = GsonTool.fromJson(resultJson, ReturnT.class, String.class);
  77.                 return returnT;
  78.             } catch (Exception e) {
  79.                 logger.error("yy-job remoting (url=" + address + ") response content invalid(" + resultJson + "）.", e);
  80.                 return new ReturnT<String>(ReturnT.FAIL_CODE, "yy-job remoting error(" + e.getMessage() + "),for url : " + address);
  81.             }
  82.         } catch (Exception e) {
  83.             logger.error(e.getMessage(), e);
  84.             return new ReturnT<String>(ReturnT.FAIL_CODE, "yy-job remoting error(" + e.getMessage() + "),for url:" + address);
  85.         } finally {
  86.             try {
  87.                 if (bufferedReader != null) {
  88.                     bufferedReader.close();
  89.                 }
  90.                 if (connection != null) {
  91.                     connection.disconnect();
  92.                 }
  93.             } catch (Exception e2) {
  94.                 logger.error(e2.getMessage(), e2);
  95.             }
  96.         }
  97.     }

下面的代码块就是ReturnT类的具体内容，可以看到，定时任务的执行结果就封装在里面

  1. public class ReturnT<T> implements Serializable {
  2.     public static final long serialVersionUID = 42L;
  4.     public static final int SUCCESS_CODE = 200;
  5.     public static final int FAIL_CODE = 500;
  7.     public static final ReturnT<String> SUCCESS = new ReturnT<String>(null);
  8.     public static final ReturnT<String> FAIL = new ReturnT<String>(FAIL_CODE, null);
  10.     private int code;
  11.     private String msg;
  12.     private T content;
  14.     public ReturnT(){}
  15.     public ReturnT(int code, String msg) {
  16.         this.code = code;
  17.         this.msg = msg;
  18.     }
  19.     public ReturnT(T content) {
  20.         this.code = SUCCESS_CODE;
  21.         this.content = content;
  22.     }
  23.     
  24.     public int getCode() {
  25.         return code;
  26.     }
  27.     public void setCode(int code) {
  28.         this.code = code;
  29.     }
  30.     public String getMsg() {
  31.         return msg;
  32.     }
  33.     public void setMsg(String msg) {
  34.         this.msg = msg;
  35.     }
  36.     public T getContent() {
  37.         return content;
  38.     }
  39.     public void setContent(T content) {
  40.         this.content = content;
  41.     }
  43.     @Override
  44.     public String toString() {
  45.         return "ReturnT [code=" + code + ", msg=" + msg + ", content=" + content + "]";
  46.     }
  48. }

根据上述代码，请大家仔细想一想，现在的程序主要是谁在干活？干的什么活？因为说到底，设计一个程序不能只考虑程序的运行，还要尽可能考虑程序的性能。当运行没有问题的时候，提高性能就成为最主要的问题了。那我目前的调度中心，性能如何，性能的瓶颈又在哪里呢？其实已经很明显了，目前的调度中心，按照我现在的编码流程，所有的活实际上都是JobScheduleHelper类中的scheduleThread线程在干。请大家再次回顾一下JobScheduleHelper类的内容。

  1. public class JobScheduleHelper {
  3.     // 调度定时任务的线程
  4.     private Thread scheduleThread;
  6.     // 创建当前类的对象
  7.     private static JobScheduleHelper instance = new JobScheduleHelper();
  9.     // 把当前类的对象暴露出去
  10.     public static JobScheduleHelper getInstance(){
  11.         return instance;
  12.     }
  14.     // 启动调度线程工作的方法
  15.     public void start(){
  16.         scheduleThread = new Thread(new Runnable() {
  17.             @Override
  18.             public void run() {
  19.                 while (true){
  20.                     // 从数据库中查询所有定时任务信息
  21.                     List<YyJobInfo> yyJobInfoList =  YyJobAdminConfig.getAdminConfig().getYyJobInfoDao().findAll();
  22.                     // 得到当前时间
  23.                     long time = System.currentTimeMillis();
  24.                     // 遍历所有定时任务信息
  25.                     for (YyJobInfo yyJobInfo : yyJobInfoList) {
  26.                         if (time > yyJobInfo.getTriggerNextTime()){
  27.                             // 如果大于就执行定时任务，就调用下面这个方法，开始远程通知定时任务程序
  28.                             // 执行定时任务
  29.                             // 注意，这里引入了一个新的类，JobTriggerPoolHelper
  30.                             JobTriggerPoolHelper.trigger(yyJobInfo);
  31.                             // 计算定时任务下一次的执行时间
  32.                             Date nextTime = null;
  33.                             try {
  34.                                  nextTime = new CronExpression(yyJobInfo.getScheduleConf()).getNextValidTimeAfter(new Date());
  35.                             } catch (ParseException e) {
  36.                                 e.printStackTrace();
  37.                             }
  38.                             // 下面就是更新数据库中定时任务的操作
  39.                             YyJobInfo job = new YyJobInfo();
  40.                             job.setTriggerNextTime(nextTime.getTime());
  41.                             System.out.println("保存job信息");
  42.                         }
  43.                     }
  44.                 }
  45.             }
  46.         });
  47.         scheduleThread.start();
  48.     }

可以看到,在JobScheduleHelper中，一旦start方法被调用了，schedulueThread线程就会启动，然后在一个循环中不停得扫描数据库，调度任务去执行。并且，调度任务去执行时，最终会一路调用YyJobTrigger类中的runExecutor方法，在该方法中，会通过http协议，把封装好的定时任务信息的对象发送给定时任务程序，并且——注意里这是是必须要强调清楚的——scheduleThread会等待定时任务程序执行完定时任务后把执行的结果回复过来。如果定时任务执行的时间过长,那scheduleThread线程不就会一直阻塞在这里等待响应结果吗？显然这是一个严重的问题，解决的方法也很简单，再开启一个线程去执行任务就好了，但每次执行任务都要创建新线程对性能也有损耗，所有可以采用线程池的方式。请大家看一下重构之后的JobTriggerPoolHelper类。

  1. public class JobTriggerPoolHelper {
  3.     private static final Logger logger = LoggerFactory.getLogger(JobTriggerPoolHelper.class);
  5.     // 在这里创建线程池，用于远程调用定时任务
  6.     private ThreadPoolExecutor triggerPool = null;
  8.     // 创建该类的对象
  9.     private static JobTriggerPoolHelper helper = new JobTriggerPoolHelper();
  11.     // 对外暴露的该类线程池的方法
  12.     public static void toStart() {
  13.         helper.start();
  14.     }
  16.     public static void trigger(YyJobInfo yyJobInfo) {
  17.         // helper其实就是该类的单例对象
  18.         helper.addTrigger(yyJobInfo);
  19.     }
  21.     // 该方法经过重构了，在这里把定时任务信息提交给线程池去远程发送
  22.     public void addTrigger(YyJobInfo yyJobInfo) {
  23.         triggerPool.execute(new Runnable() {
  24.             @Override
  25.             public void run() {
  26.                 // 这里就是线程池中的线程去执行远程调用定时任务的任务了
  27.                 YyJobTrigger.trigger(yyJobInfo);
  28.             }
  29.         });
  31.     }
  33.     public void start() {
  34.         // 在这里创建线程池，最大线程数为150
  35.         triggerPool = new ThreadPoolExecutor(
  36.                 10, 150, 60L, TimeUnit.SECONDS, new LinkedBlockingDeque<>(1000),
  37.                 new ThreadFactory() {
  38.                     @Override
  39.                     public Thread newThread(Runnable r) {
  40.                         return new Thread(r, "Yy-job, admin JobTriggerPoolHelper-fastTriggerPool-" + r.hashCode());
  41.                     }
  42.                 }
  43.         );
  44.     }
  46.     // 中止线程池的方法
  47.     public void stop(){
  48.         triggerPool.shutdown();
  49.     }

// TODO 测试启动类

现在，我想直接为大家剖析调度中心存在的一点小缺陷。有的朋友可能已经注意到了，现在是我的调度中心在维护数据库中定时任务的信息，而所有的定时任务都会把自己的信息存储在数据库中。调度线程不断地扫描数据库，判断哪些定时任务可以执行，就把信息提交给线程池。那么，请大家简单思考一下，如果数据库中存储了200个定时任务，但是线程池的最大线程数只有150，假如所有定时任务的执行时间都比较接近，这是不是意味着在一段时间内，有大量的定时任务要交给线程池中的线程执行。但是线程数并不足够，所以，有的定时任务可能就要等待别的定时任务执行完了，才能得到可以使用的线程去执行自己的任务。这种情况本来很常见，但是请大家再仔细想想，所谓定时任务，就是要在特定的时间执行才可以。所以，我们不得不考虑考虑这样一种情况。当有很多定时任务执行耗时比较长时，那么可能同一时间段，线程池中阻塞等待结果的线程就会比较多，这样一来其他定时任务就不得不也等待线程了。举个例子，如果线程池中只有两个线程，现在有三个定时任务，两个定时任务执行的耗时都为2秒，第三个定时任务执行耗时为50ms。如果这三个定时任务触发的时间都相同，结果耗时为2秒的定时任务把两个线程占用了，两个线程都要阻塞等待http的相应结果，那第三个耗时很少的定时任务就不得不等待一会儿了。这么做，就会导致耗时较少的定时任务被耗时较多的定时任务拖累，甚至导致延误执行时机，本来该执行了，结果被拖延到两秒后才执行。那针对这种情况，有没有很好的解决方法吗？当然是有的。仍然采用编程世界中的那条准则，就是少一事不如多一事。

请大家想一想，既然我的程序很有可能出现执行耗时较少的定时任务被执行耗时好长的定时任务拖累的情况，那我就把耗时较长的定时任务和耗时较短的定时任务分开不就完了？所谓的分开也很简单，就是在调度中心的JobTriggerPoolHelper组件中创建两个线程池，一个线程池专门调度耗时较长的定时任务，我就可以称它为慢线程；一个线程池专门调度耗时较短的定时任务，我就称他为快线程池。这样一来，快线程池调度定时任务就会保持很高的性能，而慢线程池就维持一般水准即可，并且，耗时较短的定时任务终于不会被耗时较长的定时任务拖累了。

那么这个编程思路该在呢么实现呢？我认为最重要的就是做好定时任务的分流，也就是哪些任务要提交给快线程池，哪些任务要提交给慢线程池。经过思考，决定给定时任务设立一个时间标尺，只要定时任务执行的时间大于500毫秒，就称这个定时任务为慢任务，要提交给慢线程池执行；而执行时间小于500毫秒的，就称这个定时任务为快任务，要提交给快线程池执行。这个判断标准很简单，简单就意味着误判，那怎么避免误判呢？因为有些定时任务很可能执行的耗时小于500毫秒，但是http在返回响应的时候网络阻塞了，导致定时任务耗时超过500毫秒了，这不就是最容易出现的误判情况吗？解决的方法也很简单，一般来说定时任务不可能只触发一次，肯定是按照特定的时间一直执行，比如每秒执行一次，每5秒执行一次等等。所说说，我只需在程序中做一个判断，判断同一个定时任务一分钟内执行的耗时，只要耗时在一分内超过500毫秒的次数大于10次了，就把它看做满任务，以后每次触发的时候，就交给慢线程池来远程调度。至于那些每分钟或每几分执行一次，甚至是每天执行一次的定时任务，晚个一两秒执行是没什么问题的。那么，怎么判定同一个定时任务每次执行的耗时呢，别忘了定时任务信息是存储在数据库中的，我只需要用每个定时任务的主键ID就可判断是否为同一个定时任务。所以，接下来我要给封装定时任务信息并且和数据库打交道的YyJobInfo类添加一个ID属性就可以了。

接下来，就为大家展示一下重构好的JobTriggerPoolHelper类

  1. public class JobTriggerPoolHelper {
  3.     private static final Logger logger = LoggerFactory.getLogger(JobTriggerPoolHelper.class);
  5.     //定义的快线程池
  6.     private ThreadPoolExecutor fastTriggerPool = null;
  7.     //定义的慢线程池
  8.     private ThreadPoolExecutor slowTriggerPool = null;
  10.     // 创建该类的对象
  11.     private static JobTriggerPoolHelper helper = new JobTriggerPoolHelper();
  13.     // 对外暴露的该类线程池的方法
  14.     public static void toStart() {
  15.         helper.start();
  16.     }
  18.     // 中止线程池的方法
  19.     public static void toStop() {
  20.         helper.stop();
  21.     }
  23.     public void start() {
  24.         // 快线程池，最大线程数为200
  25.         fastTriggerPool = new ThreadPoolExecutor(
  26.                 10, 200, 60L, TimeUnit.SECONDS, new LinkedBlockingDeque<>(1000),
  27.                 new ThreadFactory() {
  28.                     @Override
  29.                     public Thread newThread(Runnable r) {
  30.                         return new Thread(r, "Yy-job, admin JobTriggerPoolHelper-fastTriggerPool-" + r.hashCode());
  31.                     }
  32.                 }
  33.         );
  34.         // 慢线程池，最大线程数为100
  35.         slowTriggerPool = new ThreadPoolExecutor(
  36.                 10, 100, 60L, TimeUnit.SECONDS, new LinkedBlockingDeque<>(1000),
  37.                 new ThreadFactory() {
  38.                     @Override
  39.                     public Thread newThread(Runnable r) {
  40.                         return new Thread(r, "Yy-job, admin JobTriggerPoolHelper-slowTriggerPool-" + r.hashCode());
  41.                     }
  42.                 }
  43.         );
  44.     }
  46.     // 终止线程池的方法
  47.     public void stop() {
  48.         fastTriggerPool.shutdownNow();
  49.         slowTriggerPool.shutdownNow();
  50.     }
  52.     public static void trigger(YyJobInfo yyJobInfo) {
  53.         // helper其实就是该类的单例对象
  54.         helper.addTrigger(yyJobInfo);
  55.     }
  57.     // 获取当前的系统时间，这里计算出来的其实是系统当前的分钟数，下面马上就会用到
  58.     private volatile long minTim = System.currentTimeMillis() / (60 * 1000);
  60.     /**
  61.      * 如果有任务出现慢执行情况了，就会被记录在该Map中
  62.      * 所谓慢执行，就是执行的时间超过了500毫秒，该map的key为job的id,value为慢执行的次数
  63.      * 如果一分钟慢执行的次数超过了10次，该任务就会被交给慢线程池来执行
  64.      * 而该Map也会一分钟清空一次，来循环记录慢执行的情况
  65.      */
  66.     private volatile ConcurrentMap<Integer, AtomicInteger> jobTimeoutCountMap = new ConcurrentHashMap<>();
  67.     
  68.     // 该方法经过重构了，在这里把定时任务信息提交给线程池去远程发送
  69.     public void addTrigger(YyJobInfo yyJobInfo) {
  70.         int jobId = yyJobInfo.getId();
  71.         // 默认先用快线程池
  72.         ThreadPoolExecutor triggerPool = fastTriggerPool;
  73.         // 用任务Id从慢执行的Map中得到该job对应的慢执行次数
  74.         AtomicInteger jobTimeoutCount = jobTimeoutCountMap.get(jobId);
  75.         // 这里就是具体判断了，如果慢执行次数不为null,并且一分钟超过10了，就选用慢线程池来执行该任务。
  76.         if (jobTimeoutCount != null && jobTimeoutCount.get() > 10) {
  77.             // 选用慢线程池了
  78.             triggerPool = slowTriggerPool;
  79.         }
  80.         // 在这里就把任务提交给线程池了，在这个任务执行一个触发器任务，把刚才传进来的job的各种信息整合到一起
  81.         // 在触发器任务重，会进行job的远程调用，这个调用链还是比较短的，执行流程也很清晰。
  82.         triggerPool.execute(new Runnable() {
  83.             @Override
  84.             public void run() {
  85.                 // 再次获取当前时间，这个时间后面会用到
  86.                 long start = System.currentTimeMillis();
  87.                 try {
  88.                     // 这里就是线程池中的线程去执行远程调度定时任务的任务了
  89.                     YyJobTrigger.trigger(yyJobInfo);
  90.                 } catch (Exception e) {
  91.                     logger.error(e.getMessage(), e);
  92.                 } finally {
  93.                     // 这里再次获得当前的分钟数，这个分钟数会刚才上面的分钟数做对比
  94.                     long minTimeNow = System.currentTimeMillis() / (60 * 1000);
  95.                     // 这里就用到了两个分钟数做对比，如果两个分钟数不等，说明过去了一分钟
  96.                     // 而慢执行Map中的数据是一分钟清理一次，所以说这里就把慢执行Map清空
  97.                     // 注意，这个清空的动作是线程池中的线程来执行的，并且这个动作是在finally代码块中执行的
  98.                     // 也就意味着在上面的触发器任务执行完毕后才进行清空操作
  99.                     if (minTim != minTimeNow) {
  100.                         minTim = minTimeNow;
  101.                         jobTimeoutCountMap.clear();
  102.                     }
  103.                 }
  104.                 // 在这里用当前毫秒值减去之前得到的毫秒值
  105.                 long cost = System.currentTimeMillis() - start;
  106.                 // 判断任务的执行时间是否超过500毫秒了
  107.                 // 这里仍然要结合上面的finally代码块来理解，因为触发器执行完了才会执行finally代码块中的代码，所以这时候也就能得到job的执行时间了
  108.                 if (cost > 500) {
  109.                     // 超过500毫秒了，就判断当前执行的任务为慢执行任务，所以将它在慢执行Map中记录一次
  110.                     // Map的key为jobId，value为慢执行的次数
  111.                     AtomicInteger timeoutCount = jobTimeoutCountMap.putIfAbsent(jobId, new AtomicInteger(1));
  112.                     if (timeoutCount != null) {
  113.                         // 慢执行的次数加1
  114.                         timeoutCount.incrementAndGet();
  115.                     }
  116.                 }
  117.             }
  118.         });
  119.     }
  120. }
标签： 性能优化
本文转载自: https://blog.csdn.net/qq_38482920/article/details/141108638
版权归原作者 佳幂小煜 所有， 如有侵权，请联系我们删除。
登录后发布评论

“从零搭建xxl-job(四)：xxljob进行一些性能优化”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

网络安全法-网络运行安全

使用selenium/drissionpage时如何阻止chrome自动跳转http到https

docker desktop 里部署的Open WebUI 管理员密码忘记了的处理方法

在ubuntu20.04中搭建onsite比赛运行环境

利用开源的低代码表单设计器FcDesigner高效管理和渲染复杂表单结构

Kafka学习笔记

【前端】浏览器输入url到页面呈现发生了什么？

文章导航
没有找到文章内容分段。。。