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值得判斷，具體帶來的好處，相信搜尋一有很多連結都寫得很好。

作者：一滴水的堅持
連結：