Este artículo analiza cómo el patrón Singleton impone que solo se produzca una única instancia de una clase y que exista durante la vida útil de una aplicación.

¿Qué es?

Un singleton es un patrón de diseño utilizado para crear la única instancia de clase. El patrón Singleton generalmente se usa cuando hay varios ejemplos en los que solo debe existir una única instancia de una clase y se debe aplicar la restricción. Por ejemplo, las memorias caché, los grupos de subprocesos y los registros solo deben tener una instancia.

Haga que el constructor sea privado para garantizar que solo se cree un objeto de clase. De esa forma, solo los miembros de la clase pueden acceder al constructor privado y nadie más.

En el mundo real, el patrón Singleton garantiza que solo exista una única instancia de clase y ofrece un punto de acceso global a ella.

Diagrama de clase

El diagrama de clases contiene sólo una entidad.

único

Ejemplo

Digamos que queremos modelar el avión oficial del presidente estadounidense llamado Airforce One en nuestro software. La clase Singleton es la representación más adecuada para una entidad con una sola instancia.

Aquí está el código para nuestra clase singleton:

Multihilo y Singleton

Este código funciona siempre que la aplicación sea de un solo subproceso. Sin embargo, si varios subprocesos acceden a esta clase, existe la posibilidad de que se creen varios objetos.

Por ejemplo:

• El subproceso A llama al método getInstancey encuentra que onlyInstancees nulo; sin embargo, antes de que pueda crear una instancia, se cambia de contexto.
• Ahora aparece el subproceso B y llama a getInstance, que devuelve el AirforceOneobjeto.
• Si el subproceso A se vuelve a programar, comienza la travesura. El subproceso ya pasó la verificación de la condición if-null y procederá a crear un nuevo AirforceOneobjeto y asignárselo a onlyInstance. Ahora hay dos AirforceOneobjetos diferentes en la naturaleza, uno con el hilo A y otro con el hilo B.

• Al agregar synchronizedal getInstance()método, puede lograr la seguridad de subprocesos.

• Otra opción es inicializar la instancia de forma estática, garantizando que sea segura para subprocesos.

Bloqueo de doble verificación

Hay dos problemas significativos con los enfoques descritos anteriormente: la sincronización es costosa y la inicialización estática crea el objeto incluso si no se usa en una aplicación en particular. Si la creación de objetos es costosa, la inicialización estática puede costarnos rendimiento.

La solución anterior marca la instancia de singleton como volátil. Sin embargo, esta implementación de la volatilemetodología de JVM no funcionará correctamente para el bloqueo de verificación doble y necesitará otro enfoque para crear sus singletons.

El idioma de bloqueo verificado dos veces ahora se considera un antipatrón, y su utilidad ha desaparecido principalmente a medida que los tiempos de inicio de JVM se han acelerado.

Otros ejemplos

La API de Java nos proporciona los siguientes singletons:

java.lang.Tiempo de ejecución

java.awt.Escritorio

Advertencias

Puede subclasificar una clase singleton protegiendo el constructor en lugar de privado. Sin embargo, hay mejores opciones que esta en todas las circunstancias. En estas situaciones, los desarrolladores pueden crear un registro de singletons para todas las subclases. El método getInstance puede tomar un parámetro o usar una variable de entorno para devolver el objeto singleton deseado. El registro mantiene una asignación de nombres de cadena a objetos singleton.

Otros artículos de la serie Patrón de creación

• Patrón de creación: constructor
• Patrón de creación: prototipo
• Patrón de creación: método de fábrica
• Patrón de creación: fábrica abstracta