http://java-questions.com/Threads_interview1_questions.

html


Java Threads Interview Questions
Q1) If a class has a synchronised method and non-synchronised method, can
multiple threads execute the non-synchronised methods?
Ans) Yes. If a class has a synchronised and non-synchronised methods, multiple threads can
access the non-synchronised methods.
Q2) If a thread goes to sleep does it hold the lock?
Ans) Yes when a thread goes to sleep it does not release the lock.
Q3)Can a thread hold multiple locks at the same time?
Ans) Yes. A thread can hold multiple locks at the same time. Once a thread acquires a lock
and enters into the synchronized method / block, it may call another synchronized method
and acquire a lock on another object.
Q4) Can a thread call multiple synchronized methods on the object of which it hold
the lock?
Ans) Yes. Once a thread acquires a lock in some object, it may call any other synchronized
method of that same object using the lock that it already holds.
Q5) Can static methods be synchronized?
Ans) Yes. As static methods are class methods and have only one copy of static data for the
class, only one lock for the entire class is required. Every class in java is represented by
java.lang.Class instance. The lock on this instance is used to synchronize the static
methods.
Q6) Can two threads call two different static synchronized methods of the same
class?
Ans) No. The static synchronized methods of the same class always block each other as only
one lock per class exists. So no two static synchronized methods can execute at the same
time.
Q7)Does a static synchronized method block a non-static synchronized method?
Ans)No As the thread executing the static synchronized method holds a lock on the class
and the thread executing the non-satic synchronized method holds the lock on the object on
which the method has been called, these two locks are different and these threads do not
block each other.
Q8) Once a thread has been started can it be started again?
Ans) No. Only a thread can be started only once in its lifetime. If you try starting a thread
which has been already started once an IllegalThreadStateException is thrown, which is a
runtime exception. A thread in runnable state or a dead thread can not be restarted.
Q9) When does deadlock occur and how to avoid it?
Ans) When a locked object tries to access a locked object which is trying to access the first
locked object. When the threads are waiting for each other to release the lock on a
particular object, deadlock occurs .
Q10) What is a better way of creating multithreaded application? Extending
Thread class or implementing Runnable?
Ans) If a class is made to extend the thread class to have a multithreaded application then
this subclass of Thread can not extend any other class and the required application will have
to be added to this class as it can not be inherited from any other class. If a class is made
to implement Runnable interface, then the class can extend other class or implement other
interface.
Q11) Can the start() method of the Thread class be overridden? If yes should it be
overridden?
Ans) Yes the start() method can be overridden. But it should not be overridden as its
implementation in thread class has the code to create a new executable thread and is
specialised.
Q12) What are the methods of the thread class used to schedule the threads?
Ans) The methods are as follows:
public static void sleep(long millis) throws InterruptedException
public static void yield()
public final void join() throws InterruptedException
public final void setPriority(int priority)
public final void wait() throws InterruptedException
public final void notify()
public final void notifyAll()
Q13) Which thread related methods are available in Object class?
Ans) The methods are:
public final void wait() throws Interrupted exception
public final void notify()
public final void notifyAll()
Q14) Which thread related methods are available in Thread class?
Ans) Methods which are mainly used :
public static void sleep(long millis) throws Interrupted exception
public static void yield() public final void join() throws Interrupted exception
public final void setPriority(int priority)
public void start()
public void interrupt()
public final void join()
public void run()
public void resume()
Q15) List the methods which when called the thread does not release the locks
held?
Ans) Following are the methods.
notify()
join()
sleep()
yield()
Q16) List the methods which when called on the object the thread releases the
locks held on that object?
Ans) wait()
Q17) Does each thread has its own thread stack?
Ans) Yes each thread has its own call stack. For eg
Thread t1 = new Thread();
Thread t2 = new Thread();
Thread t3 = t1;
In the above example t1 and t3 will have the same stack and t2 will have its own independent stack.
Q18) What is thread starvation?
Ans) In a multi-threaded environment thread starvation occurs if a low priority thread is not
able to run or get a lock on the resoruce because of presence of many high priority threads.
This is mainly possible by setting thread priorities inappropriately.
Q19) What is threadLocal variable?
Ans) ThreadLocal is a class. If a variable is declared as threadLocal then each thread will
have a its own copy of variable and would not interfere with the other's thread copy. Typical
scenario to use this would be giving JDBc connection to each thread so that there is no
conflict.
ThreadLocal class by JAVA API
public class ThreadLocal {
public Object get();
public void set(Object newValue);
public Object initialValue();
}

