The only guide you’ll need on concurrency & multithreading for senior engineers. Pressure test your skills with real-world practice problems from top companies.

Concurrency in Java is one of the most complex and advanced topics brought up during senior engineering interviews. Knowledge of concurrency and multithreading can put interviewees at a considerable advantage. This course lays the foundations of advanced concurrency and multithreading and explains concepts such as Monitors and Deferred Callbacks in depth. It also builds simple and complete solutions to popular concurrency problems that can be asked about in interviews like the Reader-Writer Problem and the Dining Philosopher Problem. While prior knowledge of concurrency is not required to follow through with this course, familiarity with the very basics of concurrency would be helpful.

Java Multithreading for Senior Engineering Interviews

## Concurrent Collections

A bit of history before we delve into concurrent collection classes offered by Java. When the Collections Framework was introduced in JDK 1.2, it didn't come with collections that were synchronized. However, to cater for multithreaded scenarios, the framework provided static methods to wrap vanilla collections in thread-safe wrapper objects. These thread-safe wrapper objects came to be known as wrapper collections.
<h2 class="code-hd"> Example Wrapper Collection </h2>


```java
 ArrayList<Integer> myList = new ArrayList<>();
 List<Integer> syncList = Collections.synchronizedList(myList);
```

For design pattern fans, this is an example of the decorator pattern.

Java 5 introduced thread-safe concurrent collections as part of a much larger set of concurrency utilities. The concurrent collections remove the necessity for client-side locking. In fact, external synchronization is not even possible with these collections, as there is no one object which when locked will synchronize all instance methods. If you need thread safety, the concurrent collections generally provide much better performance than synchronized (wrapper) collections. This is primarily because their throughput is not reduced by the need to serialize access, as is the case with synchronized collections. Synchronized collections also suffer from the overhead of managing locks, which can be high if there is much contention.
The concurrent collections use a variety of ways to achieve thread-safety while avoiding traditional synchronization for better performance. These are:

<ul>
<li>Copy on Write: Concurrent collections utilizing this scheme are suitable for read-heavy use cases. An immutable copy is created of the backing collection and whenever a write operation is attempted, the copy is discarded and a new copy with the change is created. Reads of the collection don’t require any synchronization, though synchronization is needed briefly when the new array is being created. Examples include <code class="clazz">CopyOnWriteArrayList</code> and <code class="clazz">CopyOnWriteArraySet</code></li>
<li>Compare and Swap: Consider a computation in which the value of a single variable is used as input to a long-running calculation whose eventual result is used to update the variable. Traditional synchronization makes the whole computation atomic, excluding any other thread from concurrently accessing the variable. This reduces opportunities for parallel execution and hurts throughput. An algorithm based on CAS behaves differently: it makes a local copy of the variable and performs the calculation without getting exclusive access. Only when it is ready to update the variable does it call CAS, which in one atomic operation compares the variable’s value with its value at the start and, if they are the same, updates it with the new value. If they are not the same, the variable must have been modified by another thread; in this situation, the CAS thread can try the whole computation again using the new value, or give up, or— in some algorithms — continue, because the interference will have actually done its work for it! Collections using CAS include <code class="clazz">ConcurrentLinkedQueue</code> and <code class="clazz">ConcurrentSkipListMap</code>.</li>
<li>Lock: Some collection classes use <code class="clazz">Lock</code> to divide up the collection into multiple parts that can be locked separately resulting in improved concurrency. For example, <code class="clazz">LinkedBlockingQueue</code> has separate locks for the head and tail ends of the queue, so that elements can be added and removed in parallel. Other collections using these locks include <code class="clazz">ConcurrentHashMap</code> and most of the implementations of <code class="clazz">BlockingQueue</code>.</li>
</ul>


### CopyOnWrite Example
Lets take an example with a regular <code class="clazz">ArrayList</code> along with a <code class="clazz">CopyOnWriteArrayList</code>. We will measure the time it takes to add an item to an already initialized array. The output from running the code widget below demonstrates that the <code class="clazz">CopyOnWriteArrayList</code> takes much more time than a regular <code class="clazz">ArrayList</code> because under the hood, all the elements of the <code class="clazz">CopyOnWriteArrayList</code> object get copied thus making an insert operation that much more expensive.

# Concurrent Collections

A bit of history before we delve into concurrent collection classes offered by Java. When the Collections Framework was introduced in JDK 1.2, it didn't come with collections that were synchronized. However, to cater for multithreaded scenarios, the framework provided static methods to wrap vanilla collections in thread-safe wrapper objects. These thread-safe wrapper objects came to be known as wrapper collections.
<h2 class="code-hd"> Example Wrapper Collection </h2>


```java
 ArrayList<Integer> myList = new ArrayList<>();
 List<Integer> syncList = Collections.synchronizedList(myList);
```

For design pattern fans, this is an example of the decorator pattern.

Java 5 introduced thread-safe concurrent collections as part of a much larger set of concurrency utilities. The concurrent collections remove the necessity for client-side locking. In fact, external synchronization is not even possible with these collections, as there is no one object which when locked will synchronize all instance methods. If you need thread safety, the concurrent collections generally provide much better performance than synchronized (wrapper) collections. This is primarily because their throughput is not reduced by the need to serialize access, as is the case with synchronized collections. Synchronized collections also suffer from the overhead of managing locks, which can be high if there is much contention.
The concurrent collections use a variety of ways to achieve thread-safety while avoiding traditional synchronization for better performance. These are:

