來源

在對Dubbo新版本做性能壓測時，無意中發現對用例中某個TO（Transfer Object）類的一屬性字段稍作修改，由Date變成LocalDateTime，結果是吞吐量由近5w變成了2w，RT由9ms升指90ms。

在線的系統，拼的從來不僅僅是吞吐量，
而是在保證一定的RT基礎上，再去做其他文章的， 也就是說應用的RT是我們服務能力的基石所在， 拿壓測來說， 我們能出的qps/tps容量， 必須是應用能接受的RT下的容量，而不是純理論的數據，在集團云化的過程中計算過，底層服務的RT每增加0.1ms，在應用層就會被放大，

整體的成本就會上升10%以上。

要走向異地，首先要面對的阿喀琉斯之踵：延時，長距離來說每一百公里延時差不多在1ms左右，杭州和上海來回的延遲就在5ms以上，上海到深圳的延遲無疑會更大，延時帶來的直接影響也是響應RT變大，
用戶體驗下降，成本直線上升。 如果一個請求在不同單元對同一行記錄進行修改， 即使假定我們能做到一致性和完整性， 那么為此付出的代價也是非常高的，想象一下如果一次請求需要訪問
10 次以上的異地 HSF 服務或 10 次以上的異地 DB調用, 服務再被服務調用，延時就形成雪球，越滾越大了。

普遍性

關于時間的處理應該是無處不在，可以說離開了時間屬性，99.99%的業務應用都無法支持其意義，特別是像監控類的系統中更是面向時間做針對性的定制處理。

在JDK8以前，基本是通過java.util.Date來描述日期和時刻，java.util.Calendar來做時間相關的計算處理。JDK8引入了更加方便的時間類，包括Instant，LocalDateTime、OffsetDateTime、ZonedDateTime等等，總的說來，時間處理因為這些類的引入而更加直接方便。

Instant存的是UTC的時間戳，提供面向機器時間視圖，適合用于數據庫存儲、業務邏輯、數據交換、序列化。LocalDateTime、OffsetDateTime、ZonedDateTime等類結合了時區或時令信息，提供了面向人類的時間視圖，用于向用戶輸入輸出，同一個時間面向不同用戶時，其值是不同的。比如說訂單的支付、發貨時間買賣雙方都用本地時區顯示。可以把這3個類看作是一個面向外部的工具類，而不是應用程序內部的工作部分。

簡單說來，Instant適用于后端服務和數據庫存儲，而LocalDateTime等等適用于前臺門面系統和前端展示，二者可以自由轉換。這方面，國際化業務的同學有相當多的體感和經驗。

在HSF/Dubbo的服務集成中，無論是Date屬性還是Instant屬性肯定是普遍的一種場景。

問題復現

• Instant等類的性能優勢

以常見的格式化場景舉例

@Benchmark@BenchmarkMode(Mode.Throughput)public String date_format() {Date date = new Date();return new SimpleDateFormat("yyyyMMddhhmmss").format(date);}@Benchmark@BenchmarkMode(Mode.Throughput)public String instant_format() {return Instant.now().atZone(ZoneId.systemDefault()).format(DateTimeFormatter.ofPattern("yyyyMMddhhmmss"));}

在本地通過4個線程來并發運行30秒做壓測，結果如下。

Benchmark Mode Cnt Score Error Units DateBenchmark.date_format thrpt 4101298.589 ops/s DateBenchmark.instant_format thrpt 6816922.578 ops/s

可見，Instant在format時性能方面是有優勢的，事實上在其他操作方面（包括日期時間相加減等）都是有性能優勢，大家可以自行搜索或寫代碼測試來求解。

• Instant等類在序列化時的陷阱

針對Java自帶，Hessian(淘寶優化版本)兩種序列化方案，壓測序列化和反序列化的處理性能。

Hessian是集團內應用的HSF2.2和開源的Dubbo中默認的序列化方案。

@Benchmark@BenchmarkMode(Mode.Throughput)public Date date_Hessian() throws Exception {Date date = new Date();byte[] bytes = dateSerializer.serialize(date);return dateSerializer.deserialize(bytes);}@Benchmark@BenchmarkMode(Mode.Throughput)public Instant instant_Hessian() throws Exception {Instant instant = Instant.now();byte[] bytes = instantSerializer.serialize(instant);return instantSerializer.deserialize(bytes);}@Benchmark@BenchmarkMode(Mode.Throughput)public LocalDateTime localDate_Hessian() throws Exception {LocalDateTime date = LocalDateTime.now();byte[] bytes = localDateTimeSerializer.serialize(date);return localDateTimeSerializer.deserialize(bytes);}

結果如下。可以看出，在Hessian方案下，無論還是Instant還是LocalDateTime，吞吐量相比較Date，都出現“大跌眼鏡”的下滑，相差100多倍；通過通過分析，每一次把Date序列化為字節流是6個字節，而LocalDateTime則是256個字節，這個放到網絡帶寬中的傳輸代價也是會被放大。 在Java內置的序列化方案下，有稍微下滑，但沒有本質區別。

Benchmark Mode Cnt Score Error Units DateBenchmark.date_Hessian thrpt 2084363.861 ops/s DateBenchmark.localDate_Hessian thrpt 17827.662 ops/s DateBenchmark.instant_Hessian thrpt 22492.539 ops/s DateBenchmark.instant_Java thrpt 1484884.452 ops/s DateBenchmark.date_Java thrpt 1500580.192 ops/s DateBenchmark.localDate_Java thrpt 1389041.578 ops/s

分析解釋

Hession中其實是有針對Date類做特殊處理，遇到Date屬性，都是直接獲取long類型的相對來做處理。

通過分析Hessian對Instant類的處理，無論是序列化還是反序列化，都需要Class.forName這個耗時的過程。。。，怪不得throughput急劇下降。

延展思考

1） 可以通過擴展實現Instant等類的com.alibaba.com.caucho.hessian.io.Serializer，并注冊到SerializerFactory，來升級優化Hessian。但會有前后兼容性上，這個是大問題，在集團內這種上下游依賴比較復雜的場景下，極高的風險也會讓此不可行。從這個角度看，只有建議大家都用Date來做個TO類的首選的時間屬性。

2） HSF的RPC協議從嚴格意義上講是 Session握手層的協議定義，其中的版本識別也是這個層面的行為，而業務數據的presentation展示層是通過Hessian等自描述的序列化框架來實現，這一層其實是缺少版本識別，從而導致升級起來就異常困難。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的HSF/Dubbo序列化时的LocalDateTime, Instant的性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。