[concurrency-interest] Concurrent Serialization Pattern

Thomas Hawtin tackline at tackline.plus.com
Thu Sep 14 14:23:12 EDT 2006

Kevin Condon wrote:
> And viola!  There's the pattern.  I'd summarize the principles this way:
> 1. Make locks immutable fields, using the final modifier and rely on
> the default serialization handling to create the necessary
> happens-before relationships for lock field value visibility.  (See
> JLS 17.5.3.)
> 2. Use a custom serialization form (see Effective Java, Item 55) and
> make sure to create happens-before relationships on all
> serialized/deserialized fields by using the same locking required for
> ordinary run-time access.

In 1.6, java.util.Random (resetSeed method) uses sun.misc.Unsafe to poke 
it's final, (effectively) transient seed field. Not something I would 
generally recommend.

If you don't have to worry about a serialisable base class, then it 
might be simpler just to introduce a non-serialisable, package private 
base class.

abstract class SerialBase { // Must not implement Serializable
     final ReadWriteLock lock = new ReentrantReadWriteLock();

     SerialBase() {

public class Serial extends SerialBase implements Serializable {
     private static final long serialVersionUID = 2006091401L;

     private int x;

     private void writeObject(
         ObjectOutputStream out
     ) throws IOException {
         try {
         } finally {
     private void readObject(
         ObjectInputStream in
     ) throws IOException, ClassNotFoundException {
         try {
         } finally {

Tom Hawtin

More information about the Concurrency-interest mailing list