The ultimate guide to Java interviews with 300+ real-world questions and answers. Get interview-ready in just a few hours with strategies developed by FAANG engineers.

It’s very common to have interviews testing your knowledge of a programming language you claim to be an expert in.

If you've got an interview coming up on Java soon and need to get up to speed, this is the ideal course for you. You'll refresh your memory on everything from the basics to more advanced functionality you’re likely to be asked about. Even if you're using Java every day, you may not have been exposed to parts of it in some time, so it's always useful to make sure you're updated.

This course features more than 300 of the most commonly asked core Java interview questions that you're likely to face as an experienced software engineer. You'll get to explore questions by topic, as well as see detailed answers for each one, and plenty of live code examples where relevant. Get started today.

The Java Interview Handbook: 300+ Interview Questions

<div class="card">
 # Notes on Concurrency
<div class="ans">
<ol>
<li>Synchronizing only the write path isn't sufficient for thread-safety. In fact, synchronization has no effect unless both read and write operations are synchronized. The class below shows such a scenario, where the read path isn't synchronized and a thead may never see the updated value of the flag set by another thread because of how the Java's memory model works.
## Bad Practice


```java
class Unsafe {

 Boolean flag;


 public synchronized void setFlag(Boolean flag) {
 this.flag = flag;
 }

 // Read path is unsynchronized and a thread reading
 // the flag may never see an updated value by another thread
 public Boolean getFlag() {
 return flag;
 }

}
```


</li>
<li>The <code class="clazz">volatile</code> modifier doesn't perform mutual exclusion, but it guarantees that any thread that reads a volatile field will see the most recently written value. The above class can be fixed as follows:


```java
class Unsafe {

 volatile Boolean flag;


 public synchronized void setFlag(Boolean flag) {
 this.flag = flag;
 }

 // No synchronization but latest value is read
 public Boolean getFlag() {
 return flag;
 }

}
```

It is possible that a thread invokes <code class="mthd">setFlag()</code> but before it can complete another thread comes along and reads the flag value. However, the read or write to a variable is atomic. It can't happen that half the bytes of a variable are written by thread#1 and the other half are written by thread#2 resulting in an arbitrary value being stored. So whenever a thread concurrently reads a variable without synchronization, it is guaranteed to see a value that was written to the variable by another thread. One caveat is that this guarantee doesn't apply to type long or double unless they are marked volatile. This is because writes to long or double can translate to multistep operation at the machine code level.
</li>
<li>Be wary of non-atomic operations. Consider the snippet below:


```java
private static volatile int nextID = 0;
 public static int generateID() {
 return nextID++;
}
```

The above code is broken because the developer has mistaken the <code class="clazz">++</code> to be atomic when it is not. The above method can actually be rewritten as:


```java
private static volatile int nextID = 0;
 public static int generateID() {
 nextID = nextID + 1;
 return nextID;
}
```


It's easy to see that the rewritten method needs to be synchronized and <code class="clazz">volatile</code> isn't enough. Multiple threads calling into the method can end up reading the same value of <code class="clazz">nextID</code> and incrementing it, resulting in two identical IDs.
</li>

<li>Ideally confine mutable data to a single thread. When multiple threads share mutable data, each thread that reads or writes the data must perform synchronization. Without synchronization, there is no guarantee that one thread’s changes will be visible to another as exemplified from the previous examples.</li>

<li>Volatile can suffice, when only inter-thread communication is desired without mutual exclusion. However, correct usage of <code class="clazz">volatile</code> is tricky. For instance two threads can use a boolean between themselves when only one thread ever writes to the variable and the other ever reads the variable.


```java
class MultiThreadedCommunication {
 static volatile boolean terminate = false;

 // Invoked by thread 1
 void setTerminate() {
 terminate = true;
 }

 // Invoked by thread 2
 boolean shouldTerminate() {
 return terminate;
 }
}
```

</li>


<li>Don't invoke untrusted client methods from <code class="clazz">synchronized</code> regions of a class. The client method can in turn try to acquire locks already held or violate the invariants of the class or method.

## Bad Practice


```java
class NaiveClass {

 // Method receives a client object and invokes
 // a client method within synchronized region.
 // This can cause unexpected deadlocks, exceptions etc
 synchronized void process(Client client) {

 // ... method body

 // Don't do this
 client.method();
 }

}
```


</li>

<li>Refrain from writing your own work queues, or working with threads directly. A task is the fundamental abstraction for unit of work representable by <code class="clazz">Runnable</code> or <code class="clazz">Callable</code>. ExecutorService is the mechanism to run tasks. Leverage these abstractions where applicable as much as possible.</li>