<ul>
<li>Copy on Write: Concurrent collections utilizing this scheme are suitable for read-heavy use cases. An immutable copy is created of the backing collection and whenever a write operation is attempted, the copy is discarded and a new copy with the change is created. Reads of the collection don’t require any synchronization, though synchronization is needed briefly when the new array is being created. Examples include <code class="clazz">CopyOnWriteArrayList</code> and <code class="clazz">CopyOnWriteArraySet</code></li>
<li>Compare and Swap: Consider a computation in which the value of a single variable is used as input to a long-running calculation whose eventual result is used to update the variable. Traditional synchronization makes the whole computation atomic, excluding any other thread from concurrently accessing the variable. This reduces opportunities for parallel execution and hurts throughput. An algorithm based on CAS behaves differently: it makes a local copy of the variable and performs the calculation without getting exclusive access. Only when it is ready to update the variable does it call CAS, which in one atomic operation compares the variable’s value with its value at the start and, if they are the same, updates it with the new value. If they are not the same, the variable must have been modified by another thread; in this situation, the CAS thread can try the whole computation again using the new value, or give up, or— in some algorithms — continue, because the interference will have actually done its work for it! Collections using CAS include <code class="clazz">ConcurrentLinkedQueue</code> and <code class="clazz">ConcurrentSkipListMap</code>.</li>
<li>Lock: Some collection classes use <code class="clazz">Lock</code> to divide up the collection into multiple parts that can be locked separately resulting in improved concurrency. For example, <code class="clazz">LinkedBlockingQueue</code> has separate locks for the head and tail ends of the queue, so that elements can be added and removed in parallel. Other collections using these locks include <code class="clazz">ConcurrentHashMap</code> and most of the implementations of <code class="clazz">BlockingQueue</code>.</li>
</ul>


## CopyOnWrite Example
Lets take an example with a regular <code class="clazz">ArrayList</code> along with a <code class="clazz">CopyOnWriteArrayList</code>. We will measure the time it takes to add an item to an already initialized array. The output from running the code widget below demonstrates that the <code class="clazz">CopyOnWriteArrayList</code> takes much more time than a regular <code class="clazz">ArrayList</code> because under the hood, all the elements of the <code class="clazz">CopyOnWriteArrayList</code> object get copied thus making an insert operation that much more expensive.

# Concurrent Collections

A bit of history before we delve into concurrent collection classes offered by Java. When the Collections Framework was introduced in JDK 1.2, it didn't come with collections that were synchronized. However, to cater for multithreaded scenarios, the framework provided static methods to wrap vanilla collections in thread-safe wrapper objects. These thread-safe wrapper objects came to be known as wrapper collections.
<h2> Example Wrapper Collection </h2>


```java
 ArrayList<Integer> myList = new ArrayList<>();
 List<Integer> syncList = Collections.synchronizedList(myList);
```

For design pattern fans, this is an example of the decorator pattern.

Java 5 introduced thread-safe concurrent collections as part of a much larger set of concurrency utilities. The concurrent collections remove the necessity for client-side locking. In fact, external synchronization is not even possible with these collections, as there is no one object which when locked will synchronize all instance methods. If you need thread safety, the concurrent collections generally provide much better performance than synchronized (wrapper) collections. This is primarily because their throughput is not reduced by the need to serialize access, as is the case with synchronized collections. Synchronized collections also suffer from the overhead of managing locks, which can be high if there is much contention.
The concurrent collections use a variety of ways to achieve thread-safety while avoiding traditional synchronization for better performance. These are:

<ul>
<li>Copy on Write: Concurrent collections utilizing this scheme are suitable for read-heavy use cases. An immutable copy is created of the backing collection and whenever a write operation is attempted, the copy is discarded and a new copy with the change is created. Reads of the collection don’t require any synchronization, though synchronization is needed briefly when the new array is being created. Examples include <code>CopyOnWriteArrayList</code> and <code>CopyOnWriteArraySet</code></li>
<li>Compare and Swap: Consider a computation in which the value of a single variable is used as input to a long-running calculation whose eventual result is used to update the variable. Traditional synchronization makes the whole computation atomic, excluding any other thread from concurrently accessing the variable. This reduces opportunities for parallel execution and hurts throughput. An algorithm based on CAS behaves differently: it makes a local copy of the variable and performs the calculation without getting exclusive access. Only when it is ready to update the variable does it call CAS, which in one atomic operation compares the variable’s value with its value at the start and, if they are the same, updates it with the new value. If they are not the same, the variable must have been modified by another thread; in this situation, the CAS thread can try the whole computation again using the new value, or give up, or— in some algorithms — continue, because the interference will have actually done its work for it! Collections using CAS include <code>ConcurrentLinkedQueue</code> and <code>ConcurrentSkipListMap</code>.</li>
<li>Lock: Some collection classes use <code>Lock</code> to divide up the collection into multiple parts that can be locked separately resulting in improved concurrency. For example, <code>LinkedBlockingQueue</code> has separate locks for the head and tail ends of the queue, so that elements can be added and removed in parallel. Other collections using these locks include <code>ConcurrentHashMap</code> and most of the implementations of <code>BlockingQueue</code>.</li>
</ul>


## CopyOnWrite Example
Lets take an example with a regular <code>ArrayList</code> along with a <code>CopyOnWriteArrayList</code>. We will measure the time it takes to add an item to an already initialized array. The output from running the code widget below demonstrates that the <code>CopyOnWriteArrayList</code> takes much more time than a regular <code>ArrayList</code> because under the hood, all the elements of the <code>CopyOnWriteArrayList</code> object get copied thus making an insert operation that much more expensive.

This lesson gives a brief introduction about Java's concurrent collection classes.

The Basics

Multithreading in Java

Java's Memory Model

Interview Practice Problems

Bonus Questions

Beyond the Interview

Java Concurrency Reference

Revision & Quizzes

Concurrent Collections

Concurrent Collections

Example Wrapper Collection