來源
在對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等自描述的序列化架構來實作，這一層其實是缺少版本識别，進而導緻更新起來就異常困難。