Lazy initialization design pattern

Creational design pattern

"... lazy initialization is the tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed."

Lazy init can be triggered by

• calling the assessor method of an object
• started at a low priority background thread at application startup
• started by a job

It is a good tactic to have a central class, responsible for lazy initialized objects in the application. It is usually a singleton class, that creates and stores the object target for the lazy init.

Advantages

• Makes it possible to initialize an object just when it is required by a client.
• Makes startup time of the application shorter.
• Can save resources, like database connections, opened files or memory.

Risks

• In multi-threading environment a special care needs to be taken in order to avoid multiple instantiation of the object. It can be inconvenient, or can cause a serious performance problems in the system. Therefore can be used for attacking your system.
• As for all optimization, it is true, that you need to implement it, if it solves a real performance problem. Try to avoid eager optimization, before even facing the problem.
• Like it is easily to experiment with JPA, you need to be careful when defining the amount of objects, created by lazy initialization or amount of effort to be spent on it. You can easily load to much at the same time.    
• During debugging, the lazy init can take place, triggered by the debugger. Therefore, the application can behave different than under normal circumstances.     

Real word examples

• JPA lazy initialization for collection of related objects.
• Database pools or any resource pool, where a resource is complicated and time consuming to be build.
• LoadingCache in Google Guava project. The cache loads a new element, after it was first requested, and not found among the cached objects. 

My implementations

1. I have created a small application, that provided data to our company Avatar server. The data shown in Avatar was synchronized with different user directories of the company, like Active Directory, JIRA Crowd, Corparate Directory and LDIF. The domain object called User contained two profile pictures, one with small and another one with big resolution. The small one was used in user lists, and in some other places. As the big one was used relatively rare, it was not loaded into the User object until it was really needed.  
   User objects were stored in a memory cache, with limited capacity, so not more needed Users were purged from the memory after defined time of inactivity. Also the user object and the image inside of it were both subjects of lazy initialization.  
2. I had to check if input values from a Confluence macro contain any html tags, and remove them if so. As it was not possible either to use any Confluence utility or install the OWASP packages under the plug-in, I implemented a small class to sanitize the input strings. It used a lots of Patterns to find tags to be removed. The pattern objects were initialized at the first usage, and stored in a static list.  

Sources
https://en.wikipedia.org/wiki/Lazy_initialization
http://www.martinfowler.com/bliki/LazyInitialization.html