Implementation of ThreadLocal
public class ConnectionDispenser {
private static class ThreadLocalConnection extends ThreadLocal {
public Object initialValue() {
return DriverManager.getConnection(ConfigurationSingleton.getDbUrl());
}
}

private static ThreadLocalConnection conn = new ThreadLocalConnection();

public static Connection getConnection() {
return (Connection) conn.get();
}
}

If a synchronized method calls another non-
synchronized method, is there a lock on the non-
synchronized method



If you are in a synchronized method, then calls to other methods that are
also synchronized are locked. However calls to non-synchronized are not locked --
anyone can call them at the same time.
public synchronized void someSynchronizedMethod() {
...
someNonSynchronizedMethod();
...
}

// anyone can call this method even if the someSynchronizedMethod()
method has
// been called and the lock has been locked
public void someNonSynchronizedMethod() {
...
}
But you are asking two different things in your question:
In Java, if a synchronized method contains a call to a non-synchronized, can another
method still access the non-synchronized method at the same time?
Yes. Other methods can access non-synchronized methods.
Basically what I'm asking is everything in the synchronized method have a lock on it
(including calls to other synchronized methods)?
Uh, yes. Other calls to synchronized methods are locked. But non-synchronized
methods are not locked.
Also, remember that if the method is static then the lock is on the Class object in
the ClassLoader.
// this locks on the Class object in the ClassLoader
public static synchronized void someStaticMethod() {
If the method is an instance method then the lock is on the instance of the class.
// this locks on the instance object that contains the method
public synchronized void someInstanceMethod() {
There are 2 different locks in those 2 cases.
Lastly, when you are dealing with synchronized instance methods, each instance of
the class is what is locked. This means that two threads could be in the
same synchronized method at the same time with different instances. But if 2 threads
try to operate on synchronized methods on the same instance, one will block until the
other one exits the method

f thread A calls synchronized method M1 which in turn calls unsynchronized method
M2, then thread B can still call M2 without blocking.
Synchronized method acquires and releases intrinsic lock on the object on which it is
called. This is why it may block. Unsynchronized method doesn't attempt to acquire any
lock (unless it is done explicitly in the code).
Thus, if you need to ensure mutual exclusion for M2 as well, you should make it
synchronized regardless of whether its callers (like M1) are synchronized or not
or those who are not familiar static synchronized method locked on class object e.g. for string class
its String.class while instance synchronized method locks on current instance of Object denoted by this
keyword in Java. Since both of these object are different they have different lock so while one thread is executing
static synchronized method , other thread in java doesnt need to wait for that thread to return instead it will acquire
separate lock denoted byte .class literal and enter into static synchronized method. This is even a popular multi-
threading interview questions where interviewer asked on which lock a particular method gets locked, some time also
appear in Java test papers.

Bottom line is that never mix static and non static synchronized method for protecting same resource.


Example of Mixing instance and static synchronized methods
Here is an example of multithreading code which is using static and non static synchronized method to
protect same shared resource:

public class SynchornizationMistakes {
private static int count = 0;

//locking on this object lock
public synchronized int getCount(){
return count;
}

//locking on .class object lock
public static synchronized void increment(){
count++;
}

}

here shared count is not accessed in mutual exclusive fashion which may result in passing incorrect count to caller
of getCount() while another thread is incrementing count using static increment() method.

Thats all on this part of learning from mistakes in Java. Now we know that static and non
static synchronized method are locked on different locks and should not be used to protect same shared object.


Read more: http://javarevisited.blogspot.com/2012/03/mixing-static-and-non-
static.html#ixzz33a8SO9pu

Important points of synchronized keyword in Java
1. Synchronized keyword in Java is used to provide mutual exclusive access of a shared
resource with multiple threads in Java. Synchronization in Java guarantees that, no two
threads can execute a synchronized method which requires same lock simultaneously or
concurrently.

2. You can use java synchronized keyword only
on synchronized method or synchronized block.

3. When ever a thread enters into java synchronized method or block it acquires a lock and
whenever it leaves java synchronized method or block it releases the lock. Lock is released
even if thread leaves synchronized method after completion or due to any Error or
Exception.

4. Java Thread acquires an object level lock when it enters into an
instance synchronized java method and acquires a class level lock when it enters into
static synchronized java method.

5. Java synchronized keyword is re-entrant in nature it means if a java
synchronized method calls another synchronized method which requires same lock
then current thread which is holding lock can enter into that method without acquiring lock.

6. Java Synchronization will throw NullPointerException if object used in java synchronized
block is null e.g. synchronized (myInstance) will
throws java.lang.NullPointerException if myInstance is null.

7. One Major disadvantage of Java synchronized keyword is that it doesn't allow concurrent
read, which can potentially limit scalability. By using concept of lock stripping and using
different locks for reading and writing, you can overcome this limitation of synchronized in
Java. You will be glad to know
that java.util.concurrent.locks.ReentrantReadWriteLock provides ready made
implementation of ReadWriteLock in Java.

8. One more limitation of java synchronized keyword is that it can only be used to control
access of shared object within the same JVM. If you have more than one JVM and need to
synchronized access to a shared file system or database, the Java synchronized keyword is
not at all sufficient. You need to implement a kind of global lock for that.

9. Java synchronized keyword incurs performance cost. Synchronized method in Java is
very slow and can degrade performance. So use synchronization in java when it absolutely
requires and consider using java synchronized block for synchronizing critical section only.

10. Java synchronized block is better than java synchronized method in Java because by
using synchronized block you can only lock critical section of code and avoid locking whole
method which can possibly degrade performance. A good example of java synchronization
around this concept is getInstance() method Singleton class. See here.

11. Its possible that both static synchronized and non static synchronized method can run
simultaneously or concurrently because they lock on different object.

12. From java 5 after change in Java memory model reads and writes are atomic for all
variables declared using volatile keyword (including long and double variables) and simple
atomic variable access is more efficient instead of accessing these variables via synchronized
java code. But it requires more care and attention from the programmer to avoid memory
consistency errors.

13. Java synchronized code could result in deadlock or starvation while accessing by
multiple thread if synchronization is not implemented correctly. To know how to avoid
deadlock in java see here.

14. According to the Java language specification you can not use Java synchronized
keyword with constructor its illegal and result in compilation error. So you can not
synchronized constructor in Java which seems logical because other threads cannot see the
object being created until the thread creating it has finished it.

15. You cannot apply java synchronized keyword with variables and can not use java
volatile keyword with method.

16. Java.util.concurrent.locks extends capability provided by java synchronized
keyword for writing more sophisticated programs since they offer more capabilities
e.g. Reentrancy and interruptible locks.

17. Java synchronized keyword also synchronizes memory. In fact java synchronized
synchronizes the whole of thread memory with main memory.

18. Important method related to synchronization in Java
are wait(), notify() and notifyAll() which is defined in Object class. Do you know,
why they are defined in java.lang.object class instead of java.lang.Thread? You can
find some reasons, which make sense.

19. Do not synchronize on non final field on synchronized block in Java. because reference
of non final field may change any time and then different thread might synchronizing on
different objects i.e. no synchronization at all. example of synchronizing on non final field :
private String lock = new String("lock");
synchronized(lock){
System.out.println("locking on :" + lock);
}

any if you write synchronized code like above in java you may get warning "Synchronization
on non-final field" in IDE like Netbeans and InteliJ

20. Its not recommended to use String object as lock in java synchronized
block because string is immutable object and literal string and interned string gets stored in
String pool. so by any chance if any other part of code or any third party library used same
String as there lock then they both will be locked on same object despite being completely
unrelated which could result in unexpected behavior and bad performance. instead of String
object its advised to use new Object() for Synchronization in Java on synchronized block.

private static final String LOCK = "lock"; //not recommended
private static final Object OBJ_LOCK = new Object(); //better

public void process() {
synchronized(LOCK) {
........
}
}

21. From Java library Calendar and SimpleDateFormat classes are not thread-safe and
requires external synchronization in Java to be used in multi-threaded environment.


Probably most important point about Synchronization in Java is that, in the absence of
synchronized keyword or other construct e.g. volatile variable or atomic variable, compiler,
JVM and hardware are free to make optimization, assumption, reordering or caching of code
and data, which can cause subtle concurrency bugs in code. By introducing synchronization by
using volatile, atomic variable or synchronized keyword, we instruct compiler and JVM to not
to do that.


Update 1: Recently I have been reading several Java Synchronization and
Concurrency articles in internet and I come across jeremymanson's blog which works in
google and has worked on JSR 133 Java Memory Model, I would recommend some of this blog
post for every java developer, he has covered certain details about concurrent programming ,
synchronization and volatility in simple and easy to understand language, here is the
link atomicity, visibility and ordering.

Update 2: I am grateful to my readers, who has left some insightful comments on this post.
They have shared lots of good information and experience and to provide them more
exposure, I am including some of there comments on main article, to benefit new readers.


@Vikas wrote
Good comprehensive article about synchronized keyword in Java. to be honest I have
never read all these details about synchronized block or method at one place. you may want
to highlight some limitation of synchronized keyword in Java which is addressed by explicit
locking using new concurrent package and Lock interface :

1. synchronized keyword doesn't allow separate locks for reading and writing. as we know
that multiple thread can read without affecting thread-safety of class, synchronized keyword
suffer performance due to contention in case of multiple reader and one or few writer.

2. if one thread is waiting for lock then there is no way to time out, thread can wait
indefinitely for lock.

3. on similar note if thread is waiting for lock to acquired there is no way to interrupt the
thread.

All these limitation of synchronized keyword is addressed and resolved by
using ReadWriteLock and ReentrantLock in Java 5.

@George wrote
Just my 2 cents on your great list of Java Synchronization facts and best practices :

1) synchronized keyword in internally implemented using two byte code
instructions MonitorEnter and MonitorExit, this is generated by compiler. Compiler also
ensures that there must be a MonitorExit for every MonitorEnter in different code path
e.g. normal execution and abrupt execution, because of Exception.

2) java.util.concurrent package different locking mechanism than provided by
synchronized keyword, they mostly used ReentrantLock, which internally use CAS
operations, volatile variables and atomic variables to get better performance.

