För serialisering av ett Java-objekt vill jag testa skillnaden mellan att använda JSON och att använda allmänna serialiseringsverktyg när det gäller temporal och rumslig prestanda.
JSON väljer att använda fastjson.
Serialiseringsverktyget använder Protostuff och Kyro. Varför inte använda protobuf? För jag tycker att för en Java-klass med hundratals befintliga egenskaper är det lite anti-mänskligt att skapa en ny matchande proto-fil. Protostuff är en förbättrad version av Protobuf, som låter dig serialisera ett Java-objekt direkt, med hjälp av det lite som Kyro, utan lika många mellanliggande processer som Protobuf. Andra, som Hession, Java med serialisering, etc., sägs ha mycket sämre prestanda än Kryo och Protobuf, så jag vet inte vad jag kan förvänta mig.
Efter ett enkelt test upptäckte jag att gapet var ganska uppenbart, så jag kände att det inte fanns något behov av en specifik utvärdering. Klipp ut ett stycke ur loggen och skicka ut det, alla känner av det.
kostnadstid är System.nanoTime(); Alla tre är standardkonfigurationer utan någon konfiguration. Utrymmesytan efter serialisering är något lägre än för protostuff, och båda är mycket större än JSON. Det här är lätt att förstå, json-strängar är ju läsbara, tvinga inte för mycket. Tiden som krävs för serialisering och deserialisering är bättre än Kyro jämfört med FastJSON, och skillnaden är ganska tydlig.
Så sammanfattningsvis, om det inte finns några extremt krävande krav på utrymme, kan Protostuff vara det bästa valet. Protostuff har en ytterligare fördel jämfört med Kyro, nämligen att om java-klassen lägger till fält efter serialisering och före deserialisering (vilket är oundvikligt i verkliga affärer), så blir Kyro värdelöst. Protostuff kan dock användas så länge det läggs till i slutet av klassen och använder sun series JDK. Därför, om serialisering används i scenarier som cache, och det serialiserade objektet behöver lagras länge, kan du bara välja protostuff.
Självklart, om det behövs läsbarhet eller liknande, kan du bara använda json.
|