Over a million developers have joined DZone.

Avoiding Java Serialization to increase performance

DZone's Guide to

Avoiding Java Serialization to increase performance

· Java Zone
Free Resource

Try Okta to add social login, MFA, and OpenID Connect support to your Java app in minutes. Create a free developer account today and never build auth again.

Many frameworks for storing objects in an off-line or cached manner, use standard Java Serialization to encode the object as bytes which can be turned back into the original object.

Java Serialization is generic and can serialise just about any type of object.

Why avoid it

The main problem with Java Serialization is performance and efficiency. Java serialization is much slower than using in memory stores and tends to significantly expand the size of the object. Java Serialization also creates a lot of garbage.

Access performance

Say you have a collection and you want to update a field of many elements. Something like

for (MutableTypes mt : mts) {

If you update one million elements for about five seconds how long does each one take.

Huge Collection update one field, took an average 5.1 ns.
List<JavaBean> update one field took an average 6.5 ns.
List with Externalizable update one field took an average 5,841 ns.
List update one field took an average 23,217 ns.

If you update ten million elements for five seconds or more

Huge Collection update one field, took an average 5.4 ns.
List, update one field took an average 6.6 ns.
List with readObject/writeObject update one field took an average 6,073 ns.
List update one field took an average 22,943 ns.

Huge Collection stores information in a column based based, so accessing just one field is much more CPU cache efficient than using JavaBeans. If you were to update every field, it would be about 2x or more times slower.

Using an optimised Externalizable is much faster than the default Serializable, however is it 400x slower than using a a JavaBean

Memory efficiency

The per object memory used is also important as it impacts how many object you can store and the performance of accessing those objects.

Collection type Heap used
per million
Direct memory
per million
Garbage produced
per million
Huge Collection 0.09 MB 34 MB 80 bytes
List<JavaBean> 68 MB none 30 bytes
List<byte[]> using Externalizable 140 MB none 5,941 MB
List<byte[]> 506 MB none 16,746 MB
This test was performed on a collection of one million elements.

To test the amount of garbage produced I set the Eden size target than 15 GB so no GC would be performed.
-mx22g -XX:NewSize=20g -XX:-UseTLAB -verbosegc


Having an optimised readExternal/writeExternal can improve performance and the size of a serialised object by 2-4 times, however if you need to maximise performance and efficiency you can gain much more by not using it.


From http://vanillajava.blogspot.com/2011/08/avoiding-java-serialization-to-increase.html

Build and launch faster with Okta’s user management API. Register today for the free forever developer edition!


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}