elastic-job 源码解读之从源码看null值

在elastic-Job作业启动的时候，首先会去持久化LiteJob的配置信息，持久化保存之前先去会检查job存不存在，读取zk上的原有配置的job信息，如果节点不存在，或者需要重写的时候，去注册中心写节点或者是修改节点数据。

    //SchedulerFacade.java 
    /**
     * 更新作业配置.
     *
     * @param liteJobConfig 作业配置
     * @return 更新后的作业配置
     */
  public LiteJobConfiguration updateJobConfiguration(final LiteJobConfiguration liteJobConfig) {    //持久化LiteJob配置
    configService.persist(liteJobConfig);    return configService.load(false);
  }    //ConfigurationService.java
     /**
     * 持久化分布式作业配置信息.
     *
     * @param liteJobConfig 作业配置
     */
    public void persist(final LiteJobConfiguration liteJobConfig) {        //检查冲突作业
        checkConflictJob(liteJobConfig);        if (!jobNodeStorage.isJobNodeExisted(ConfigurationNode.ROOT) || liteJobConfig.isOverwrite()) {
            jobNodeStorage.replaceJobNode(ConfigurationNode.ROOT, LiteJobConfigurationGsonFactory.toJson(liteJobConfig));
        }
    }  //检查冲突作业
 private void checkConflictJob(final LiteJobConfiguration liteJobConfig) {        //查从注册中心获取旧的配置
        Optional<LiteJobConfiguration> liteJobConfigFromZk = find();        //返回Optional是啥这个Optional是啥？？.isPresent是啥方法，百思不得其解
        if (liteJobConfigFromZk.isPresent() && !liteJobConfigFromZk.get().getTypeConfig().getJobClass().equals(liteJobConfig.getTypeConfig().getJobClass())) {            throw new JobConfigurationException("Job conflict with register center. The job '%s' in register center's class is '%s', your job class is '%s'", 
                    liteJobConfig.getJobName(), liteJobConfigFromZk.get().getTypeConfig().getJobClass(), liteJobConfig.getTypeConfig().getJobClass());
        }
    }    //返回值是optional，这个是什么东东？？
    private Optional<LiteJobConfiguration> find() {        if (!jobNodeStorage.isJobNodeExisted(ConfigurationNode.ROOT)) {            return Optional.absent();
        }
        LiteJobConfiguration result = LiteJobConfigurationGsonFactory.fromJson(jobNodeStorage.getJobNodeDataDirectly(ConfigurationNode.ROOT));        if (null == result) {            // TODO 应该删除整个job node,并非仅仅删除config node
            jobNodeStorage.removeJobNodeIfExisted(ConfigurationNode.ROOT);
        }        //这里还是一脸懵逼 optional是干嘛的？？
        return Optional.fromNullable(result);
    }

根据逻辑，应该是在配置中心获取旧的配置，检查旧配置是否存在，判断是不是null，然后再判断要不要重写， Optional<LiteJobConfiguration> liteJobConfigFromZk = find(); 那这里应该是返回LiteJobConfiguration才对，Optional是个什么东东？？打开这个Optional看了一下类结构，在guava包里，依赖如下：

<dependency>
     <groupId>com.google.guava</groupId>
     <artifactId>guava</artifactId>
     <version>18.0</version>
 </dependency>

原来是鼎鼎大名的guava，膜拜膜拜。那么这个Optional到底是啥？？看业务逻辑liteJobConfigFromZk.isPresent()应该是不为null的意思，看到不懂得地方，赶快去总结总结Optional的用法和API：

• 构造方法：该Optional接口实现类有两个，一个为Absent，一个为Present，中文意思为缺席的，出席的，然后个人理解，Present为存在的，Absent为不存在的。

  • 可以为null，为null时，构造absent对象，否则构造Present

  • t不能为null，否则抛异常

  • 返回absent对象

  • absent()

  • of(T t)

  • fromNullable(T t)

• isPresent()

  • 是否是present，不是则为absent。

• get()

  • 返回Optional包含的T实例，若为null，抛异常

• or(T)

  • 若Option包含了值，返回Optional包含的T，否则返回输入的T实例作为默认值

• orNull()

  • 返回Optional实例中包含的非空T实例，如果Optional中包含的是空值，返回null;

在elasticJob中，节点不存在或者节点配置job的信息为null，返回Absent，否则返回Present。如果Job配置是present的状态且作业监听类不一致，抛异常，检查失败。
这里是使用Optional代替了null值得判断，具体带来的好处，相信搜索一有很多链接都写得很好。

作者：一滴水的坚持
链接：https://www.jianshu.com/p/ab5f6fd6f823