Was ist Thread-Sicherheit und wie erreicht man sie?

1. Übersicht

Java unterstützt sofortiges Multithreading. Dies bedeutet, dass die JVM durch gleichzeitiges Ausführen von Bytecode in separaten Arbeitsthreads die Anwendungsleistung verbessern kann.

Obwohl Multithreading eine leistungsstarke Funktion ist, hat es seinen Preis. In Multithread-Umgebungen müssen wir Implementierungen threadsicher schreiben. Dies bedeutet, dass verschiedene Threads auf dieselben Ressourcen zugreifen können, ohne fehlerhaftes Verhalten aufzudecken oder unvorhersehbare Ergebnisse zu erzielen. Diese Programmiermethode wird als "Thread-Sicherheit" bezeichnet.

In diesem Tutorial werden verschiedene Ansätze vorgestellt, um dies zu erreichen.

2. Staatenlose Implementierungen

In den meisten Fällen sind Fehler in Multithread-Anwendungen darauf zurückzuführen, dass der Status zwischen mehreren Threads falsch geteilt wurde.

Daher besteht der erste Ansatz darin, die Thread-Sicherheit mithilfe zustandsloser Implementierungen zu erreichen .

Um diesen Ansatz besser zu verstehen, betrachten wir eine einfache Utility-Klasse mit einer statischen Methode, die die Fakultät einer Zahl berechnet:

public class MathUtils { public static BigInteger factorial(int number) { BigInteger f = new BigInteger("1"); for (int i = 2; i <= number; i++) { f = f.multiply(BigInteger.valueOf(i)); } return f; } } 

Die Fakultät Fakultät () ist eine zustandslose deterministische Funktion. Bei einer bestimmten Eingabe wird immer dieselbe Ausgabe erzeugt.

Die Methode beruht weder auf einem externen Zustand noch behält sie den Zustand bei . Daher wird es als threadsicher angesehen und kann von mehreren Threads gleichzeitig sicher aufgerufen werden.

Alle Threads können die Fakultät factorial () sicher aufrufen und erhalten das erwartete Ergebnis, ohne sich gegenseitig zu stören und ohne die Ausgabe zu ändern, die die Methode für andere Threads generiert.

Daher staatenlos Implementierungen sind der einfachste Weg , Thread-Sicherheit zu erreichen .

3. Unveränderliche Implementierungen

Wenn wir den Status zwischen verschiedenen Threads teilen müssen, können wir threadsichere Klassen erstellen, indem wir sie unveränderlich machen .

Unveränderlichkeit ist ein leistungsfähiges, sprachunabhängiges Konzept, das in Java relativ einfach zu erreichen ist.

Einfach ausgedrückt ist eine Klasseninstanz unveränderlich, wenn ihr interner Status nach ihrer Erstellung nicht mehr geändert werden kann .

Der einfachste Weg, eine unveränderliche Klasse in Java zu erstellen, besteht darin, alle Felder als privat und endgültig zu deklarieren und keine Setter bereitzustellen:

public class MessageService { private final String message; public MessageService(String message) { this.message = message; } // standard getter }

Ein MessageService- Objekt ist effektiv unveränderlich, da sich sein Status nach seiner Erstellung nicht ändern kann. Daher ist es threadsicher.

Wenn MessageService tatsächlich veränderbar ist, aber mehrere Threads nur Lesezugriff darauf haben, ist es außerdem threadsicher.

So Unveränderlichkeit ist nur eine andere Art Thread-Sicherheit zu erreichen .

4. Thread-lokale Felder

Bei der objektorientierten Programmierung (OOP) müssen Objekte tatsächlich den Status durch Felder beibehalten und das Verhalten durch eine oder mehrere Methoden implementieren.

Wenn wir den Status tatsächlich beibehalten müssen, können wir threadsichere Klassen erstellen, die den Status nicht zwischen Threads teilen, indem wir ihre Felder threadlokal machen.

Wir können leicht Klassen erstellen, deren Felder threadlokal sind, indem wir einfach private Felder in Thread- Klassen definieren.

Wir könnten zum Beispiel eine Thread- Klasse definieren, die ein Array von Ganzzahlen speichert :

public class ThreadA extends Thread { private final List numbers = Arrays.asList(1, 2, 3, 4, 5, 6); @Override public void run() { numbers.forEach(System.out::println); } }

Während ein anderer eine Reihe von Zeichenfolgen enthalten könnte :

public class ThreadB extends Thread { private final List letters = Arrays.asList("a", "b", "c", "d", "e", "f"); @Override public void run() { letters.forEach(System.out::println); } }

In beiden Implementierungen haben die Klassen ihren eigenen Status, der jedoch nicht mit anderen Threads geteilt wird. Somit sind die Klassen threadsicher.

Ebenso können wir threadlokale Felder erstellen, indem wir einem Feld ThreadLocal- Instanzen zuweisen .

Betrachten wir zum Beispiel die folgende StateHolder- Klasse:

public class StateHolder { private final String state; // standard constructors / getter }

Wir können es leicht wie folgt zu einer threadlokalen Variablen machen:

public class ThreadState { public static final ThreadLocal statePerThread = new ThreadLocal() { @Override protected StateHolder initialValue() { return new StateHolder("active"); } }; public static StateHolder getState() { return statePerThread.get(); } }

Thread-lokale Felder ähneln normalen Klassenfeldern, außer dass jeder Thread, der über einen Setter / Getter auf sie zugreift, eine unabhängig initialisierte Kopie des Felds erhält, sodass jeder Thread seinen eigenen Status hat.

5. Synchronisierte Sammlungen

Mit den im Sammlungsframework enthaltenen Synchronisations-Wrappern können wir problemlos threadsichere Sammlungen erstellen.

Wir können zum Beispiel einen dieser Synchronisations-Wrapper verwenden, um eine thread-sichere Sammlung zu erstellen:

Collection syncCollection = Collections.synchronizedCollection(new ArrayList()); Thread thread1 = new Thread(() -> syncCollection.addAll(Arrays.asList(1, 2, 3, 4, 5, 6))); Thread thread2 = new Thread(() -> syncCollection.addAll(Arrays.asList(7, 8, 9, 10, 11, 12))); thread1.start(); thread2.start(); 

Beachten Sie, dass synchronisierte Sammlungen in jeder Methode die intrinsische Sperre verwenden (wir werden uns später mit der intrinsischen Sperre befassen).

Dies bedeutet, dass nur jeweils ein Thread auf die Methoden zugreifen kann, während andere Threads blockiert werden, bis die Methode vom ersten Thread entsperrt wird.

Daher hat die Synchronisation aufgrund der zugrunde liegenden Logik des synchronisierten Zugriffs einen Leistungsverlust.

6. Gleichzeitige Sammlungen

Alternativ zu synchronisierten Sammlungen können wir gleichzeitig Sammlungen verwenden, um threadsichere Sammlungen zu erstellen.

Java stellt das Paket java.util.concurrent bereit , das mehrere gleichzeitige Sammlungen enthält, z. B. ConcurrentHashMap :

Map concurrentMap = new ConcurrentHashMap(); concurrentMap.put("1", "one"); concurrentMap.put("2", "two"); concurrentMap.put("3", "three"); 

Im Gegensatz zu ihren synchronisierten Gegenstücken erreichen gleichzeitige Sammlungen Thread-Sicherheit, indem ihre Daten in Segmente unterteilt werden . In einer ConcurrentHashMap können beispielsweise mehrere Threads Sperren für verschiedene Kartensegmente erwerben, sodass mehrere Threads gleichzeitig auf die Karte zugreifen können .

Gleichzeitige Sammlungen sind aufgrund der inhärenten Vorteile des gleichzeitigen Thread-Zugriffs viel leistungsfähiger als synchronisierte Sammlungen .

Es ist erwähnenswert, dass synchronisierte und gleichzeitige Sammlungen nur die Sammlung selbst threadsicher machen und nicht den Inhalt .

7. Atomobjekte

Es ist auch möglich, Thread-Sicherheit mithilfe der von Java bereitgestellten Atomklassen zu erreichen, einschließlich AtomicInteger , AtomicLong , AtomicBoolean und AtomicReference .

Atomklassen ermöglichen es uns, atomare Operationen, die threadsicher sind, ohne Synchronisation auszuführen . Eine atomare Operation wird in einer einzigen Operation auf Maschinenebene ausgeführt.

Um das dadurch gelöste Problem zu verstehen, schauen wir uns die folgende Counter- Klasse an:

public class Counter { private int counter = 0; public void incrementCounter() { counter += 1; } public int getCounter() { return counter; } }

Nehmen wir an, dass unter einer Race-Bedingung zwei Threads gleichzeitig auf die Methode incrementCounter () zugreifen .

In theory, the final value of the counter field will be 2. But we just can't be sure about the result, because the threads are executing the same code block at the same time and incrementation is not atomic.

Let's create a thread-safe implementation of the Counter class by using an AtomicInteger object:

public class AtomicCounter { private final AtomicInteger counter = new AtomicInteger(); public void incrementCounter() { counter.incrementAndGet(); } public int getCounter() { return counter.get(); } }

This is thread-safe because, while incrementation, ++, takes more than one operation, incrementAndGet is atomic.

8. Synchronized Methods

While the earlier approaches are very good for collections and primitives, we will at times need greater control than that.

So, another common approach that we can use for achieving thread-safety is implementing synchronized methods.

Simply put, only one thread can access a synchronized method at a time while blocking access to this method from other threads. Other threads will remain blocked until the first thread finishes or the method throws an exception.

We can create a thread-safe version of incrementCounter() in another way by making it a synchronized method:

public synchronized void incrementCounter() { counter += 1; }

We've created a synchronized method by prefixing the method signature with the synchronized keyword.

Since one thread at a time can access a synchronized method, one thread will execute the incrementCounter() method, and in turn, others will do the same. No overlapping execution will occur whatsoever.

Synchronized methods rely on the use of “intrinsic locks” or “monitor locks”. An intrinsic lock is an implicit internal entity associated with a particular class instance.

In a multithreaded context, the term monitor is just a reference to the role that the lock performs on the associated object, as it enforces exclusive access to a set of specified methods or statements.

When a thread calls a synchronized method, it acquires the intrinsic lock. After the thread finishes executing the method, it releases the lock, hence allowing other threads to acquire the lock and get access to the method.

We can implement synchronization in instance methods, static methods, and statements (synchronized statements).

9. Synchronized Statements

Sometimes, synchronizing an entire method might be overkill if we just need to make a segment of the method thread-safe.

To exemplify this use case, let's refactor the incrementCounter() method:

public void incrementCounter() { // additional unsynced operations synchronized(this) { counter += 1;  } }

The example is trivial, but it shows how to create a synchronized statement. Assuming that the method now performs a few additional operations, which don't require synchronization, we only synchronized the relevant state-modifying section by wrapping it within a synchronized block.

Unlike synchronized methods, synchronized statements must specify the object that provides the intrinsic lock, usually the this reference.

Synchronization is expensive, so with this option, we are able to only synchronize the relevant parts of a method.

9.1. Other Objects as a Lock

We can slightly improve the thread-safe implementation of the Counter class by exploiting another object as a monitor lock, instead of this.

Not only does this provide coordinated access to a shared resource in a multithreaded environment, but also it uses an external entity to enforce exclusive access to the resource:

public class ObjectLockCounter { private int counter = 0; private final Object lock = new Object(); public void incrementCounter() { synchronized(lock) { counter += 1; } } // standard getter }

We use a plain Object instance to enforce mutual exclusion. This implementation is slightly better, as it promotes security at the lock level.

When using this for intrinsic locking, an attacker could cause a deadlock by acquiring the intrinsic lock and triggering a denial of service (DoS) condition.

On the contrary, when using other objects, that private entity is not accessible from the outside. This makes it harder for an attacker to acquire the lock and cause a deadlock.

9.2. Caveats

Even though we can use any Java object as an intrinsic lock, we should avoid using Strings for locking purposes:

public class Class1 { private static final String LOCK = "Lock"; // uses the LOCK as the intrinsic lock } public class Class2 { private static final String LOCK = "Lock"; // uses the LOCK as the intrinsic lock }

At first glance, it seems that these two classes are using two different objects as their lock. However, because of string interning, these two “Lock” values may actually refer to the same object on the string pool. That is, the Class1 and Class2 are sharing the same lock!

This, in turn, may cause some unexpected behaviors in concurrent contexts.

In addition to Strings, we should avoid using any cacheable or reusable objects as intrinsic locks. For example, the Integer.valueOf() method caches small numbers. Therefore, calling Integer.valueOf(1) returns the same object even in different classes.

10. Volatile Fields

Synchronized methods and blocks are handy for addressing variable visibility problems among threads. Even so, the values of regular class fields might be cached by the CPU. Hence, consequent updates to a particular field, even if they're synchronized, might not be visible to other threads.

To prevent this situation, we can use volatile class fields:

public class Counter { private volatile int counter; // standard constructors / getter }

With the volatile keyword, we instruct the JVM and the compiler to store the counter variable in the main memory. That way, we make sure that every time the JVM reads the value of the counter variable, it will actually read it from the main memory, instead of from the CPU cache. Likewise, every time the JVM writes to the counter variable, the value will be written to the main memory.

Moreover, the use of a volatile variable ensures that all variables that are visible to a given thread will be read from the main memory as well.

Let's consider the following example:

public class User { private String name; private volatile int age; // standard constructors / getters }

In this case, each time the JVM writes the agevolatile variable to the main memory, it will write the non-volatile name variable to the main memory as well. This assures that the latest values of both variables are stored in the main memory, so consequent updates to the variables will automatically be visible to other threads.

Similarly, if a thread reads the value of a volatile variable, all the variables visible to the thread will be read from the main memory too.

This extended guarantee that volatile variables provide is known as the full volatile visibility guarantee.

11. Reentrant Locks

Java provides an improved set of Lock implementations, whose behavior is slightly more sophisticated than the intrinsic locks discussed above.

With intrinsic locks, the lock acquisition model is rather rigid: one thread acquires the lock, then executes a method or code block, and finally releases the lock, so other threads can acquire it and access the method.

There's no underlying mechanism that checks the queued threads and gives priority access to the longest waiting threads.

ReentrantLock instances allow us to do exactly that, hence preventing queued threads from suffering some types of resource starvation:

public class ReentrantLockCounter { private int counter; private final ReentrantLock reLock = new ReentrantLock(true); public void incrementCounter() { reLock.lock(); try { counter += 1; } finally { reLock.unlock(); } } // standard constructors / getter }

The ReentrantLock constructor takes an optional fairnessboolean parameter. When set to true, and multiple threads are trying to acquire a lock, the JVM will give priority to the longest waiting thread and grant access to the lock.

12. Read/Write Locks

Another powerful mechanism that we can use for achieving thread-safety is the use of ReadWriteLock implementations.

A ReadWriteLock lock actually uses a pair of associated locks, one for read-only operations and other for writing operations.

Infolgedessen ist es möglich, dass viele Threads eine Ressource lesen, solange kein Thread darauf schreibt. Darüber hinaus verhindert das Schreiben von Threads in die Ressource, dass andere Threads sie lesen .

Wir können eine ReadWriteLock- Sperre wie folgt verwenden:

public class ReentrantReadWriteLockCounter { private int counter; private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock(); private final Lock readLock = rwLock.readLock(); private final Lock writeLock = rwLock.writeLock(); public void incrementCounter() { writeLock.lock(); try { counter += 1; } finally { writeLock.unlock(); } } public int getCounter() { readLock.lock(); try { return counter; } finally { readLock.unlock(); } } // standard constructors } 

13. Schlussfolgerung

In diesem Artikel haben wir gelernt, was Thread-Sicherheit in Java ist, und uns eingehend mit verschiedenen Ansätzen befasst, um dies zu erreichen .

Wie üblich sind alle in diesem Artikel gezeigten Codebeispiele auf GitHub verfügbar.