<li>Use higher level concurrency utilities rather than working directly with <code class="mthd">wait()</code> and <code class="mthd">notify()</code> which can be hard to get right.</li>

<li>Prefer using concurrent collections than externally synchronized collections.</li>

<li>Most commonly used synchronizers are <code class="clazz">CountDownLatch</code> and <code class="clazz">Semaphore</code>. Less commonly used are <code class="clazz">CyclicBarrier</code> and <code class="clazz">Exchanger</code>. Use these synchronizers than rewriting their functionality.</li>


<li>Always use the wait loop idiom to invoke the <code class="mthd">wait()</code> method. Never invoke <code class="mthd">wait()</code> outside of a loop. 
## Correct wait() usage idiom


```java

 // The standard idiom for using the wait() method
 synchronized (obj) {
 while (<condition does not hold>)
 obj.wait(); // Lock released & reacquired on wakeup
 // ... Do Processing
 }
```

The <code class="mthd">notifyAll()</code> method should generally be used in preference to <code class="mthd">notify()</code>.
</li>
<li>Consider using a private lock object instead of <code class="clazz">synchronized</code> methods. Public synchronized methods are in essence public locks that can be held by client either intentionally or accidentally and result in denial of service to other clients.</li>

<li>Avoid lazy initialization unless absolutely needed. The pattern delays initialization of a resource until needed but makes each access costlier.
</li>

<li>Use the holder class idiom for enabling lazy initialization on static fields. The idiom is given as follows:
## Lazy initializing static field


```java
class OuterClass {

 // Nested static class that holds the field
 // we want to lazily initialize
 private static class ObjectHolder{
 static final Object lazilyInitField = init();

 static Object init(){
 // ... Do expensive initialization here
 }
 }

 static Object getStaticField(){
 return ObjectHolder.lazilyInitField;
 }

}
```


The VM will synchronize access to the static field only to initialize the nested class. Once the nested class is initialized, the VM will patch the code so that subsequent access to the field does not involve any testing or synchronization.</li>

<li>Use double checked locking idiom for lazily initializing instance fields. The idiom is given below:
## Lazily initializing instance fields


```java
class DCL {

 volatile Object object;

 void getObject() {

 if (object == null) { // First check with no locking

 synchronized (this) {
 if (object == null){ // Second check with locking
 object = // ... Do expensive initialization here
 }
 }
 }

 return object;
 }

}
```


Note, the above idiom didn't work on versions of Java prior to 1.5. We can apply the double check locking idiom to static fields as well but the holder class idiom is a better fit for those situations.

In the given implementation of double check locking, after the object has been initialized for the first time, each subsequent access reads the <code class="clazz">volatile</code> field twice. Once in the if condition and once when it is being returned. Volatile reads can be expensive and we can improve on the performance by reading the volatile field in a local variable only once as shown below.
## Improved double check locking


```java
class ImprovedDCL {

 volatile Object object;

 void getObject() {

 Object localVar = object; // Read volatile fields only once
 if (localVar == null) { // First check with no locking

 synchronized (this) {
 if (object == null){ // Second check with locking
 object = // ... Do expensive initialization here
 }
 }
 }

 // Return localVar and not object which would have caused
 // the second read of the volatile field
 return localVar;
 }

}
``` 

</li>


<li>Consider using single checked idiom where repeated initializations can be tolerated or are desired. The single check idiom is similar to the double checked idiom without the second check.
## Single check idiom


```java
class SingleCheck {

 volatile Object object;

 void getObject() {

 if (object == null) { // Single check with no locking
 object = // ... Do expensive initialization here
 }

 return object;
 }

}
```

Note the field is still declared <code class="clazz">volatile</code>. If you don’t care whether every thread recalculates the value of a field, and the type of the field is a primitive other than long or double, then you may choose to remove the volatile modifier from the field declaration in the single check idiom. This variant is known as the racy single check idiom. It speeds up field access on some architectures, at the expense of additional initializations (up to one per thread that accesses the field). This technique is used by <code class="clazz">String</code> instances to cache their hash codes.</li>


<li>Programs should never rely on the thread scheduler for correctness or performance. Such programs may not be portable. The best way to write a robust, responsive, portable program is to ensure that the average number of runnable threads is not significantly greater than the number of available processors in the system. Threads that are waiting aren't considered runnable.</li>

<li>Busy-waiting should be shunned for coordination among threads. It is a common folly to program a thread to repeatedly check for an event to happen. Besides making the program vulnerable to the vagaries of the scheduler, busy-waiting greatly increases the load on the processor, reducing the amount of useful work that other threads can accomplish.</li>

