Wann und wie soll ich eine Threadlokalvariable verwenden?

StackOverflow https://stackoverflow.com/questions/817856

Frage

Wann sollte ich a verwenden ThreadLocal Variable?

Wie wird es benutzt?

War es hilfreich?

Lösung

Eine mögliche (und übliche) Verwendung ist, wenn Sie ein Objekt haben, das nicht mit Thread-Sicherheit ist, aber Sie vermeiden möchten Synchronisierung Zugriff auf dieses Objekt (ich schaue Sie an, SimpledateFormat). Geben Sie stattdessen jedem Thread eine eigene Instanz des Objekts.

Zum Beispiel:

public class Foo
{
    // SimpleDateFormat is not thread-safe, so give one to each thread
    private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){
        @Override
        protected SimpleDateFormat initialValue()
        {
            return new SimpleDateFormat("yyyyMMdd HHmm");
        }
    };

    public String formatIt(Date date)
    {
        return formatter.get().format(date);
    }
}

Dokumentation.

Andere Tipps

Seit einem ThreadLocal ist ein Hinweis auf Daten innerhalb eines gegebenen Thread, Sie können bei der Verwendung mit Laderletzungen am Ende eingeladen werden ThreadLocals in Anwendungsservern mit Threadpools. Sie müssen sehr vorsichtig sein, wenn Sie alle aufräumen ThreadLocalS du get() oder set() durch Verwendung der ThreadLocal's remove() Methode.

Wenn Sie nicht aufräumen, wenn Sie fertig sind, bleiben alle Referenzen an Klassen, die als Teil eines bereitgestellten WebApp geladen werden, in der permanenter Haufen und wird niemals Müll sammeln lassen. Wiedereinsetzung/Ablagerung des WebApps wird nicht jeweils beseitigt ThreadIch Bezug Thread ist nicht etwas, das Ihrem WebApp gehört. Jede aufeinanderfolgende Bereitstellung wird eine neue Instanz der Klasse schaffen, die niemals Müll gesammelt wird.

Sie werden mit Ausnahmen aus den Speicherausnahmen enden java.lang.OutOfMemoryError: PermGen space Und nachdem ein paar Googeln wahrscheinlich nur zunehmen wird -XX:MaxPermSize Anstatt den Fehler zu reparieren.

Wenn Sie diese Probleme am Ende haben, können Sie feststellen, welcher Thread und welche Klasse diese Referenzen verwenden, indem Sie verwenden Eclipse -Speicheranalysator und/oder durch Folgen Frank Kieviet's Guide und nachverfolgen.

UPDATE: Neu entdeckt Alex Vasseurs Blogeintrag Das hat mir geholfen, einige aufzuspüren ThreadLocal Probleme, die ich hatte.

Viele Frameworks verwenden Threadlocals, um einen Kontext zu erhalten, der sich mit dem aktuellen Thread bezieht. Wenn beispielsweise die aktuelle Transaktion in einem ThreadLocal gespeichert wird, müssen Sie sie nicht als Parameter über jeden Methodenaufruf übergeben, falls jemand den Stapel hinunterzugreifen muss. Webanwendungen können Informationen zur aktuellen Anfrage und Sitzung in einem ThreadLocal speichern, sodass die Anwendung einen einfachen Zugriff auf sie hat. Mit Guice können Sie bei der Implementierung Threadlocals verwenden benutzerdefinierte Bereiche Für die injizierten Objekte (Guice Standardeinstellung Servlet Scopes höchstwahrscheinlich auch sie auch benutzen).

Threadlocals sind eine Art von globalen Variablen (obwohl etwas weniger böse, weil sie auf einen Thread beschränkt sind). Sie sollten daher vorsichtig sein, wenn Sie sie verwenden, um unerwünschte Nebenwirkungen und Speicherlecks zu vermeiden. Entwerfen Sie Ihre APIs so, dass die ThreadLocal -Werte immer automatisch gelöscht werden, wenn sie nicht mehr benötigt werden und dass die falsche Verwendung der API nicht möglich ist (zum Beispiel so was). Threadlocals können verwendet werden, um den Code sauberer zu machen, und in einigen seltenen Fällen sind sie die einzige Möglichkeit, etwas zum Laufen zu bringen (mein aktuelles Projekt hatte zwei solcher Fälle; sie sind dokumentiert hier unter "statischen Feldern und globalen Variablen").