3) With synchronized keyword, you have to leave the lock, once you exist a synchronized
method or block, there is no way you can take the lock to other
method. java.util.concurrent.locks.ReentrantLock solves this problem by
providing control for acquiring and releasing lock, which means you can acquire lock in
method A and can release in method B, if they both needs to be locked in same object lock.
Though this could be risky as compiler will neither check nor warn you about any accidental
leak of locks. Which means, this can potentially block other threads, which are waiting for
same lock.

4) Prefer ReentrantLock over synchronized keyword, it provides more control on lock
acquisition, lock release and better performance compared to synchronized keyword.

5) Any thread trying to acquire lock using synchronized method will block indefinitely, until
lock is available. Instead this, tryLock() method
of java.util.concurrent.locks.ReentrantLock will not block if lock is not available.
Having said that, I must say, lots of good information.




Read more: http://javarevisited.blogspot.com/2011/04/synchronization-in-java-
synchronized.html#ixzz33a8tMBbE
Why do we need Synchronization in Java?
If your code is executing in multi-threaded environment, you need synchronization for
objects, which are shared among multiple threads, to avoid any corruption of state or any
kind of unexpected behavior. Synchronization in Java will only be needed if shared object is
mutable. if your shared object is either read only or immutable object, than you don't
need synchronization, despite running multiple threads. Same is true with what threads are
doing with object if all the threads are only reading value then you don't
require synchronization in Java. JVM guarantees that Java synchronized code will only be
executed by one thread at a time. In Summary Java synchronized Keyword provides
following functionality essential for concurrent programming :