<li>Avoid tweaking thread priorities or using Thread.yield to fix liveness (ability to make progress) issues in a program. Thread priorities are among the least portable features of the Java platform and the resulting program will be neither robust nor portable.</li>


<li>Avoid using thread groups. <code class="clazz">ThreadGroup</code> are considered obsolete.</li>
</ol>
</div>

<div>
 # Notes on Concurrency
<div>
<ol>
<li>Synchronizing only the write path isn't sufficient for thread-safety. In fact, synchronization has no effect unless both read and write operations are synchronized. The class below shows such a scenario, where the read path isn't synchronized and a thead may never see the updated value of the flag set by another thread because of how the Java's memory model works.
## Bad Practice


```java
class Unsafe {

 Boolean flag;


 public synchronized void setFlag(Boolean flag) {
 this.flag = flag;
 }

 // Read path is unsynchronized and a thread reading
 // the flag may never see an updated value by another thread
 public Boolean getFlag() {
 return flag;
 }

}
```


</li>
<li>The <code>volatile</code> modifier doesn't perform mutual exclusion, but it guarantees that any thread that reads a volatile field will see the most recently written value. The above class can be fixed as follows:


```java
class Unsafe {

 volatile Boolean flag;


 public synchronized void setFlag(Boolean flag) {
 this.flag = flag;
 }

 // No synchronization but latest value is read
 public Boolean getFlag() {
 return flag;
 }

}
```

It is possible that a thread invokes <code>setFlag()</code> but before it can complete another thread comes along and reads the flag value. However, the read or write to a variable is atomic. It can't happen that half the bytes of a variable are written by thread#1 and the other half are written by thread#2 resulting in an arbitrary value being stored. So whenever a thread concurrently reads a variable without synchronization, it is guaranteed to see a value that was written to the variable by another thread. One caveat is that this guarantee doesn't apply to type long or double unless they are marked volatile. This is because writes to long or double can translate to multistep operation at the machine code level.
</li>
<li>Be wary of non-atomic operations. Consider the snippet below:


```java
private static volatile int nextID = 0;
 public static int generateID() {
 return nextID++;
}
```

The above code is broken because the developer has mistaken the <code>++</code> to be atomic when it is not. The above method can actually be rewritten as:


```java
private static volatile int nextID = 0;
 public static int generateID() {
 nextID = nextID + 1;
 return nextID;
}
```


It's easy to see that the rewritten method needs to be synchronized and <code>volatile</code> isn't enough. Multiple threads calling into the method can end up reading the same value of <code>nextID</code> and incrementing it, resulting in two identical IDs.
</li>

<li>Ideally confine mutable data to a single thread. When multiple threads share mutable data, each thread that reads or writes the data must perform synchronization. Without synchronization, there is no guarantee that one thread’s changes will be visible to another as exemplified from the previous examples.</li>

<li>Volatile can suffice, when only inter-thread communication is desired without mutual exclusion. However, correct usage of <code>volatile</code> is tricky. For instance two threads can use a boolean between themselves when only one thread ever writes to the variable and the other ever reads the variable.


```java
class MultiThreadedCommunication {
 static volatile boolean terminate = false;

 // Invoked by thread 1
 void setTerminate() {
 terminate = true;
 }

 // Invoked by thread 2
 boolean shouldTerminate() {
 return terminate;
 }
}
```

</li>


<li>Don't invoke untrusted client methods from <code>synchronized</code> regions of a class. The client method can in turn try to acquire locks already held or violate the invariants of the class or method.

## Bad Practice


```java
class NaiveClass {

 // Method receives a client object and invokes
 // a client method within synchronized region.
 // This can cause unexpected deadlocks, exceptions etc
 synchronized void process(Client client) {

 // ... method body

 // Don't do this
 client.method();
 }

}
```


</li>

<li>Refrain from writing your own work queues, or working with threads directly. A task is the fundamental abstraction for unit of work representable by <code>Runnable</code> or <code>Callable</code>. ExecutorService is the mechanism to run tasks. Leverage these abstractions where applicable as much as possible.</li>

<li>Use higher level concurrency utilities rather than working directly with <code>wait()</code> and <code>notify()</code> which can be hard to get right.</li>

<li>Prefer using concurrent collections than externally synchronized collections.</li>

<li>Most commonly used synchronizers are <code>CountDownLatch</code> and <code>Semaphore</code>. Less commonly used are <code>CyclicBarrier</code> and <code>Exchanger</code>. Use these synchronizers than rewriting their functionality.</li>