Wenn Sie in Java über ein Datum verfügen, das pro-Thread variieren kann, können Sie das Datum an jede Methode übergeben, die es benötigt (oder möglicherweise benötigt), oder das Datum mit dem Thread zu verknüpfen. Das Übergeben des Datums überall kann praktikabel sein, wenn alle Ihre Methoden bereits eine gemeinsame "Kontextvariable" weitergeben müssen.

Wenn dies nicht der Fall ist, möchten Sie Ihre Methodensignaturen möglicherweise nicht mit einem zusätzlichen Parameter überladen. In einer Nicht-Thread-Welt könnten Sie das Problem mit dem Java-Äquivalent einer globalen Variablen lösen. In einem Thread-Wort ist das Äquivalent einer globalen Variablen eine Thread-lokale Variable.

There is very good example in book Java Concurrency in Practice. Where author (Joshua Bloch) explains how Thread confinement is one of the simplest ways to achieve thread safety and ThreadLocal is more formal means of maintaining thread confinement. In the end he also explain how people can abuse it by using it as global variables.

I have copied the text from the mentioned book but code 3.10 is missing as it is not much important to understand where ThreadLocal should be use.

Thread-local variables are often used to prevent sharing in designs based on mutable Singletons or global variables. For example, a single-threaded application might maintain a global database connection that is initialized at startup to avoid having to pass a Connection to every method. Since JDBC connections may not be thread-safe, a multithreaded application that uses a global connection without additional coordination is not thread-safe either. By using a ThreadLocal to store the JDBC connection, as in ConnectionHolder in Listing 3.10, each thread will have its own connection.

ThreadLocal is widely used in implementing application frameworks. For example, J2EE containers associate a transaction context with an executing thread for the duration of an EJB call. This is easily implemented using a static Thread-Local holding the transaction context: when framework code needs to determine what transaction is currently running, it fetches the transaction context from this ThreadLocal. This is convenient in that it reduces the need to pass execution context information into every method, but couples any code that uses this mechanism to the framework.

It is easy to abuse ThreadLocal by treating its thread confinement property as a license to use global variables or as a means of creating “hidden” method arguments. Like global variables, thread-local variables can detract from reusability and introduce hidden couplings among classes, and should therefore be used with care.

Essentially, when you need a variable's value to depend on the current thread and it isn't convenient for you to attach the value to the thread in some other way (for example, subclassing thread).

A typical case is where some other framework has created the thread that your code is running in, e.g. a servlet container, or where it just makes more sense to use ThreadLocal because your variable is then "in its logical place" (rather than a variable hanging from a Thread subclass or in some other hash map).

On my web site, I have some further discussion and examples of when to use ThreadLocal that may also be of interest.

Some people advocate using ThreadLocal as a way to attach a "thread ID" to each thread in certain concurrent algorithms where you need a thread number (see e.g. Herlihy & Shavit). In such cases, check that you're really getting a benefit!

The documentation says it very well: "each thread that accesses [a thread-local variable] (via its get or set method) has its own, independently initialized copy of the variable".

You use one when each thread must have its own copy of something. By default, data is shared between threads.

Webapp server may keep a thread pool, and a ThreadLocal var should be removed before response to the client, thus current thread may be reused by next request.

  1. ThreadLocal in Java had been introduced on JDK 1.2 but was later generified in JDK 1.5 to introduce type safety on ThreadLocal variable.

  2. ThreadLocal can be associated with Thread scope, all the code which is executed by Thread has access to ThreadLocal variables but two thread can not see each others ThreadLocal variable.

  3. Each thread holds an exclusive copy of ThreadLocal variable which becomes eligible to Garbage collection after thread finished or died, normally or due to any Exception, Given those ThreadLocal variable doesn't have any other live references.

  4. ThreadLocal variables in Java are generally private static fields in Classes and maintain its state inside Thread.

Read more: ThreadLocal in Java - Example Program and Tutorial

Two use cases where threadlocal variable can be used -
1- When we have a requirement to associate state with a thread (e.g., a user ID or Transaction ID). That usually happens with a web application that every request going to a servlet has a unique transactionID associated with it.

// This class will provide a thread local variable which
// will provide a unique ID for each thread
class ThreadId {
    // Atomic integer containing the next thread ID to be assigned
    private static final AtomicInteger nextId = new AtomicInteger(0);

