Multiton design pattern

The Multiton pattern is a design pattern similar to the singleton, which allows only one instance of a class to be created. The Multiton pattern expands on the singleton concept to manage a map of named instances as key-value pairs.

Rather than having a single instance per virtual machine, the Multiton pattern instead ensures a single instance per key. The key must not be a String, it is handy to define it as an enumeration. Using enumeration as Multiton key limits the number of possible elements in the hash, therefore eliminates the greatest risk of using the Multiton pattern, namely the memory leak. 

The pattern can be used when

• creating an object requires more effort, than storing it.
• some, but not too many instances of the given class should exists in the application
• instances should be created at the first demand
• instances should be accessible centrally

Advantages

• The pattern simplifies retrieval of shared objects in an application. Instances of the class should be accessed globally, via static getInstance method of the class.
• Makes it possible to store structures with high creation cost in the memory. If creation of the structure requires data reading, and high amount of calculation, it worth not to throw them away after once created, but store them in a Multiton structure.
  
  
• Possible examples can be like representation of domain specific configuration data

Disadvantages

• Memory leak. As object instances once created, are constantly referenced from the Multiton map, they can not be subject of garbage collection, until the end of the application. Therefore I would not recommend using Multiton for a set of objects with dynamic number of elements. 
    
• as with many creational pattern, Multiton introduces a global state, therefore makes it more complicated to test the application. 
  
  
• Makes dependency handling of related unit tests more complicated. If the constructor is private, and can be used only from inside the class, a more sophisticated mocking is necessary.

Examples of usage

• Storing database connection properties in a Multiton structure. If a predefined number of connections are used for the enterprise application, with well separated domains (Like HR database, Inventory database, Customer database, etc.) all connection information can be stored in a ConnectonProperties class. Instead of creating a ConnectonProperties instance every time, when a connection pool needs to be created, or a new element needs to be added to the pool, they can be stored in a Multiton structure. 
  A ConnectonProperties will be read only on demand, and stored from that point of time on, till end of the application.
• When implementing a GUI table, with requirement of showing detail view of the selected element, you can store detailed record information in a Multitone structure. The Multiton will be contain a dynamically growing set of data, therefore it is afforded to implement a feature to remove long time not used elements from the structure. 

Sources
http://www.blackwasp.co.uk/Multiton.aspx
https://en.wikipedia.org/wiki/Multiton_pattern
http://gen5.info/q/2008/07/25/the-multiton-design-pattern