<li>Always use the wait loop idiom to invoke the <code>wait()</code> method. Never invoke <code>wait()</code> outside of a loop. 
## Correct wait() usage idiom


```java

 // The standard idiom for using the wait() method
 synchronized (obj) {
 while (<condition does not hold>)
 obj.wait(); // Lock released & reacquired on wakeup
 // ... Do Processing
 }
```

The <code>notifyAll()</code> method should generally be used in preference to <code>notify()</code>.
</li>
<li>Consider using a private lock object instead of <code>synchronized</code> methods. Public synchronized methods are in essence public locks that can be held by client either intentionally or accidentally and result in denial of service to other clients.</li>

<li>Avoid lazy initialization unless absolutely needed. The pattern delays initialization of a resource until needed but makes each access costlier.
</li>

<li>Use the holder class idiom for enabling lazy initialization on static fields. The idiom is given as follows:
## Lazy initializing static field


```java
class OuterClass {

 // Nested static class that holds the field
 // we want to lazily initialize
 private static class ObjectHolder{
 static final Object lazilyInitField = init();

 static Object init(){
 // ... Do expensive initialization here
 }
 }

 static Object getStaticField(){
 return ObjectHolder.lazilyInitField;
 }

}
```


The VM will synchronize access to the static field only to initialize the nested class. Once the nested class is initialized, the VM will patch the code so that subsequent access to the field does not involve any testing or synchronization.</li>

<li>Use double checked locking idiom for lazily initializing instance fields. The idiom is given below:
## Lazily initializing instance fields


```java
class DCL {

 volatile Object object;

 void getObject() {

 if (object == null) { // First check with no locking

 synchronized (this) {
 if (object == null){ // Second check with locking
 object = // ... Do expensive initialization here
 }
 }
 }

 return object;
 }

}
```


Note, the above idiom didn't work on versions of Java prior to 1.5. We can apply the double check locking idiom to static fields as well but the holder class idiom is a better fit for those situations.

In the given implementation of double check locking, after the object has been initialized for the first time, each subsequent access reads the <code>volatile</code> field twice. Once in the if condition and once when it is being returned. Volatile reads can be expensive and we can improve on the performance by reading the volatile field in a local variable only once as shown below.
## Improved double check locking


```java
class ImprovedDCL {

 volatile Object object;

 void getObject() {

 Object localVar = object; // Read volatile fields only once
 if (localVar == null) { // First check with no locking

 synchronized (this) {
 if (object == null){ // Second check with locking
 object = // ... Do expensive initialization here
 }
 }
 }

 // Return localVar and not object which would have caused
 // the second read of the volatile field
 return localVar;
 }

}
``` 

</li>


<li>Consider using single checked idiom where repeated initializations can be tolerated or are desired. The single check idiom is similar to the double checked idiom without the second check.
## Single check idiom


```java
class SingleCheck {

 volatile Object object;

 void getObject() {

 if (object == null) { // Single check with no locking
 object = // ... Do expensive initialization here
 }

 return object;
 }

}
```

Note the field is still declared <code>volatile</code>. If you don’t care whether every thread recalculates the value of a field, and the type of the field is a primitive other than long or double, then you may choose to remove the volatile modifier from the field declaration in the single check idiom. This variant is known as the racy single check idiom. It speeds up field access on some architectures, at the expense of additional initializations (up to one per thread that accesses the field). This technique is used by <code>String</code> instances to cache their hash codes.</li>


<li>Programs should never rely on the thread scheduler for correctness or performance. Such programs may not be portable. The best way to write a robust, responsive, portable program is to ensure that the average number of runnable threads is not significantly greater than the number of available processors in the system. Threads that are waiting aren't considered runnable.</li>

<li>Busy-waiting should be shunned for coordination among threads. It is a common folly to program a thread to repeatedly check for an event to happen. Besides making the program vulnerable to the vagaries of the scheduler, busy-waiting greatly increases the load on the processor, reducing the amount of useful work that other threads can accomplish.</li>

<li>Avoid tweaking thread priorities or using Thread.yield to fix liveness (ability to make progress) issues in a program. Thread priorities are among the least portable features of the Java platform and the resulting program will be neither robust nor portable.</li>


<li>Avoid using thread groups. <code>ThreadGroup</code> are considered obsolete.</li>
</ol>
</div>

This lesson lists gotchas of Java concurrency.

Java Ecosystem

Methods

Classes

Interfaces

Inheritance

Lambda Expressions

Generics

Multi-Threading

Memory Management

Collections

Exceptions

Reflection

Serialization

Miscellaneous Topics

Java in Practice

Patterns

The End

Concurrency

Notes on Concurrency