    // Thread local variable containing each thread's ID
    private static final ThreadLocal<Integer> threadId =
        ThreadLocal.<Integer>withInitial(()-> {return nextId.getAndIncrement();});

    // Returns the current thread's unique ID, assigning it if necessary
    public static int get() {
        return threadId.get();
    }
}

Note that here the method withInitial is implemented using lambda expression.
2- Another use case is when we want to have a thread safe instance and we don't want to use synchronization as the performance cost with synchronization is more. One such case is when SimpleDateFormat is used. Since SimpleDateFormat is not thread safe so we have to provide mechanism to make it thread safe. 

public class ThreadLocalDemo1 implements Runnable {
    // threadlocal variable is created
    private static final ThreadLocal<SimpleDateFormat> dateFormat = new ThreadLocal<SimpleDateFormat>(){
        @Override
        protected SimpleDateFormat initialValue(){
            System.out.println("Initializing SimpleDateFormat for - " + Thread.currentThread().getName() );
            return new SimpleDateFormat("dd/MM/yyyy");
        }
    };

    public static void main(String[] args) {
        ThreadLocalDemo1 td = new ThreadLocalDemo1();
        // Two threads are created
        Thread t1 = new Thread(td, "Thread-1");
        Thread t2 = new Thread(td, "Thread-2");
        t1.start();
        t2.start();
    }

    @Override
    public void run() {
        System.out.println("Thread run execution started for " + Thread.currentThread().getName());
        System.out.println("Date formatter pattern is  " + dateFormat.get().toPattern());
        System.out.println("Formatted date is " + dateFormat.get().format(new Date()));
    } 

}

Since Java 8 release, there is more declarative way to initialize ThreadLocal:

ThreadLocal<Cipher> local = ThreadLocal.withInitial(() -> "init value");

Until Java 8 release you had to do the following:

ThreadLocal<String> local = new ThreadLocal<String>(){
    @Override
    protected String initialValue() {
        return "init value";
    }
};

Moreover, if instantiation method (constructor, factory method) of class that is used for ThreadLocal does not take any parameters, you can simply use method references (introduced in Java 8):

class NotThreadSafe {
    // no parameters
    public NotThreadSafe(){}
}

ThreadLocal<NotThreadSafe> container = ThreadLocal.withInitial(NotThreadSafe::new);

Note: Evaluation is lazy since you are passing java.util.function.Supplier lambda that is evaluated only when ThreadLocal#get is called but value was not previously evaluated.

Sie müssen mit dem ThreadLocal -Muster sehr vorsichtig sein. Es gibt einige wichtige Down-Seiten, wie Phil erwähnt, aber eines, das nicht erwähnt wurde, ist sicherzustellen, dass der Code, der den ThreadLocal-Kontext festlegt, nicht "wieder eingetreten" ist.

Schlechte Dinge können passieren, wenn der Code, der die Informationen festlegt, ein zweites oder drittes Mal ausgeführt wird, da Informationen in Ihrem Thread zu mutieren können, wenn Sie dies nicht erwartet haben. Achten Sie also darauf, dass die ThreadLocal -Informationen nicht festgelegt wurden, bevor Sie sie erneut eingestellt haben.

wenn?

Wenn ein Objekt nicht mit Thread-sicher ist, anstatt die Synchronisation, die die Skalierbarkeit beeinträchtigt, geben Sie jedem Thread ein Objekt an und halten Sie den Thread-Bereich, was ThreadLocal ist. Eines der am häufigsten verwendeten, aber nicht mit Thread-sicheren Objekte ist die Datenbankverbindung und die JMSConnection.

Wie ?

Ein Beispiel ist, dass Spring Framework ThreadLocal verwendet, um Transaktionen hinter den Kulissen zu verwalten, indem diese Verbindungsobjekte in ThreadLocal -Variablen aufbewahrt werden. Wenn eine Transaktion gestartet wird, erhält sie die Verbindung (und deaktiviert das Auto -Commit) und hält sie in ThreadLocal. Bei weiteren DB -Aufrufen verwendet es die gleiche Verbindung, um mit DB zu kommunizieren. Am Ende nimmt es die Verbindung von ThreadLocal und begeht (oder rollback) die Transaktion und setzt die Verbindung frei.

Ich denke, Log4j verwendet auch ThreadLocal, um MDC zu pflegen.

