jackson使用setDateFormat後反序列化錯誤

最近marketing-activity系統在接入降級服務，出現啓動時能夠正確獲取到降級配置，系統運行一段時間後修改降級策略不生效的問題，以前訂單系統，用戶系統和其餘系統的接入都沒問題出現這個問題，確定是觸發了某種特定的case。營銷的同窗聯繫我進行排查，排查日誌發現是降級服務反序列化Date類型異常，接收到的數據格式是yyyy-MM-dd HH:mm:ss，並不在jackson支持的反序列化格式以內。降級服務的sdk也是使用的jackson進行序列化的，爲何會出現jackson序列化後的數據卻不能使用jackson反序列化。
接着查看marketing-activity系統的降級服務sdk日誌發現一個很詭異的現象，最初發送的序列化後的請求仍是時間戳格式的，運行一段時間後就變成了yyyy-MM-dd HH:mm:ss格式，也就是說系統的行爲在運行時被改變了。

那麼究竟是什麼能夠改變系統運行時的序列化邏輯呢？可能出現的主要緣由有2種。一種是字節碼技術，也就是btrace，greys這些。另外一種就是調用jackson自己的api改變了一些屬性。顯然第二種的可能性更大一些，果真在jsonUitl裏發現了蛛絲馬跡，toObject容許設置特定的時間格式進行反序列化，調用setDateFormat會致使後續所有的Date類型的序列化都會是yyyy-MM-dd HH:mm:ss格式，天然不能默認設置的jackson反序列化。

至此降級服務改變策略後不生效的根本緣由就獲得瞭解答，那麼若是某個對象就是要使用yyyy-MM-dd HH:mm:ss 進行序列化和反序列化怎麼辦，建議使用@JsonFormat 單獨對屬性進行註釋。
最後談談fastjson和jackson，貌似jackson的各類坑遇到過不少，而fastjson的坑不多，那麼爲何jackson仍是要比fastjson更流行，真的只是國外的月亮更圓，空氣更甜？這個主要是json框架的設計理念偏重點不一樣，fastjson偏重的是簡單和快速，內部實現有不少的hack和magic code。而jackson偏重的是標準和強大，格式支持json，xml，有不少的屬性能夠設置很是的靈活，也有不少的接口能夠自定義進行擴展，致使學習成本比較高，須要詳細看過jackson文檔才能上手。