El patrón singleton tiene las siguientes características:
1. Una clase singleton solo puede tener una instancia.
2. Una clase singleton debe crear su propia instancia única.
3. La clase singleton debe proporcionar esta instancia a todos los demás objetos.
El patrón singleton garantiza que solo haya una instancia de una clase, crea una instancia de sí mismo y proporciona esta instancia a todo el sistema. En los sistemas informáticos, los grupos de subprocesos, cachés, objetos de registro, cuadros de diálogo, impresoras y objetos de controladores de tarjetas gráficas suelen diseñarse como singletons. Todas estas aplicaciones tienen más o menos la funcionalidad de los administradores de recursos. Cada computadora puede tener varias impresoras, pero solo puede haber un administrador de trabajos de impresión para evitar que dos trabajos de impresión se envíen a la impresora al mismo tiempo. Cada computadora puede tener varios puertos de comunicación, y el sistema debe administrar estos puertos de comunicación de manera centralizada para evitar que dos solicitudes llamen a un puerto de comunicación al mismo tiempo. En resumen, el propósito de elegir el modo singleton es evitar estados inconsistentes y evitar políticas a largo plazo.
Primero, veamos una implementación singleton clásica.
Copie el código de código de la siguiente manera:
clase pública Singleton {
Singleton estático privado UniqueInstance = nulo;
singleton privado() {
// Existe sólo para derrotar la creación de instancias.
}
getInstance Singleton estático público () {if (instancia única == nulo) {
instancia única = nuevo Singleton();
}
devolver instancia única;
}
// Otros métodos...
}
Singleton evita que se creen instancias externas de la clase al limitar el método de construcción a privado. Dentro del alcance de la misma máquina virtual, solo se puede acceder a la única instancia de Singleton a través del método getInstance (). (De hecho, es posible crear una instancia de una clase con un constructor privado a través del mecanismo de reflexión de Java, que básicamente invalidará todas las implementaciones singleton de Java. Este problema no se discutirá aquí. Supongamos que el mecanismo de reflexión no existe).
Sin embargo, la implementación anterior no considera problemas de seguridad de subprocesos. La llamada seguridad de subprocesos significa: si hay varios subprocesos ejecutándose al mismo tiempo en el proceso donde se encuentra su código, estos subprocesos pueden ejecutar este código al mismo tiempo. Si los resultados de cada ejecución son los mismos que los de las ejecuciones de un solo subproceso y los valores de otras variables son los mismos que los esperados, es seguro para subprocesos. En otras palabras: la interfaz proporcionada por una clase o programa es una operación atómica para subprocesos o cambiar entre múltiples subprocesos no causará ambigüedad en los resultados de ejecución de la interfaz, lo que significa que no necesitamos considerar problemas de sincronización. Obviamente, la implementación anterior no cumple con los requisitos de seguridad de subprocesos y es probable que aparezcan varias instancias de Singleton en un entorno concurrente.
Copie el código de código de la siguiente manera:
// Clase singleton de estilo hambriento. Cuando se inicializa la clase, se crea una instancia de ella misma.
clase pública Singleton1 {
//Constructor privado predeterminado
singleton1 privado() {}
//Ya instanciado por sí mismo
singleton1 final estático privado single = new Singleton1();
//método de fábrica estático
público estático Singleton1 getInstance() {
volver soltero;
}
}
// Clase singleton diferida. Crea una instancia cuando se llama por primera vez.
clase pública Singleton2 {
//Constructor privado predeterminado
singleton2 privado() {}
//Nota, aquí no hay final
Singleton2 estático privado single=null;
//método de fábrica estático
público sincronizado estático Singleton2 getInstance() {
si (único == nulo) {
único = nuevo Singleton2();
}
volver soltero;
}
}