ThreadLocal ist nützlich, wenn Sie einen Zustand haben möchten, der nicht zwischen verschiedenen Threads geteilt werden sollte, aber zu seinem gesamten Leben von jedem Thread zugänglich sein sollte.

Stellen Sie sich beispielsweise eine Webanwendung vor, bei der jede Anfrage von einem anderen Thread bedient wird. Stellen Sie sich vor, Sie benötigen für jede Anfrage mehrmals ein Datenstück, was ziemlich teuer zu berechnen ist. Diese Daten haben sich jedoch möglicherweise für jede eingehende Anforderung geändert, was bedeutet, dass Sie keinen einfachen Cache verwenden können. Eine einfache, schnelle Lösung für dieses Problem wäre, a zu haben ThreadLocal Variabler Halten zu Zugriff auf diese Daten, sodass Sie sie nur einmal für jede Anforderung berechnen müssen. Natürlich kann dieses Problem auch ohne die Verwendung von gelöst werden ThreadLocal, aber ich habe es zu Illustrationszwecken entwickelt.

Das heißt, denken Sie daran, dass ThreadLocalS sind im Wesentlichen eine Form des globalen Staates. Infolgedessen hat es viele andere Auswirkungen und sollte erst nach der Betrachtung aller anderen möglichen Lösungen verwendet werden.

Nichts wirklich Neues hier, aber ich habe heute das entdeckt ThreadLocal ist sehr nützlich, wenn die Bean -Validierung in einer Webanwendung verwendet wird. Validierungsmeldungen sind lokalisiert, jedoch standardmäßig verwendet Locale.getDefault(). Sie können die konfigurieren Validator mit einem anderen MessageInterpolator, aber es gibt keine Möglichkeit, das anzugeben Locale wenn du anrufst validate. Sie könnten also eine statische Erstellung erstellen ThreadLocal<Locale> (oder noch besser ein allgemeiner Behälter mit anderen Dingen, die Sie möglicherweise sein müssen ThreadLocal Und dann haben Sie Ihren Brauch MessageInterpolator wähle die Locale davon. Der nächste Schritt ist, a zu schreiben ServletFilter die einen Sitzungswert verwendet oder request.getLocale() Um das Gebietsschema auszuwählen und es in Ihrem zu lagern ThreadLocal Hinweis.

Wie von @UunkNOWN (Google) erwähnt, wird eine globale Variable definiert, in der der referenzierte Wert in jedem Thread eindeutig sein kann. Die Verwendungen beinhalten in der Regel das Speichern von Kontextinformationen, die mit dem aktuellen Ausführungsthread verknüpft sind.

Wir verwenden es in einer Java -EE -Umgebung, um die Benutzeridentität an Klassen zu übergeben, die sich nicht bewusst sind (keinen Zugriff auf HTTPSession oder den EJB SessionContext). Auf diese Weise kann der Code, der Identität für sicherheitsbasierte Operationen verwendet, von überall auf die Identität zugreifen, ohne ihn in jedem Methodenaufruf explizit weitergeben zu müssen.

Der Anforderungs-/Antwortzyklus von Operationen in den meisten Java EE -Aufrufen erleichtert diese Art von Nutzung, da sie genau definierte Eingangs- und Ausgangspunkte zum Setzen und Verunreinigen des ThreadLocals bietet.

ThreadLocal sorgt dafür, dass der Zugriff auf das veränderliche Objekt durch die mehreren Threads in der nicht synchronisierten Methode synchronisiert ist, was bedeutet, dass das veränderliche Objekt innerhalb der Methode unveränderlich ist.

Dies wird erreicht, indem für jeden Thread eine neue Instanz des veränderlichen Objekts angibt. Versuchen Sie, darauf zuzugreifen. Es ist also eine lokale Kopie zu jedem Thread. Dies ist ein Hack, um eine Instanzvariable in einer Methode zu erstellen, die wie eine lokale Variable zugegriffen werden kann. Da Sie die Methode bewusst sind, ist eine lokale Variable nur für den Thread verfügbar, ein Unterschied ist. Methoden lokale Variablen werden dem Thread nicht zur Verfügung stehen, sobald die Methode ausgeführt wird, wenn mit ThreadLocal als mutable Objekt über mehrere Methoden hinweg verfügbar ist, bis wir es reinigen.

Per Definition:

Mit der ThreadLocal -Klasse in Java können Sie Variablen erstellen, die nur durch denselben Thread gelesen und geschrieben werden können. Selbst wenn zwei Threads denselben Code ausführen und der Code einen Verweis auf eine Threadlokal -Variable hat, können die beiden Threads nicht die Threadlokalvariablen des anderen sehen.

Jeder Thread In Java enthält ThreadLocalMap drin.
Wo 

Key = One ThreadLocal object shared across threads.
value = Mutable object which has to be used synchronously, this will be instantiated for each thread.

Erreichen des ThreadLocals:

Erstellen Sie nun eine Wrapper -Klasse für ThreadLocal, die das veränderliche Objekt wie unten (mit oder ohne initialValue()).
Jetzt funktioniert Getter und Setter dieses Wrappers auf ThreadLocal -Instanz anstelle von veränderlichem Objekt.

Wenn Getter () von ThreadLocal keinen Wert mit der ThreadLocalMap des Thread; Anschließend wird der InitialValue () aufgerufen, um seine private Kopie in Bezug auf den Thread zu erhalten.

class SimpleDateFormatInstancePerThread {

    private static final ThreadLocal<SimpleDateFormat> dateFormatHolder = new ThreadLocal<SimpleDateFormat>() {

        @Override
        protected SimpleDateFormat initialValue() {
            SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd") {
                UUID id = UUID.randomUUID();
                @Override
                public String toString() {
                    return id.toString();
                };
            };
            System.out.println("Creating SimpleDateFormat instance " + dateFormat +" for Thread : " + Thread.currentThread().getName());
            return dateFormat;
        }
    };

    /*
     * Every time there is a call for DateFormat, ThreadLocal will return calling
     * Thread's copy of SimpleDateFormat
     */
    public static DateFormat getDateFormatter() {
        return dateFormatHolder.get();
    }

    public static void cleanup() {
        dateFormatHolder.remove();
    }
}

