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

## Reentrant Lock

Java's answer to the traditional mutex is the reentrant lock, which comes with additional bells and whistles. It is similar to the implicit monitor lock accessed when using <code class="b_blue">synchronized</code> methods or blocks. With the reentrant lock, you are free to lock and unlock it in different methods but not with different threads. If you attempt to unlock a reentrant lock object by a thread which didn't lock it initially, you'll get an IllegalMonitorStateException. This behavior is similar to when a thread attempts to unlock a pthread mutex.

## Condition Variable

We saw how each java object exposes the three methods, <code>wait()</code>,<code>notify()</code> and <code>notifyAll()</code> which can be used to suspend threads till some condition becomes true. You can think of Condition as factoring out these three methods of the object monitor into separate objects so that there can be multiple wait-sets per object. As a reentrant lock replaces <code class="b_blue">synchronized</code> blocks or methods, a condition replaces the object monitor methods. In the same vein, one can't invoke the condition variable's methods without acquiring the associated lock, just like one can't wait on an object's monitor without synchronizing on the object first. In fact, a reentrant lock exposes an API to create new condition variables, like so:


```java
Lock lock = new ReentrantLock();
Condition myCondition = lock.newCondition();
```

Notice, how we can now have multiple condition variables associated with the same lock. In the <code class="b_blue">synchronized</code> paradigm, we could only have one wait-set associated with each object.
 </div>
</div>

 ## java.util.concurrent 
Java's util.concurrent package provides several classes that can be used for solving everyday concurrency problems and should always be preferred than reinventing the wheel. Its offerings include thread-safe data structures such as <code class="b_blue">ConcurrentHashMap</code>.

# Reentrant Lock

Java's answer to the traditional mutex is the reentrant lock, which comes with additional bells and whistles. It is similar to the implicit monitor lock accessed when using <code class="b_blue">synchronized</code> methods or blocks. With the reentrant lock, you are free to lock and unlock it in different methods but not with different threads. If you attempt to unlock a reentrant lock object by a thread which didn't lock it initially, you'll get an IllegalMonitorStateException. This behavior is similar to when a thread attempts to unlock a pthread mutex.

# Condition Variable

We saw how each java object exposes the three methods, <code>wait()</code>,<code>notify()</code> and <code>notifyAll()</code> which can be used to suspend threads till some condition becomes true. You can think of Condition as factoring out these three methods of the object monitor into separate objects so that there can be multiple wait-sets per object. As a reentrant lock replaces <code class="b_blue">synchronized</code> blocks or methods, a condition replaces the object monitor methods. In the same vein, one can't invoke the condition variable's methods without acquiring the associated lock, just like one can't wait on an object's monitor without synchronizing on the object first. In fact, a reentrant lock exposes an API to create new condition variables, like so:


```java
Lock lock = new ReentrantLock();
Condition myCondition = lock.newCondition();
```

Notice, how we can now have multiple condition variables associated with the same lock. In the <code class="b_blue">synchronized</code> paradigm, we could only have one wait-set associated with each object.
 </div>
</div>

 ## java.util.concurrent 
Java's util.concurrent package provides several classes that can be used for solving everyday concurrency problems and should always be preferred than reinventing the wheel. Its offerings include thread-safe data structures such as <code class="b_blue">ConcurrentHashMap</code>.

# Reentrant Lock

Java's answer to the traditional mutex is the reentrant lock, which comes with additional bells and whistles. It is similar to the implicit monitor lock accessed when using <code>synchronized</code> methods or blocks. With the reentrant lock, you are free to lock and unlock it in different methods but not with different threads. If you attempt to unlock a reentrant lock object by a thread which didn't lock it initially, you'll get an IllegalMonitorStateException. This behavior is similar to when a thread attempts to unlock a pthread mutex.

# Condition Variable

We saw how each java object exposes the three methods, <code>wait()</code>,<code>notify()</code> and <code>notifyAll()</code> which can be used to suspend threads till some condition becomes true. You can think of Condition as factoring out these three methods of the object monitor into separate objects so that there can be multiple wait-sets per object. As a reentrant lock replaces <code>synchronized</code> blocks or methods, a condition replaces the object monitor methods. In the same vein, one can't invoke the condition variable's methods without acquiring the associated lock, just like one can't wait on an object's monitor without synchronizing on the object first. In fact, a reentrant lock exposes an API to create new condition variables, like so:


```java
Lock lock = new ReentrantLock();
Condition myCondition = lock.newCondition();
```

Notice, how we can now have multiple condition variables associated with the same lock. In the <code>synchronized</code> paradigm, we could only have one wait-set associated with each object.
 </div>
</div>

 ## java.util.concurrent 
Java's util.concurrent package provides several classes that can be used for solving everyday concurrency problems and should always be preferred than reinventing the wheel. Its offerings include thread-safe data structures such as <code>ConcurrentHashMap</code>.

The Basics

Multithreading in Java

Java's Memory Model

Interview Practice Problems

Bonus Questions

Beyond the Interview

Java Concurrency Reference

Revision & Quizzes

Reentrant Locks & Condition Variables

Reentrant Lock