+6  A: 

No... serialization is a way to write or read a representation of an object's state as a byte array. It is not an alternative in-memory representation. An object's serialized form may or may not consume more bytes than it does inside the JVM; typically it would be quite comparable. In rare cases it could be more, and sometimes an object's state can be completely serialized in a way that consumes fewer bytes than it does on the heap. But no to answer the question it is not a "tool to shrink memory footprint".

Sean Owen
A: 

With object serializations, the values of all (non-transient) fields and some additional management data are written to a buffer (stream). The usual intention is to write this buffer to a file or a socket. The serialized objects are not affected.

So in fact it's vice versa: serialization (temporarily) increases the memory footprint, because the serialized representation of the object will reside in memory too.

Andreas_D
A: 

Serialization is not conserned with shrinking memory footprint anyhow, its basically the process of saving an object's state to a sequence of bytes, and rebuilding those bytes into a live object at some future time. It is mainly used to store the objects state so that they can be used beyond the life time of thr virtual machine, the object can be reconstrcuted and used when and where required.

Nidhi
A: 

I say MAY BE YES (if shrink == grow / increase), because serialization conserve the representation of object in memory during it's process.

If you want to stop that, you need to call close or reset on the ObjectOutputStream.

If you call new ObjectOutputStream / close, there is no footprint on memory, after the close.

Istao
+1  A: 

The only way it could shrink memory footprint is by serializing some object with transient fields, dumping the original objects and deserializing - this way you lost objects in transient fields.

binary_runner
+1  A: 

My question is, whether it is a good tool to decrease the memory usage.

No it is not a good tool for doing that. The serialized object representation includes a lot of 'metadata' that describes the type and representation of the object. Unless you serialize a significant number of objects into one 'stream', the 'metadata' overhead will make the serialized form larger than the original form. Ignoring this overhead, the serialized representation is typically more compact, but the saving will depend to a considerable extent on the object's representation types. (Take a look at the "Object Serialization Stream Protocol" for more details.)

And as other answers mention, you temporarily increase memory usage while serializing and deserializing because you have to hold both the serial and object representations AND the map used for dealing with cycles, etc.

If you want to represent a data structure in a compact form in memory, you would be better off developing your own application-specific serialization scheme. But IMO, it would be better still to write the data to the file system or a database.

Stephen C
Indeed may tests parallel to this questions seemed to reveal, that the object structure has to be larger/more complex than a certain threshold. Then the memory reduction pays off against the relatively large meta-data overhead. I therefore choosed this answer as correct. Thanks.
Peter Wippermann