1) synchronized keyword in Java provides locking, which ensures mutual exclusive access
of shared resource and prevent data race.

2) synchronized keyword also prevent reordering of code statement by compiler which can
cause subtle concurrent issue if we don't use synchronized or volatile keyword.

3) synchronized keyword involve locking and unlocking. before entering
into synchronized method or block thread needs to acquire the lock, at this point it reads
data from main memory than cache and when it release the lock, it flushes write operation
into main memory which eliminates memory inconsistency errors.


Read more: http://javarevisited.blogspot.com/2011/04/synchronization-in-java-
synchronized.html#ixzz33a8Y0pUr
Prior to Java 1.5 synchronized keyword was only way to provide synchronization of shared
object in Java. Any code written by using synchronized block or enclosed
inside synchronized method will be mutually exclusive, and can only be executed by one
thread at a time. You can have both static synchronized method and non static synchronized
method and synchronized blocks in Java but we can not have synchronized variable in java.
Using synchronized keyword with variable is illegal and will result in compilation error.
Instead of synchronized variable in Java, you can have java volatile variable, which
will instruct JVM threads to read value of volatile variable from main memory and dont
cache it locally. Block synchronization in Java is preferred over method synchronization in
Java because by using block synchronization, you only need to lock the critical section of
code instead of whole method. Since synchronization in Java comes with cost of performance,
we need to synchronize only part of code which absolutely needs to be synchronized.


