DEV Community: Kai Sawamoto

Lazy Loading with Virtual Proxy Pattern | Thread-safety and beyond

Kai Sawamoto — Wed, 05 Jul 2023 20:24:06 +0000

What can you learn?

What problem virtual proxy design pattern solves
How the basic virtual proxy pattern works = How to make the pattern thread-safe without compromising fast performance

Prerequisite

Basic understanding of how lambda expression works
Just a little bit of software development experience

What is Virtual Proxy Pattern?

It is a software design pattern used for lazy-loading heavy objects. Let's see an example.

import java.util.*;

interface Image {
    public void displayImage();
}

class RealImage implements Image {
    private String filename;
    public RealImage(String filename) { 
        this.filename = filename;
        loadImageFromDisk();
    }

    private void loadImageFromDisk() {
        // ...
        System.out.println("Loading   "+filename);
    }

    public void displayImage() { System.out.println("Displaying "+filename); }
}

class ProxyImage implements Image {
    private String filename;
    private Image image;

    public ProxyImage(String filename) { this.filename = filename; }
    public void displayImage() {
        if (image == null) {
            image = new RealImage(filename); // Lazy allocation
        }
        image.displayImage();
    }
}

class ProxyExample {
    public static void main(String[] args) {
        Image image1 = new ProxyImage("HiRes_10MB_Photo1");
        Image image2 = new ProxyImage("HiRes_10MB_Photo2");
        Image image3 = new ProxyImage("HiRes_10MB_Photo3");      

        image1.displayImage(); // needs loading
        image2.displayImage(); // needs loading
        image2.displayImage(); // already loaded
        // image3 has not been loaded
    }
}

In the example above, ProxyImage contains a RealImage object. So we can think of it as a placeholder for an RealImage.

But since RealImage instances are heavy weight, we only want to instantiate an actual RealImage instance only when it's needed.

This is what Virtual Proxy pattern solves. A RealImage instance is initialized when and only when displayImage is called.
Simple, right?

What is the problem with Virtual Proxy pattern?

There is one thing that is sadly making the code above unusable. That is, the code has a race condition.

Consider when a multiple threads are running concurrently, and they call displayImage on the same ProxyImage instance at once. Each thread thinks "It's the first time displayImage is called. I need to initialize it!".

This ends up calling the heavy operation many times. In the worst case scenario, the heavy operation could have non-read-only operation, leaving the program in an undefined state.

`synchronized` to the rescue

Java conveniently supports locking with ease, just by using synchronized keyword in the method signature.
We modify displayImage of ProxyImage class as follows:

public synchronized void displayImage() {
        if (image == null) {
            image = new RealImage(filename); // Lazy allocation with thread-safety
        }
        image.displayImage();
    }

Now that we have locking in place, we achieved thread-safety. Yay! ... but it still has another concern.

Performance concern

Although displayImage method is now thread-safe, it suffers performance issue.

After the first call, there will be no mutation of image field of ProxyImage, which means race condition only exists in the first invocation of the method.

To address issue, we can make use of Supplier functional interface of java.

With Supplier

import java.util.*;

interface Image {
    public void displayImage();
}

class ProxyImage implements Image {
    private String filename;
    private Supplier<Image> imageSupplier = () -> loadImage();

    public ProxyImage(String filename) { this.filename = filename; }

    private synchronized Image loadImage() {
        class ImageFactory implements Supplier<Image> {
            private final String filename;
            private final Image imageInstance = new RealImage(filename);
            public ImageFactory(String filename) {
                this.filename = filename;
            }
            public Image get() { return imageInstance; }
        }
        if (!ImageFactory.class.isInstance(imageSupplier)) {
            imageSupplier = new ImageFactory();
        }
        return imageSupplier.get();
    }

    public void displayImage() {
        imageSupplier.get().displayImage();
    }
}

Quite a lot of changes, eh? Let's break down the changes.

`Supplier<Image>`

Supplier is an functional interface with get method that returns an instance of Image
Initially, imageSupplier is a synchronized loadImage function but it gets replaced after the first call

`loadImage`

loadImage instantiates a ImageFactory, which is another image supplier type, defined within loadImage
replaces its supplier field

`ImageFactory`

implements Supplier<Image>
finally instantiates a RealImage object and returns this instance from get method

In a nutshell, the supplier is only synchronized for the first call and it's replaced with a non-synchronized supplier thereafter.

That is it. You made it!
That was quite long of a refactor but certainly makes your code more robust and performant.

Execute Around Method (EAM) Pattern | Design Patterns

Kai Sawamoto — Wed, 05 Jul 2023 02:43:07 +0000

What can you learn?

What problem Execute Around Method design pattern solves
How EAM works

Prerequisite

Basic understanding of how lambda expression works
Just a little bit of software development experience

Why EAM pattern?

It is crucial to close file writers

Have you wrote a code like this and wondered why the file is not being written?

void main() {
    final FileWriterExample writer = new FileWriterExample("peekaboo.txt");
    writer.writeStuff("peek-a-boo");
}

That is because, file writers retain the written content in a buffer, not persisting it right away. Therefore, it is required to close the writer before it flushes the buffer so that we can see the file update.

In addition to that, Java's garbage collector do not take care of releasing external resources such as database and files, which leads to waiting our precious memory.

In order to ensure such resources are released, Execute Around Method (EAM) pattern comes in handy.

(Imperfect) Improvement over the last code

void main(){
    final FileWriterExample writer = new FileWriterExample("peekaboo.txt");
    try  {
        writer.writeStuff("peek-a-boo");
    } finally {
        writer.close();
    }
}

This code now ensures to close the file, even when the writer raises an exception thanks to the finally block.

However, this code is verbose and we need to write the try-finally block every single time we use the writer.

EAM pattern to the rescue

Using EAM pattern the code above can be rewritten as follows:

void write(String fileName, Consumer<FileWriterExample> block)  {
    final FileWriterExample writer = new FileWriterExample(fileName);
    try {
        block.accept(writerEAM);
    } finally {
        writerEAM.close();
    }
}

void main() {
    write("peekaboo.txt", writer -> {
        writer.writeStuff("nice");
        writer.writeStuff("clean");
    });
}

We defined write method, which takes in a filename and a block. block is a type of Consumer, which is a java functional interface. Consumer is basically a function that takes a FileWriterExample class as an input and returns nothing.

As block, we can pass in a function pointer, a method reference, or a lambda expression.
In the example above, it is passing in a lambda expression.
write function takes care of creating a writer and closing it after invoking the code inside block.

The beauty is that inside the body of block, we have a free access to a writer instance without any concerns about cleaning up the resource, no matter how many times we call write.

There you have it. You now know how EAM pattern works.

Another usage

In Java we can use synchronized to make a function thread-safe like so: public synchronized void method() {...}.
This is exactly a realization of EAM pattern.

In stead of creating and closing a file writer, methods marked as synchronized acquire and release a mutex lock at the beginning and the end of the methods' lifetime.

Just food for thoughts.

DEV Community: Kai Sawamoto

Lazy Loading with Virtual Proxy Pattern | Thread-safety and beyond

What can you learn?

Prerequisite

What is Virtual Proxy Pattern?

What is the problem with Virtual Proxy pattern?

synchronized to the rescue

Performance concern

With Supplier

Supplier<Image>

loadImage

ImageFactory

Execute Around Method (EAM) Pattern | Design Patterns

What can you learn?

Prerequisite

Why EAM pattern?

It is crucial to close file writers

(Imperfect) Improvement over the last code

EAM pattern to the rescue

Another usage

`synchronized` to the rescue

`Supplier<Image>`

`loadImage`

`ImageFactory`