Warum faule Instanziierung der MessageresourcesFactory in Streben 1.2.7?

Question

Da es das Problem mit doppelter Überprüfung gibt, müssen wir die Synchronisation verwenden, um den gleichzeitigen Zugriff auf die folgende Methode zu gewährleisten (org.apache.struts.util.Messageresources-Klasse):

Faule Instanziierung

public synchronized static MessageResources getMessageResources(String config) {

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

    return defaultFactory.createResources(config);
}

Warum nicht verwenden:

Eifrige Instanziierung

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);
    }

}

Und dann:

public static MessageResources getMessageResources(String config) {

    return defaultFactory.createResources(config);
}

Dies würde einen gleichzeitigen Zugriff auf die Methode ermöglichen GetMessageresources, die zumindest in meinem Fall einige Male bezeichnet werden kann.

Die Auswirkungen bei der Nichtverwendung von Synchronisierungen sind hier:

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

Answer 1

Ich denke, es ist eine Möglichkeit für Struts, sicherzustellen, dass es im Multi-Thread-Modus einwandfrei funktioniert, unabhängig davon, ob die Person org.apache.struts.util.Messageresources überschreitet, definiert CreateResources (String-Konfiguration) als synchronisiert oder nicht.

Answer 2

Ist MessageResourcesFactory Thread-Safe? Das synchronized Methode schützt sowohl die Einstellung des Feldes als auch die createResources Methodenaufruf. Wenn es sich um eine Gewinde handelt, kann die Sperre bewegt werden, um das Feld zu setzen, und lassen Sie die Methode außerhalb des kritischen Abschnitts.

Answer 3

Der Overhead, der durch synchronisierte Methoden auf einem modernen JVM entstanden ist, ist so klein, dass sie unbedeutend werden. Nachfolgende Aufrufe der synchronisierten Fabrikmethode für Lazy-Init sind so gut wie schnell wie Aufrufe einer unsynchronisierten Eier-Init-Methode.

In Bezug auf den Code ist der Lazy-Init-Ansatz einfacher und einfacher zu verstehen (meiner Meinung nach) als die Verwendung eines statischen Initialisierungsblocks. Wenn statische Init -Blöcke scheitern, kann es sehr verwirrend sein, herauszufinden, wo und warum.

Answer 4

Es sei denn, es gibt einen Grund MessageResourceFactory Kann nicht frühzeitig initialisiert werden (z. B. müssen bestimmte Servlet -Ressourcen zuerst initialisiert werden), ich denke, ich mag Ihre Lösung besser. Ich würde vermuten, dass es keinen Grund für das Struts -Team gibt, die Fabrik trägt zu laden.

Haben Sie versucht, einen Fehlerbericht einzureichen und Ihre Lösung vorzuschlagen?