問題現象與背景：

這個bug出現在引入kotlin程式碼的過程中。我們的專案採用的是spring boot框架，為前端提供業務介面。通過周密調研，我們計劃在一個子模組中應用kotlin來進行業務開發。springboot與kotlin的結合方式不再本文累述。

開發過程中發現了一個bug：系統提供的介面有部分引數丟失。如圖所示，輸出的介面資料中沒有is_try_read、is_online、is_free這3個數據。

進一步進行debug，發現記憶體中該物件確實包含對應屬性。

方法已經執行到了return這一步，那麼為什麼在輸出環節丟失了資料呢？

排查與定位：

首先分析該輸出物件的類的設計是否有異常。該物件的類採用

Kotlin 可以建立一個只包含資料的類，關鍵字為data。編譯器會自動的從主建構函式中根據所有宣告的屬性生產equals()、hashCode()、toString() 、componentN()、和copy() 函式。kotlin的資料類簡化了這種用於表示特定實體的類，不用再麻煩地設定setter、getter方法。根據kotlin程式碼設計原則，屬性預設為public級別可見性，編譯器會為其生成setter、getter方法。如圖所示的資料類設計應該沒有問題。

接著我反編譯資料類class檔案，發現了一些端倪。如圖所示，"is"開頭的變數，編譯器自動加上

綜上，我覺得可能spring boot預設的序列化工具在把物件轉換成json字串時可能找不到上述"is"開頭的變數的get方法才導致該變數丟失。於是我寫了一個簡單的測試方法來測試fastJson、Gson、Jackson這3個序列化工具。如圖所示。

其中Book

解決方案：

至此，定位到了問題原因是kotlin對"is"開頭變數編譯生成的set、get方法命名方式有所不同導致某些java序列化工具不能識別。因為專案用的序列化工具是jackson，所以我升級了jackson的版本，發現變數仍然丟失。

解決方案一：

資料類不用"is"開頭來命名變數。但是這個始終留下了隱患，開發人員稍不注意可能就掉坑裡了，治標不治本。

解決方案二：

用Gson替換框架的序列化工具。在典型的Spring場景中，一旦請求退出後，那麼@Controller註解就會去渲染一個檢視。我們可以通過@RequestBody或者@RestController這種註解來請求Spring，並且可以直接將Model中的java物件注入到Response中，而這個過程中應用了序列化。我採用HttpMessageConverters來自定義gson為定首選序列化工具。配置如下：

@Configuration

publicclass CustomConfiguration {

    @Bean

    public HttpMessageConverterscustomConverters() {

       Collection<HttpMessageConverter<?>> messageConverters = newArrayList<>();

        GsonHttpMessageConvertergsonHttpMessageConverter = new GsonHttpMessageConverter();

       messageConverters.add(gsonHttpMessageConverter);

        return new HttpMessageConverters(true,messageConverters);

    }

}

通過這個配置，springframework框架預設使用的HttpMessageConverter中追加了GsonHttpMessageConverter來進行序列化工作。

最終我採用了方案二的方式來處理這個問題。

其他：

定位問題過程中其實還有一些曲折，例如is_try_read、is_online、is_free這3個變數都是kotlin的Int型別，而kotlin的Int與java的int和Integer相對應，懷疑可能是這個型別出現的序列化問題。但是在控制變數多次嘗試後，發現與型別無關，String型別的is_online變數依然會丟失。

Gson提供了流式序列化的方法，核心是各種adapter的write方法。

通過getAdapter(TypeToken<T> type)方法來繫結物件的變數到其Adapter的boundFields來進行後續轉換。

參考資料：