W przypadku serializacji obiektu Java chciałbym przetestować różnicę między użyciem JSON a ogólnymi narzędziami do serializacji pod względem wydajności czasowej i przestrzennej.
json wybiera fastjson.
Narzędzie do serializacji korzysta z Protostuff i Kyro. Dlaczego nie użyć protobufu? Bo uważam, że dla klasy Java z setkami istniejących właściwości tworzenie nowego dopasowanego pliku proto jest trochę antyludzkie. Protostuff to ulepszona wersja Protobuf, która pozwala bezpośrednio serializować obiekt Java, używając go trochę jak Kyro, bez tylu procesów pośrednich jak Protobuf. Inne, jak Hession, Java z serializacją itd., mają znacznie gorszą wydajność niż Kryo i Protobuf, więc nie wiem, czego się spodziewać.
Po prostym teście okazało się, że luka jest dość widoczna, więc uznałem, że nie ma potrzeby przeprowadzania konkretnej oceny. Wytnij akapit z dziennika i wyślij go, wszyscy to czują.
koszt czasu to System.nanoTime(); Wszystkie trzy są domyślnymi konfiguracjami bez żadnej konfiguracji.
Powierzchnia po serializacji jest nieco mniejsza niż w protostuff, a oba są znacznie większe niż w JSON. To łatwe do zrozumienia, w końcu ciągi jsonów są czytelne, nie wymuszaj zbyt wiele.
Czas potrzebny na serializację i deserializację jest lepszy niż w Kyro w porównaniu do FastJSON, a różnica jest dość oczywista.
Podsumowując, jeśli nie ma bardzo wymagających wymagań dotyczących przestrzeni, Protostuff może być najlepszym wyborem. Protostuff ma dodatkową przewagę nad Kyro, czyli jeśli klasa Java dodaje pola po serializacji i przed deserializacją (co jest nieuniknione w prawdziwym biznesie), Kyro będzie bezużyteczny. Jednak protostuff można używać, o ile zostanie dodany na koniec klasy i korzysta z serii sun JDK. Dlatego jeśli serializacja jest stosowana w scenariuszach takich jak cache, a obiekt serializowany musi być przechowywany przez długi czas, możesz wybrać tylko protostuff.
Oczywiście, jeśli jest potrzeba czytelności lub czegoś podobnego, możesz używać tylko json.
|
Opublikowano 15.07.2019 21:16:23
|
|
|