Jetzt wrapper.getDateFormatter() werde anrufen threadlocal.get() und das wird das überprüfen currentThread.threadLocalMap enthält Dies (ThreadLocal) Instanz.
Wenn ja, geben Sie den Wert (SimpleDateFormat) für die entsprechende ThreadLocal -Instanz zurück
Andernfalls fügen Sie die Karte mit dieser ThreadLocal -Instanz hinzu, initialValue ().

Hiermit ist die Sicherheit der Thread in dieser veränderlichen Klasse erreicht; Mit jedem Thread arbeitet mit einer eigenen veränderlichen Instanz, jedoch mit derselben ThreadLocal -Instanz. Bedeutet, dass der gesamte Thread dieselbe ThreadLocal -Instanz wie Schlüssel, aber eine unterschiedliche SimpleDateFormat -Instanz wie Wert hat.

https://github.com/skanagavelu/yt.tech/blob/master/src/threadlocaltest.java

Thread-lokale Variablen werden häufig verwendet, um das Teilen von Designs zu verhindern, die auf mutablen Singletonen oder globalen Variablen basieren.

Es kann in Szenarien wie der Herstellung einer separaten JDBC -Verbindung für jeden Thread verwendet werden, wenn Sie keinen Verbindungspool verwenden.

private static ThreadLocal<Connection> connectionHolder
           = new ThreadLocal<Connection>() {
      public Connection initialValue() {
           return DriverManager.getConnection(DB_URL);
          }
     };

public static Connection getConnection() {
      return connectionHolder.get();
}

Wenn Sie GetConnection aufrufen, wird eine mit diesem Thread verknüpfte Verbindung zurückgegeben. Das gleiche kann mit anderen Eigenschaften wie DateFormat und Transaktionskontext durchgeführt werden, die Sie nicht zwischen Threads teilen möchten.

Sie hätten auch lokale Variablen für dasselbe verwenden können, aber diese Ressourcen nehmen normalerweise Zeit in der Erstellung, sodass Sie sie nicht immer wieder erstellen möchten, wenn Sie mit ihnen eine Geschäftslogik ausführen. ThreadLocal -Werte werden jedoch im Thread -Objekt selbst gespeichert, und sobald der Faden Müll gesammelt ist, sind diese Werte auch verschwunden.

Dies Verknüpfung Erklärt die Verwendung von ThreadLocal sehr gut.

Das ThreadLocal Mit der Klasse in Java können Sie Variablen erstellen, die nur durch denselben Thread gelesen und geschrieben werden können. Selbst wenn zwei Threads denselben Code ausführen und der Code einen Verweis auf eine Threadlokal -Variable hat, können die beiden Threads nicht die Threadlokalvariablen des anderen sehen.

