Answer

Historically, lazy initialization emerged to optimize resource usage, when an object is created only when it is actually needed. This was originally important when working with heavy objects, connections, caches, or when implementing complex patterns (e.g., Singleton).

The problem is that if all resources are created at once, it can lead to wasted memory, time, and power even when the object is not needed. Lazy initialization addresses the issue of "deferred" creation.

The solution is usually implemented by checking: if the object is not yet created, we create it, otherwise, we return the existing one.

Code example:

public class LazyHolder {
    private Resource resource;

    public Resource getResource() {
        if (resource == null) {
            resource = new Resource();
        }
        return resource;
    }
}

In multithreaded contexts, synchronization is necessary.

Key features:

Allows resource savings
Requires special attention to thread safety
Often used with Singleton, cache, proxy

Trick questions.

Is Double-Checked Locking a reliable implementation for lazy initialization of Singleton?

Only since Java 5, as earlier the memory model did not guarantee it. It is necessary to use the volatile keyword for the resource field.

private volatile Resource resource;

public Resource getResource() {
    if (resource == null) {
        synchronized(this) {
            if (resource == null) {
                resource = new Resource();
            }
        }
    }
    return resource;
}

Is there any point in doing lazy initialization for lightweight objects?

Generally, no. It is better to create "light" objects immediately to maintain code readability and avoid complicating it with unnecessary logic.

Does lazy initialization work with object serialization?

Not always. During serialization, the "old" state may be restored, or additional logic may be required in readObject().

Typical mistakes and anti-patterns

Lack of thread safety when accessing lazily initialized fields
Applying lazy initialization to cheap resources — complicating the code
Initialization loops (recursive calls)

Real-life example

Negative case

In a high-load service, a special pool of objects was parsed lazily but was not synchronized. Two threads simultaneously initialized the object, leading to memory leaks and unpredictable errors.

Pros:

Fast startup
Fewer resources when testing

Cons:

Unsafe in multithreaded environments
Difficulty in reproducing bugs

Positive case

In a large web application, analytics is connected only through an API call via a lazily initialized proxy object with double-checked locking.