Post summary: What are common approaches to deal with multithreading problems in Java. What is ThreadLocal and how to use it.
Multithreading problems
By definition, multithreading is the ability of CPU to execute multiple processes and threads. Almost every application nowadays is multithreaded. This allows programs to be faster and handler more users, programs have a more complex design. Multithreading causes race conditions (performing many operations at the same time on one resource) and deadlocks (competitive actions wait for each other to finish).
Multithreading problem
See code snippet below. This is a simple utility class that converts Date to String. When functional or unit tests are executed on it there are no issues, since in most cases those are single threaded. When a performance test is run program will burst into flames. Problem is that SimpleDateFormat is not thread-safe. Java 8 date objects are thread safe as they are immutable, but Java 7 below are not:
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Locale;
public final class DateTimeUtils {
private static final SimpleDateFormat DATE_FORMAT
= new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH);
private DateTimeUtils() {
// Util class
}
public static String toDateString(Date date) {
return DATE_FORMAT.format(date);
}
}
Avoid multithreading problems
Debugging multithreading problems is really hard. During debug, there are no race conditions and program works correctly. The program can even work correctly with a small number of users. One clue for multithreading problems is NullPointerException in places in a code where it is impossible to have such. Prevention is better than debugging. Prevention suggests proper design. Below is a list of approaches how to prevent and avoid multithreading issues:
- Immutable objects
- Defensive copies
- Synchronized
- Volatile
- Atomic operations
- ThreadLocal
Immutable objects
Immutable means something that cannot change. Values in such objects are initialized once and never changed, just read. Date objects in Java 8 are immutable which makes them safe to use. Object below is an example of immutable one:
public class Immutable {
private String name;
public Immutable(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
Going back to the initial problem with DateTimeUtils one solution could be to always create new SimpleDateFormat object:
public static String toDateString(Date date) {
return new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).format(date);
}
Defensive copies
Immutable objects are really simple and their fields should be primitive data types, which is not always possible. If some field is an object (List) then the getter will return a copy of the reference to this object, but the actual object can be still manipulated in heap. In such cases defensive copies are returned:
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
public class Immutable {
private String name;
private List<String> hobbies;
public Immutable(String name, String... hobbies) {
this.name = name;
this.hobbies = new ArrayList<>();
Collections.addAll(this.hobbies, hobbies);
}
public String getName() {
return name;
}
public List<String> getHobbies() {
return new ArrayList<>(hobbies);
}
}
The example here works as ArrayList is from String. If it was from some Object only references would be copied from one list to other, again real object would be available in heap, so deep copy of the Object data is also needed. Copy should drill down to the primitive types.
Synchronized
Synchronized methods cannot be accessed from two thread at the same time. One thread can access the synchronized object method, others are blocked and wait. Another solution to DateTimeUtils problem could be using synchronized:
private static final SimpleDateFormat DATE_FORMAT
= new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH);
public static synchronized String toDateString(Date date) {
return DATE_FORMAT.format(date);
}
Theoretically, this should work and when testing locally it does, but I’ve seen this solution not working in real life application, so I would not go for synchronized in given problem context.
Volatile
Volatile means that variable is stored in main memory. I would not go into details about this solution. It is pretty complex and has unexpected problems.
Atomic operations
The Java language specification guarantees that reading or writing a variable is an atomic operation (unless the variable is of type long or double because of some CPU architecture specifics). For example, i++ is not an atomic operation, it consists of two operations – read the value and add 1 to it. In order to be sure you use atomic operations on variables, Java provides a whole package with atomic objects java.util.concurrent.atomic. Objects have methods like getAndSet(), getAndIncrement() and getAndDecrement() which ensure thread safety.
ThreadLocal
This was the topic initially blog post was about, but with the research, it got little extended. This class provides thread-local variables or in other words variables that are actually different for each and every thread. It is little strange because declaration suggests this is one variable but Java makes copies behind the scenes. There is also InheritableThreadLocal which means the variable is different for other threads, but one and the same for the current thread and its sub-threads. This could also lead to multithreading problems if you mess the thread-local object from the sub-threads. The third solution to DateTimeUtils problem could be:
private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT
= new ThreadLocal<SimpleDateFormat>() {
@Override
protected SimpleDateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH);
}
};
public static String toDateString(Date date) {
return DATE_FORMAT.get().format(date);
}
Or using new Java 8 lambda expressions code will look as below. More on Java 8 features can be found in Java 8 features – Lambda expressions, Interface changes, Stream API, DateTime API post.
private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT_SAFE = ThreadLocal
.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH));
public static String toDateString(Date date) {
return DATE_FORMAT.get().format(date);
}
Comparison of solutions to multithreading problem
I have given three solutions to DateTimeUtils multithreading problem. Code shown above is available in GitHub java-samples/junit repository. There is unit test DateTimeUtilsTest which is run in multithreading mode with Maven Surefire Plugin and tests the solutions. 10 tests are run in 10 separate threads. Each test makes 1000 invocations of toDateString() method with unique date. Java 8 LocalDate is used in tests to confirm thread safety. Here are thoughts and time for different solutions:
- synchronized (toDateStringSynchronized) – time to execute tests is 0.091 – 0.101s. I would not go for this solution as I stated above I’ve seen it not working in real life application. Also just theoretically since threads have to wait on each other performance will suffer.
- new object on each method call (toDateStringNewObject) – time to execute tests is 0.114 – 0.124s. Object creation could be expensive operation. In this case there are 10000 objects created, compared to 1 in synchronized version and 10 in ThreadLocal version.
- ThreadLocal (toDateStringThreadLocal) – time to execute tests is 0.75 – 0.82s. This is my favourite. There is no wait on threads and very low amount of objects are created.
Observations above are valid for given multithreading problem, not a general rule. Everything is up to the problem that needs to be solved.
Conclusion
Multithreading is a very advanced topic. In this post, I have just given some overview and examples that could be easily applied in automation code. I would encourage you to use ThreadLocal to prevent multithreading problems. In production code, things could be much more complex. Very good tutorial on multithreading can be found in Java Concurrency / Multithreading Tutorial.