Example of Synchronized Method in Java
Using synchronized keyword along with method is easy just apply synchronized keyword
in front of method. What we need to take care is that static synchronized method locked on
class object lock and non static synchronized method locks on current object (this). So
its possible that both static and non static java synchronized method running in parallel.
This is the common mistake a naive developer do while writing Java synchronized code.



public class Counter{

private static int count = 0;

public static synchronized int getCount(){
return count;
}

public synchoronized setCount(int count){
this.count = count;
}

}

In this example of Java synchronization code is not properly synchronized because
both getCount() and setCount() are not getting locked on same object and can run in
parallel which may results in incorrect count. Here getCount() will lock
in Counter.class object while setCount() will lock on current object (this). To make
this code properly synchronized in Java you need to either make both method static or non
static or use java synchronized block instead of java synchronized method.By the way this is
one of the common mistake Java developers make while synchronizing their code.

Example of Synchronized Block in Java
Using synchronized block in java is also similar to using synchronized keyword in methods.
Only important thing to note here is that if object used to lock synchronized block of
code, Singleton.class in below example is null then Java synchronized block will throw
a NullPointerException.

public class Singleton{

private static volatile Singleton _instance;

public static Singleton getInstance(){
if(_instance == null){
synchronized(Singleton.class){
if(_instance == null)
_instance = new Singleton();
}
}
return _instance;
}

This is a classic example of double checked locking in Singleton. In this example of
Java synchronized code, we have made only critical section (part of code which is creating
instance of singleton) synchronized and saved some performance. If you make
whole method synchronized than every call of this method will be blocked, while you only
need blocking to create singleton instance on first call. By the way, this is not the only way to
write thread-safe singleton in Java. You can use Enum, or lazy loading to avoid thread-safety
issue during instantiation. Even above code will not behave as expected because prior to Java
1.5, double checked locking was broker and even with volatile variable you can view half
initialized object. Introduction of Java memory model and happens before guarantee in Java
5 solves this issue. To read more about Singleton in Java see that.


Read more: http://javarevisited.blogspot.com/2011/04/synchronization-in-java-
synchronized.html#ixzz33a8dNRd8