¿Por qué instancias perezoso de la MessageResourcesFactory en Struts 1.2.7?

Question

Dado que no es el doble comprobación problema de bloqueo hasta que tenemos que utilizar la sincronización para garantizar el acceso simultáneo a la siguiente clase (org.apache.struts.util.MessageResources) Método:

LAZY instanciación

public synchronized static MessageResources getMessageResources(String config) {

    if (defaultFactory == null) {
        defaultFactory = MessageResourcesFactory.createFactory();
    }

    return defaultFactory.createResources(config);
}

¿Por qué no usar:

instanciación EAGER

static {

    // Construct a new instance of the specified factory class
    try {
        if (clazz == null)
            clazz = RequestUtils.applicationClass(factoryClass);
        MessageResourcesFactory defaultFactory =
            (MessageResourcesFactory) clazz.newInstance();
    } catch (Exception e) {
        LOG.error("MessageResourcesFactory.createFactory", e);
    }

}

Y a continuación:

public static MessageResources getMessageResources(String config) {

    return defaultFactory.createResources(config);
}

Esto permitiría el acceso concurrente a los getMessageResources método que al menos en mi caso se le puede llamar unas cuantas veces.

Las consecuencias cuando no se utiliza sincronizados están aquí:

http://en.wikipedia.org/wiki/Double-checked_locking

Answer 1

Creo que es una forma de puntales para asegurarse de que funciona bien cuando está en modo multi-hilo, no importa si la persona anulando org.apache.struts.util.MessageResources define createResources (Configuración de la secuencia) como sincronizado o no .

Answer 2

Es MessageResourcesFactory flujos seguros? El método synchronized protege tanto la configuración del campo y la llamada al método createResources. Si es seguro para subprocesos del bloqueo podría ser movido a cubrir sólo la creación del campo y dejar la llamada al método fuera de la sección crítica.

Answer 3

La sobrecarga producida por métodos sincronizados en una JVM moderno es tan pequeña como para ser insignificante. llamadas posteriores al método de fábrica perezosa-init sincronizada serán casi tan rápido como lo haría llama a un método ansiosos-init no sincronizada.

En términos de código, el enfoque perezoso-init es más simple y más fácil de entender (en mi opinión) que el uso de un bloque inicializador estático. Además, cuando los bloques de inicialización estática fallan, puede ser muy confuso para averiguar dónde y por qué.

Answer 4

A menos que haya alguna razón el MessageResourceFactory no se puede inicializar desde el principio (por ejemplo, necesita ser inicializado primero ciertos recursos servlet), creo que me gusta su solución mejor. Me imagino que no hay razón para el equipo de puntales para cargar con pereza la fábrica aparte de que eso es lo que el desarrollador en particular los que trabajaron en esto se utiliza para hacer (la gente tiende a cargar con pereza únicos, incluso cuando no es necesario).

Ha intentado enviar un informe de error, y proponer su solución?