Fury 是一個基于 JIT 動態(tai)編(bian)譯和零拷貝的多(duo)語(yu)言序列化框架(jia)，支(zhi)持
Java/Python/Golang/JavaScript/C++ 等(deng)語(yu)言(yan)，提供全自動的(de)對象多語(yu)言(yan) / 跨(kua)語(yu)言(yan)序列化能力，和相比 JDK 最(zui)高 170 倍的(de)性能。
背景
序列(lie)化(hua)是系統通(tong)信的(de)基(ji)礎組件，在大數據(ju)、AI 框架和(he)云原生等(deng)分布式系統中(zhong)廣泛使用。當對象需要跨進程、跨語言、跨節點傳(chuan)輸、持久化(hua)、狀態讀寫(xie)、復制時，都需要進行序列(lie)化(hua)，其性能和(he)易用性影響運行效率和(he)開發效率。
靜態序列化框架
protobuf/flatbuffer/thrift 由于(yu)不(bu)(bu)(bu)支持(chi)對象引用和多態(tai)(tai)、需要提(ti)前生成代碼(ma)等原因，無法作為領域(yu)對象直接(jie)面向應用進(jin)行跨語言開發。而動(dong)態(tai)(tai)序列化(hua)框(kuang)架 JDK 序列化(hua) /Kryo/Fst/Hessian/Pickle 等，盡(jin)管(guan)提(ti)供(gong)了(le)易用性(xing)和動(dong)態(tai)(tai)性(xing)，但不(bu)(bu)(bu)支持(chi)跨語言，且(qie)性(xing)能(neng)存在(zai)顯著不(bu)(bu)(bu)足，并不(bu)(bu)(bu)能(neng)滿(man)足高吞吐、低延遲和大規(gui)模數據傳輸場(chang)景需求(qiu)。
因此，我們開(kai)發了(le)一個新(xin)的(de)多語言(yan)序列(lie)化框(kuang)架 Fury，并(bing)正式在 Github 開(kai)源。通過一套高度優化的(de)序列(lie)化基礎原語，結合 JIT 動(dong)態編譯(yi)和(he) Zero-Copy 等(deng)技術，同時(shi)滿(man)足(zu)了(le)性能(neng)、功能(neng)和(he)易用性的(de)需求，實現了(le)任意對象(xiang)自動(dong)跨語言(yan)序列(lie)化，并(bing)提供極致的(de)性能(neng)。
Fury 簡介
Fury 是一個(ge)基(ji)于 JIT 動(dong)態編(bian)譯和(he)零拷貝的多語言序列化框架，提供極致的性能(neng)和(he)易(yi)用性：
支持(chi)主流編程語言(yan)(yan) Java/ Python/ C++/ Golang/ JavaScript，其它語言(yan)(yan)可輕易擴展;
統一(yi)的多語言序列化(hua)核心(xin)能力：
高(gao)度優(you)化的序列化原(yuan)語;
Zero-Copy 序(xu)列化 支(zhi)持，支(zhi)持 Out of band 序(xu)列化協議，支(zhi)持堆外內存讀(du)寫;
基于 JIT 動(dong)態(tai)編 技術在(zai)運行時(shi)異步(bu)多線程自(zi)動(dong)生成序列(lie)化(hua)代碼(ma)優化(hua)性能，增(zeng)加方法內聯、代碼(ma)緩存(cun)和消(xiao)除死代碼(ma)，減少虛方法調用 / 條件(jian)分(fen)支 /Hash 查找 / 元數據寫(xie)入 / 內存(cun)讀寫(xie)等(deng)，提(ti)供相比(bi)別的(de)序列(lie)化(hua)框架最(zui)高 170 倍的(de)性能;
多協(xie)議支持(chi)：兼顧動態序(xu)列化的靈活性(xing)和(he)易用性(xing)，以及靜(jing)態序(xu)列化的跨語言能(neng)力。
Java 序列化：
無縫替(ti)代 JDK/Kryo/Hessian，無需修改(gai)任(ren)何代碼，但提(ti)供最(zui)高(gao) 170x 的性能，可以大幅提(ti)升高(gao)性能場景 RPC 調用、數據傳輸和對象持久(jiu)化效率(lv);
100% 兼容 JDK 序列化，原生(sheng)支持 JDK 自(zi)定義序列化方(fang)法(fa) writeObject/ readObject/ writeReplace/ readResolve/ readObjectNoData
跨語言對象圖序列化：
多語(yu)言 / 跨(kua)語(yu)言自動序(xu)列化任意對(dui)象，無需創建 IDL 文件、手動編譯 schema 生成代碼以(yi)及將對(dui)象轉換為中間格式;
多語(yu)言 / 跨(kua)語(yu)言自動(dong)序列化共享引用和循環引用，不需要關(guan)心數據重復或者遞(di)歸錯誤(wu);
支持對象類型(xing)多態，多個子類型(xing)對象可以同時被序列化;
行存序列化：
提供緩(huan)存友好的二(er)進制(zhi)隨機訪問行存格式，支(zhi)持(chi)跳過序(xu)列(lie)(lie)化和部分序(xu)列(lie)(lie)化，適合高(gao)性能計(ji)算和大規模數(shu)據傳輸(shu)場景(jing);
支持和 Arrow 列存自動互轉 ;
序列化核心能力
盡(jin)管(guan)不同(tong)的場景對序列(lie)(lie)化(hua)(hua)有(you)需求，但序列(lie)(lie)化(hua)(hua)的底(di)層(ceng)操作都是類似的。因此(ci) Fury 定義和實(shi)現(xian)了一套(tao)序列(lie)(lie)化(hua)(hua)的基(ji)礎能(neng)力，基(ji)于這套(tao)能(neng)力能(neng)夠(gou)快速構(gou)建不同(tong)的多(duo)語(yu)言序列(lie)(lie)化(hua)(hua)協議，并通過編譯加速等(deng)優化(hua)(hua)具備高性能(neng)。同(tong)時針對一種(zhong)協議在基(ji)礎能(neng)力上(shang)的性能(neng)優化(hua)(hua)，也(ye)能(neng)夠(gou)讓所(suo)有(you)的序列(lie)(lie)化(hua)(hua)協議都受益(yi)。
序列化原語
序(xu)列(lie)化涉(she)及(ji)的常(chang)見操作主要包括：
bitmap 位操作
整數編解碼
整數壓縮
字符(fu)串創建 * 拷貝(bei)優化
字(zi)符(fu)串編碼：ASCII/UTF8/UTF16
內存拷貝優化
數組拷貝壓縮優化
元數據編碼 & 壓縮 & 緩存
Fury 針對這些(xie)操作在每種語(yu)言內部(bu)都做(zuo)了(le)大量的優化，結合 SIMD 指令和語(yu)言高級特性，將性能(neng)推到極致(zhi)，從(cong)而(er)方便不同(tong)協議使用。
零拷貝序列化
在大規模數據(ju)傳輸(shu)場景，一(yi)個(ge)對象圖(tu)內部往往有多個(ge) binary buffer，而序(xu)列化(hua)(hua)框架在序(xu)列化(hua)(hua)過程當中會把這(zhe)些數據(ju)寫(xie)入一(yi)個(ge)中間 buffer，引入多次耗時(shi)內存拷貝(bei)。Fury 借鑒了 pickle5、ray 以(yi)及 arrow 的零拷貝(bei)設(she)計，實現了一(yi)套(tao) Out-Of-Band 序(xu)列化(hua)(hua)協(xie)議，能夠(gou)把一(yi)個(ge)對象圖(tu)當中的所有 binary buffer 直(zhi)接抓取(qu)出來，避免(mian)掉這(zhe)些 buffer 的中間拷貝(bei)，將(jiang)序(xu)列化(hua)(hua)期間的內存拷貝(bei)開銷降(jiang)低到 0。
下圖(tu)是 Fury 關閉(bi)引(yin)用支持時(shi) Zero-Copy 的大致序列化過(guo)程。
目(mu)前(qian) Fury 內置了以下類型的 Zero-Copy 支(zhi)持：
Java：所有基(ji)本類(lei)型(xing)數組(zu)、ByteBuffer、ArrowRecordBatch、VectorSchemaRoot
Python：array 模塊的所有(you) array、numpy 數(shu)組、pyarrow.Table、pyarrow.RecordBatch
Golang：byte slice
用戶也可以基于 Fury 的接口擴展(zhan)新的零拷貝類型。
JIT 動態編譯加速
對(dui)于要序(xu)列(lie)化的(de)(de)自(zi)定(ding)義類型(xing)(xing)對(dui)象(xiang)，其(qi)中通常包含大量(liang)類型(xing)(xing)信(xin)息，Fury 利用(yong)這些類型(xing)(xing)信(xin)息在運行(xing)時(shi)直接(jie)生成高效的(de)(de)序(xu)列(lie)化代(dai)碼，將(jiang)大量(liang)運行(xing)時(shi)的(de)(de)操(cao)作(zuo)在動態編譯階段(duan)完成，從(cong)而增加(jia)方法(fa)內(nei)聯和代(dai)碼緩存，減少虛(xu)方法(fa)調用(yong) / 條(tiao)件分支 /Hash 查找 / 元(yuan)數據寫(xie)入 / 內(nei)存讀寫(xie) 等(deng)，最終(zhong)大幅(fu)加(jia)速了序(xu)列(lie)化性能(neng)。
對于(yu)(yu) Java 語言，Fury 實(shi)現了(le)一套運行時(shi)(shi)代碼生(sheng)成(cheng)框架，定義了(le)一套序列化邏輯的算子表達(da)式 IR，在(zai)運行時(shi)(shi)基于(yu)(yu)對象(xiang)類型的泛型信息進行類型推斷，然后構建(jian)一顆描述序列化代碼邏輯的表達(da)式樹，根據表達(da)式樹生(sheng)成(cheng)高(gao)效的 Java 代碼，再(zai)在(zai)運行時(shi)(shi)通過(guo) Janino 編(bian)譯成(cheng)字節(jie)碼，再(zai)加載(zai)到用戶的 ClassLoader 里(li)面或者 Fury 創建(jian)的 ClassLoader 里(li)面，最終通過(guo) Java JIT 編(bian)譯成(cheng)高(gao)效的匯(hui)編(bian)代碼。
由(you)于 JVM JIT 會(hui)跳過大(da)方(fang)(fang)法(fa)編(bian)(bian)譯和(he)內聯，Fury 也實現(xian)了一(yi)套優化器(qi)，將大(da)方(fang)(fang)法(fa)遞歸拆分成小方(fang)(fang)法(fa)，這樣就(jiu)保證了 Fury 生成的所有代(dai)碼都可以被編(bian)(bian)譯和(he)內聯，壓榨(zha) JVM 的性(xing)能到(dao)極致。
同時 Fury 也(ye)支持(chi)異步多(duo)線程動態編(bian)譯，將不同序列(lie)化(hua)器(qi)的代碼(ma)生成任務提(ti)交到線程池執行，在編(bian)譯完成之前(qian)使用解(jie)釋模(mo)式執行，從而保(bao)證不會出(chu)現序列(lie)化(hua)毛刺，不需要提(ti)前(qian)預熱所有類(lei)型的序列(lie)化(hua)。
Python 和 JavaScript 場景也是采用(yong)的類(lei)似代碼(ma)生成(cheng)(cheng)方(fang)式，這樣的生成(cheng)(cheng)方(fang)式開發(fa)門檻(jian)低，更容易排查問題。
由于序列(lie)化需(xu)要密切操作每種編(bian)程(cheng)語(yu)(yu)言的(de)(de)對象，而編(bian)程(cheng)語(yu)(yu)言并(bing)沒有暴露內存模型的(de)(de)低階 API，通過 Native 方法(fa)調用存在(zai)較(jiao)大開銷，因此我們并(bing)不能(neng)通過 LLVM 構(gou)建一個(ge)統一的(de)(de)序列(lie)化器(qi) JIT 框架，而是需(xu)要在(zai)每種語(yu)(yu)言內部結合語(yu)(yu)言特性實現特定的(de)(de)代碼(ma)生成框架以及序列(lie)化器(qi)構(gou)建邏輯。
靜態代碼生成
盡(jin)管 JIT 編(bian)譯(yi)(yi)能夠大幅提(ti)升序列(lie)(lie)化(hua)效率，并且(qie)在運(yun)行時(shi)能夠根據數據的(de)統計(ji)分布重新(xin)生(sheng)成更優的(de)序列(lie)(lie)化(hua)代碼，但 C++/Rust 等語言不(bu)支持反(fan)射，沒有虛擬機(ji)，也沒有提(ti)供內(nei)存模型的(de)低階 API，因此我們無(wu)法針對(dui)這類語言通過 JIT 動態編(bian)譯(yi)(yi)生(sheng)成序列(lie)(lie)化(hua)代碼。
對(dui)于(yu)此類場(chang)景，Fury 正在(zai)實現(xian)一套 AOT 靜(jing)態代(dai)碼生(sheng)成(cheng)框架，在(zai)編譯時根(gen)據對(dui)象的 schema 提前生(sheng)成(cheng)序(xu)(xu)列(lie)化代(dai)碼，然后使(shi)用生(sheng)成(cheng)的代(dai)碼進行(xing)自動序(xu)(xu)列(lie)化。對(dui)于(yu) Rust，未來(lai)也(ye)會通過(guo) Rust 的 macro 在(zai)編譯時生(sheng)成(cheng)代(dai)碼，提供更好的易用性。
緩存優化
在序(xu)(xu)(xu)列(lie)化自定義(yi)類(lei)型時(shi)，會把(ba)字(zi)段進(jin)行(xing)重(zhong)排序(xu)(xu)(xu)，保(bao)證相同接(jie)口類(lei)型的字(zi)段依次序(xu)(xu)(xu)列(lie)化，增加(jia)緩(huan)存命中的概(gai)率，同時(shi)也促(cu)進(jin)了(le) CPU 指令(ling)緩(huan)存，實現了(le)更加(jia)高效的序(xu)(xu)(xu)列(lie)化。對于基(ji)本(ben)類(lei)型字(zi)段將寫(xie)入順序(xu)(xu)(xu)按照字(zi)節字(zi)段大小降序(xu)(xu)(xu)排列(lie)，這樣如果開始地址是對齊(qi)的，隨后的讀寫(xie)都會發生在內(nei)存地址對齊(qi)的位置，CPU 執行(xing)起來更加(jia)高效。
多協議設計與實現
基于 Fury 提供(gong)的(de)多語(yu)言序(xu)列化核心(xin)能(neng)力，我們在這(zhe)之上構建了(le)三種(zhong)序(xu)列化協議，分別適用于不同的(de)場景：
Java 序(xu)列化：適合純 Java 序(xu)列化場景，提供最高百倍(bei)以上的性能提升;
跨(kua)語(yu)言(yan)(yan)對象圖序列化(hua)：適合(he)面向(xiang)應用的多語(yu)言(yan)(yan)編程(cheng)，以及高性能跨(kua)語(yu)言(yan)(yan)序列化(hua);
行存(cun)序(xu)列化：適(shi)合分布式計算引擎如 Spark/Flink/Dories/Velox/ 樣本流處理框架(jia) / 特征存(cun)儲(chu)等;
后續我們也(ye)會針對一些(xie)核心場景添加新的(de)協議(yi)，用(yong)戶也(ye)可以(yi)基(ji)于(yu) Fury 的(de)序列化能力構建自己的(de)協議(yi)。
Java 序列化
由(you)于 Java 在大(da)數據、云原生、微服(fu)務和企業(ye)級應用的(de)廣泛使用，對 Java 序列化的(de)性能(neng)優化可以大(da)幅(fu)降低(di)系統延遲(chi)，提升吞(tun)吐率(lv)，降低(di)服(fu)務器成(cheng)本。
因此(ci) Fury 針對 Java 序列化進行了大量極致(zhi)性能(neng)優化，我們的(de)實(shi)現具備以下能(neng)力：
極致性能(neng)：通過利用 Java 對象的類(lei)型(xing)和泛型(xing)信息(xi)，結合(he) JIT 編譯、Unsafe 低階操作，Fury 相(xiang)比 JDK 最高有 170 倍的性能(neng)提升，相(xiang)比 Kryo/Hessian 最高有 50~100 倍的性能(neng)提升。
100% JDK 序列化 API 兼(jian)容性：支持(chi)了所(suo)有(you) JDK 自定義序列化方(fang)法 writeObject/readObject/ writeReplace/ readResolve/readObjectNoData 的語(yu)義，保(bao)證(zheng)任(ren)意場景替(ti)換 JDK 序列化的正確性。而(er)已有(you)的 Java 序列化框架如 Kryo/Hessian 在這些(xie)場景，都(dou)存(cun)在一定的正確性問題
類型前后(hou)兼容(rong)：在反序列化端和序列化端 Class Schema 不一致(zhi)時，仍然可以正確反序列化，支持應用(yong)獨立(li)(li)升級部(bu)署，獨立(li)(li)增刪字段。并且(qie)我們對元數(shu)據進行(xing)了極致(zhi)的(de)壓縮(suo)和共(gong)享，類型兼容(rong)模式相比(bi)類型強一致(zhi)模式做到(dao)了幾乎沒有任何性能損失。
元數(shu)據(ju)共(gong)享：在某個上(shang)下(xia)(xia)文(wen) (TCP 連接) 下(xia)(xia)多次(ci)序列(lie)化(hua)之間共(gong)享元數(shu)據(ju)(類(lei)(lei)名稱(cheng)(cheng)、字(zi)段名稱(cheng)(cheng)、Final 字(zi)段類(lei)(lei)型(xing)信(xin)息等)，這些信(xin)息會在該(gai)上(shang)下(xia)(xia)文(wen)下(xia)(xia)第(di)一次(ci)序列(lie)化(hua)時發送到對端，對端可(ke)以(yi)根據(ju)該(gai)類(lei)(lei)型(xing)信(xin)息重建相同的反序列(lie)化(hua)器，后續(xu)序列(lie)化(hua)可(ke)以(yi)避免傳輸元數(shu)據(ju)，減小(xiao)網絡流量(liang)壓力，同時也自動支(zhi)持類(lei)(lei)型(xing)前后兼(jian)容。
零拷(kao)貝(bei)支持(chi)：支持(chi) Out of band 零拷(kao)貝(bei)和(he)堆外內存讀寫。
跨語言對象圖序列化
跨語言對(dui)象(xiang)圖序(xu)列化主要用于對(dui)動態性(xing)和易用性(xing)有更高要求(qiu)的場景。盡管(guan) Protobuf/Flatbuffer 等框架提供(gong)了多(duo)語言序(xu)列化能力，但(dan)仍然(ran)存在一些不足：
需要提前編寫(xie) IDL 并靜態(tai)編譯(yi)生成(cheng)代碼，不具備(bei)足夠的動態(tai)性(xing)和靈活性(xing);
生成的類不符合面(mian)向對(dui)(dui)象(xiang)設計(ji)也無法給類添加(jia)行為(wei)，并不能作為(wei)領域對(dui)(dui)象(xiang) 直接用于多語言應(ying)用開發。
不(bu)支持(chi)子類序列化(hua)。面向(xiang)對象(xiang)(xiang)(xiang)編程(cheng)(cheng)的(de)主(zhu)要(yao)特(te)點(dian)是通(tong)過接口調用(yong)子類方法(fa)(fa)。這類模式也無法(fa)(fa)得(de)到很好(hao)的(de)支持(chi)。盡管 Flatbuffer 提(ti)供(gong)了(le)(le) Union，Protobuf 提(ti)供(gong)了(le)(le) OneOf/Any 特(te)性(xing)，這類特(te)性(xing)需要(yao)在序列化(hua)和(he)反(fan)序列化(hua)時判斷對象(xiang)(xiang)(xiang)的(de)類型(xing)，不(bu)符合面向(xiang)對象(xiang)(xiang)(xiang)編程(cheng)(cheng)的(de)設計。
不支(zhi)持循環和共享引用(yong)，需要針(zhen)對(dui)領域(yu)對(dui)象(xiang)重新定義一套 IDL 并自己實現引用(yong)解析，然(ran)后在每種語言里(li)面編寫代(dai)碼實現領域(yu)對(dui)象(xiang)和協議對(dui)象(xiang)之間的相互轉換，如果對(dui)象(xiang)圖(tu)嵌套層(ceng)數較深，則需要編寫更多的代(dai)碼。
結合以上幾點，Fury 實現了一套跨語言的對象圖序列化協議：
多(duo)語(yu)言(yan) / 跨(kua)語(yu)言(yan) 自動序列(lie)化任意對象(xiang)：在(zai)序列(lie)化和反序列(lie)化端定義兩個 Class，即可自動將一種(zhong)語(yu)言(yan)的對象(xiang)自動序列(lie)化為另一種(zhong)語(yu)言(yan)的對象(xiang)，無需創(chuang)建 IDL 文(wen)件(jian)、編(bian)譯(yi) schema 生成(cheng)代碼(ma)以(yi)及手寫(xie)轉(zhuan)換(huan)代碼(ma);
多語言 / 跨語言自動序列化共享引用和循環引用;
支持對象類(lei)型(xing)多態(tai)，符(fu)合(he)面向對象編(bian)程范式，多個(ge)子(zi)類(lei)型(xing)對象可以同時(shi)被自動(dong)反(fan)序列化(hua)，無需用戶手動(dong)處理;
同時(shi)我(wo)們(men)在這套協(xie)議上(shang)面(mian)也支持了(le) Out of band 零拷貝;
自動跨語言序列化示例：
行存序列化
對(dui)于高(gao)性能(neng)計算(suan)和(he)大規模數(shu)據(ju)(ju)(ju)傳輸場景，數(shu)據(ju)(ju)(ju)序列(lie)化和(he)傳輸往往是(shi)整(zheng)個(ge)系統的性能(neng)瓶頸。如果用戶(hu)只需要讀取部分數(shu)據(ju)(ju)(ju)，或(huo)者根據(ju)(ju)(ju)對(dui)象(xiang)某個(ge)字段進(jin)行(xing)過濾，反序列(lie)化整(zheng)個(ge)數(shu)據(ju)(ju)(ju)將(jiang)帶來額外開銷。因此 Fury 也提供了一套二(er)(er)進(jin)制數(shu)據(ju)(ju)(ju)結構，在二(er)(er)進(jin)制數(shu)據(ju)(ju)(ju)上(shang)直讀直寫，避開序列(lie)化。
Apache arrow 是一個(ge)成(cheng)熟的列(lie)存(cun)格式(shi)，支持二進制讀(du)寫。但(dan)列(lie)存(cun)并不能滿足(zu)所有場(chang)景(jing)需求，在線鏈路和(he)流式(shi)計算場(chang)景(jing)的數(shu)據天(tian)然就(jiu)是行存(cun)結(jie)構，同時(shi)列(lie)式(shi)計算引(yin)擎內部在涉及到(dao)數(shu)據變更和(he) Hash/Join/Aggregation 操作時(shi)，也會使用到(dao)行存(cun)結(jie)構。
而行存并沒有一個統一標(biao)準實現，計算引擎如 Spark/Flink/Doris/Velox 等都定義(yi)了一套行存格(ge)式(shi)，這些格(ge)式(shi)不(bu)支(zhi)持跨語言(yan)，且只能被(bei)自己引擎內(nei)部使(shi)用，無(wu)法用于其它框架(jia)。盡管 Flatbuffer 能夠(gou)支(zhi)持按(an)需反序列化，但需要靜(jing)態編譯(yi) Schema IDL 和管理 offset，無(wu)法滿足復(fu)雜(za)場(chang)景的動態性(xing)和易用性(xing)需求。
因此 Fury 在早期借鑒(jian)了 spark tungsten 和 apache arrow 格式(shi)，實(shi)現(xian)了一套可以隨機(ji)訪問的二進制(zhi)行存結構(gou)，目前實(shi)現(xian)了 Java/Python/C++ 版本，實(shi)現(xian)了在二進制(zhi)數據上面直讀(du)直寫，避免(mian)掉了所有序列化開銷。
下圖(tu)是 Fury Row Format 的二進制格式：
該(gai)格式密集(ji)存(cun)儲(chu)，數(shu)據(ju)對齊，緩存(cun)友好，讀寫(xie)更快。由于(yu)避免了反序列化(hua)，能夠減少 Java GC 壓力(li)。同時降低 Python 開銷(xiao)，同時由于(yu) Python 的(de)動態性(xing)，Fury 的(de)數(shu)據(ju)結構(gou)實現了 _getattr__/getitem/slice/ 和(he)其它特殊方法，保證了行為跟 python dataclass/list/object 的(de)一(yi)致性(xing)，用(yong)戶沒有任何感知。
性能對比
這里給出部分 Java 序列化性(xing)能數(shu)據，其中標題包(bao)含 compatible 的圖(tu)表是支持(chi)類型前(qian)后兼容下的性(xing)能數(shu)據，標題不包(bao)含 compatible 的圖(tu)表是不支持(chi)類型前(qian)后兼容下的性(xing)能數(shu)據。為了(le)公平起見，所有測試 Fury 關閉了(le)零拷(kao)貝特(te)性(xing)。
