Q31: What is a Volatile variable?

Ans: If you are using “volatile” keyword for a variable than Java guarantees every change on volatile variable will be visible to other thread. It will always read a variable value from “Main memory” and never from CPU Cache and Registers. Similarly every write will also be done in “Main memory”. In one line: volatile variables read and write always happen from Main memory.

If thread is doing any operation on a volatile variable, it will always read from main memory and copy it in CPU cache than process the variable. Once processing is done immediately flush back from CPU cache to main memory (It always update main memory, so other thread will read from main memory , latest value).

Q32. What all guarantees java volatile variable?

Ans: “volatile variable” gives below guarantee

1. Let’s assume there are two threads ThreadA and ThreadB. If ThreadsA start writing to volatile variable and has few other variables in memory and at the same time ThreadB reads the same volatile variable. Then all variables which were visible to ThreadA before writing the volatile variable, same variable will be visible to ThreadB after reading “volatile variable”

2. Instruction reordering: For performance reason JVM re-order instructions). So before and after of volatile variable instructions may re-order, but volatile read and write instructions can not be re-ordered.

int count1=0;

int count2=0;

int count3=0;

volatile count4=0;

int coount5=0;

int count6=0;

int count7=0;

JVM can re-order count1 to count3 only if writing happens before writing count4 variable. Similarly JVM can re-order count5 to count7 only if writing happens before count4.

Suppose thread writes count4 from CPU cache to main memory and it also has other variable like count1 to count3 and count5 to count7 in memory, then it will also flush these variables to main memory.

Q33. Is volatile guarantees 100% visibility?

Ans: Because there is no lock involved. Hence, small time gap while reading and writing back to main memory can lead to “Race condition”.

Q34. When is volatile good to use?

Ans: If only one thread is writing and all other threads just need to read the variable. Hence, all the reading thread will always read the latest value written to main memory, and they are not going to change the value, hence no “Race condition”

Q35. Does volatile impact the overall performance?

Ans: Yes, because reading from main memory and writing to main memory is always expensive than reading and writing from CPU cache or registers.

Q36. What is a ThreadLocal?

Ans: ThreadLocal as name suggests, they are local to each thread. It cannot be shared across thread. So whatever read and write happens to ThreadLocal object it will be visible to only same local thread.

Q36. How you will use ThreadLocal?

Ans: ThreadLocal instance can be created as below.

private ThreadLocal threadLocal = new ThreadLocal();

We can set the value in threadLocal as below.

threadLocal.set("Value");

You read the value stored in a ThreadLocal like this:

String threadValue = (String) threadLocal.get();

Q37. What is thread signaling?

Ans : Thread signaling is a way by which thread can communicate with each other. For thread signaling threads will use a common objects lets say “CommonObjects”. And thread will call “wait()” ,”notify()” or “notifyAll()” method to communicate with each other.

Q38. Signaling methods are defined in which class?

Ans: As mentioned above all methods “wait()” ,”notify()” or “notifyAll()” are defined on Object level. Hence, every objects will have these methods. And also mentioned all thread must be using common object to get signal from each other. So thread will call these methods on common objects.

Q39. What is the use of “wait()” ,”notify()” or “notifyAll()” ?

Ans : Suppose we have two three threads ThreadA, ThreadB and ThreadC. All needs to execute below code block (this is not complete code)

synchronized write(){

counter=counter+1;

this.notify();

}

synchronized read(){

            this.wait()

return counter;

}

Now ThreadA is executing write() method and ThreadB are executing read() method. To entering in synchronized block each thread has first take a lock on common objects (that is this object, in this case). Let’s assume ThreadB get a lock and to read the counter value, and ThreadA is waiting for getting lock on this object to enter write() method. As soon as ThreadB reaches to this.wait() it will release the lock and wait for notifications from other thread to return counter value. Now, ThreadA can get a lock and start writing counter value and once done it will notify() waiting thread (in this case ThreadB) and release the lock. As soon as thread get notification it will process and return the updated counter value.

Q40. Is it necessary to have wait() and notify() calls to be in synchronized block?

Ans: Yes, wait(), notify() and notifyAll() can be called from synchronized block only. They must have a lock on common object. Than only they can call these methods.

Premium Training : Spark Full Length Training : with Hands On Lab

Previous Next