Weiterlesen

Als Referenz] ThreadLocal kann keine Aktualisierungsprobleme des gemeinsam genutzten Objekts lösen. Es wird empfohlen, ein staticThreadlocal -Objekt zu verwenden, das von allen Operationen im selben Thread geteilt wird. [Obligatorische] REMED () -Methode muss durch Threadlokalvariablen implementiert werden, insbesondere bei Verwendung von Threadpools, in denen Fäden häufig wiederverwendet werden. Andernfalls kann dies die nachfolgende Geschäftslogik beeinflussen und unerwartete Probleme wie Speicherlecks verursachen.

Durch das Caching müssen Sie manchmal viel Zeit berechnen, indem Sie den letzten Satz von Eingängen auf eine Methode und das Ergebnis speichern, und das Ergebnis können Sie den Code beschleunigen. Durch die Verwendung eines lokalen Speichers von Thread -Lokalen vermeiden Sie es, über das Sperren nachzudenken.

ThreadLocal ist eine speziell bereitgestellte Funktionalität von JVM, um nur einen isolierten Speicherplatz für Threads bereitzustellen. Wie der Wert der Instanz -Scoped -Variablen sind nur an eine bestimmte Instanz einer Klasse gebunden. Jedes Objekt hat seine einzigen Werte und sie können sich nicht gegenseitig sehen. Dies ist auch das Konzept der Threadlokal -Variablen, sie sind im Sinne von Objektinstanzen ein lokaler Thread, der es erstellt hat, nicht sehen. Siehe hier

import java.util.concurrent.atomic.AtomicInteger;
import java.util.stream.IntStream;


public class ThreadId {
private static final AtomicInteger nextId = new AtomicInteger(1000);

// Thread local variable containing each thread's ID
private static final ThreadLocal<Integer> threadId = ThreadLocal.withInitial(() -> nextId.getAndIncrement());


// Returns the current thread's unique ID, assigning it if necessary
public static int get() {
    return threadId.get();
}

public static void main(String[] args) {

    new Thread(() -> IntStream.range(1, 3).forEach(i -> {
        System.out.println(Thread.currentThread().getName() + " >> " + new ThreadId().get());
    })).start();

    new Thread(() -> IntStream.range(1, 3).forEach(i -> {
        System.out.println(Thread.currentThread().getName() + " >> " + new ThreadId().get());
    })).start();

    new Thread(() -> IntStream.range(1, 3).forEach(i -> {
        System.out.println(Thread.currentThread().getName() + " >> " + new ThreadId().get());
    })).start();

}
}

ThreadLocal bietet eine sehr einfache Möglichkeit, die Wiederverwendbarkeit von Objekten ohne Kosten zu erreichen.

Ich hatte eine Situation, in der mehrere Threads bei jeder Aktualisierungsbenachrichtigung ein Bild von veränderlichem Cache erstellten.

Ich habe einen ThreadLocal für jeden Thread verwendet, und dann müsste jeder Thread nur ein altes Bild zurücksetzen und dann bei jeder Aktualisierungsbenachrichtigung erneut aus dem Cache aktualisiert.

Übliche wiederverwendbare Objekte aus Objektpools haben die Sicherheitskosten für die Gewinde, die diesen Ansatz nicht haben.

Es gibt 3 Szenarien für die Verwendung a Klassenhelfer Wie SimpleDateFormat im Multithread -Code, der am besten verwendet wird ThreadLocal

Szenarien

1- Benutze wie Objekt teilen mit Hilfe von Schloss oder Synchronisation Mechanismus, der die App macht langsam

2- Verwendung als a Lokales Objekt In einer Methode

In diesem Szenario, wenn wir haben 4 Thread Jeder Ruft eine Methode 1000 auf Zeit dann haben wir
4000 SimpledateFormat Objekt erstellt und darauf zu warten, dass GC sie löscht

3- Verwendung ThreadLocal

Wenn wir 4 Thread haben und wir an gegeben haben Jeder Thread One SimpledateFormat Instance
also haben wir 4 Themen, 4 Objekte von SimpledateFormat.

Es besteht keine Notwendigkeit des Schließmechanismus und der Erstellung und Zerstörung von Objekten. (Gute Zeit Komplexität und Raumkomplexität)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top