THREADS
Why we need threads?
Consider a scenario where you have a GUI application named MultiThreading. What our application does is, based on user inputs, it fetches data a database server and when the read button is clicked, the results are displayed. In a single thread model, the user executes a query which fetches a huge amount of data. Now as it is a single thread model, when the application is fetching the data if the user clicks on the read button, the application looks as if it has hung. The user is pissed, reports the application as a stupid one and your application is dumped.
Another scenario, you are developing a mobile game in java. u need to update the various game attributes while the game is still going on. If this is implemented in a single thread model, the user will never play your game again. Take my word for it. Reason, the sucking animation of the game.
Look around, everything is multi-threaded.

Why we dont need threads?
The only and only reason for this is, multi-threading causes havoc in programs which otherwise would have run very smoothly. Take for example the classic banking example. Customer A has a debit card and he has also got an add-on card for B(I never said B was A’s girl friend). A’s bank account has twenty thousand. I am sorry to break the myth but we software engineers are really under-paid. Now, A really likes a Cannon camera which is worth 19000. A is really excited and doesnt think twice before deciding to swipe his credit card. Meanwhile, B was out shopping and she liked a Swaroski crystal showpiece which was worth 5000. Now comes the tricky part. A swipes his card, the card is validated, checked if it has sufficient funds and the amount is added to his credit. Just before the debit transaction is recorded in the database, B swipes the add on card, the card is validated and checked if it has sufficient funds. Now as the amount from A has not been deducted, it shows 20000 as debit limit and hence the transaction is successful. So, now you are happy that with 20000 u buy stuff worth 24000. But the guys at the bank are really angry, and they change their design and make the withdrawal part synchronized.(Here synchronized means only one thread can access the shared resource at a time.) And we are back into our poverty.

MAKE YOUR HANDS DIRTY
Enough of theory, time to start coding. One last thing, Threads are parallel processes that you spawn to achieve more computation power.

Two ways to create thread execution:
1) Extend the Thread class
2) Implement the Runnable interface


public class ExtendThread extend Thread{
/* Declare class variables
/* Have your own methods
public void run(){
/*This is where the new thread execution is started
}


public class ExtendThread implements Runnable{
/* Declare class variables
/* Have your own methods
public void run(){
/*This is where the new thread execution is started
}


As you can see both the demo classes have one method in common and that is public void run(). The speciality of this method is that it acts as the main method for your new thread. This is the lowest entry in the new thread stack.

There are two very important methods which are inherited from the Object class. Those are the wait and notify methods. You can guess from this, how important multi threading is to Java.

Lets dig a little bit deeper now.

public class Thread1 implements Runnable{
public void run() {
try{
for( int i = 0; i < 10; i++ ){
System.out.println("Thread1 is running.");
Thread.sleep(20);
}
}catch( InterruptedException ex){
ex.printStackTrace();
}
}
}


public class Thread2 implements Runnable{
public void run() {
try{
for( int i = 0; i < 10; i++ ){
System.out.println("Thread2 is running.");
Thread.sleep(20);
}
}catch( InterruptedException ex){
ex.printStackTrace();
}
}
}



public class TheMain {
public static void main( String[] args ){
Thread1 thread1 = new Thread1();
Thread2 thread2 = new Thread2();
Thread thread_sample1 = new Thread(thread1);
Thread thread_sample2 = new Thread(thread2);
thread_sample1.start();
thread_sample2.start();
}
}


You expect the output to be alternate outputs of Thread1 and Thread2. But you cannot guarantee that. A good way to do it will be discussed later.

When you are implementing the Runnable interface the coding effort is considerably higher, but it is always a good practice to use the Runnable interface than extend the Thread class. This way you have the flexibity to extend any other class if you want. Lets say you have a small GUI program. How will u extend the Applet class if you are extending the Thread class already.

Some methods are new in this code example. The sleep method is a static method in the Thread class which puts the current thread into sleep. The Thread constructor in the main method takes in a Runnable object as argument.
For other constructors of Thread class, consult the API.

isAlive()
There is a time lag before the thread is actually executed by the JVM and after the thread has been terminated. The isAlive() method can be used to know if a Thread is running or not.

join()
Lets say ihave created a new thread and continued with my work. But now after a certain amount of code has been executed i want my main thread to wait for the new thread which i had created and only after the new thread has completed its work, i want my main thread to continue. This can be done by using join()
In the previous code example, add

System.out.println("No Joining.")

Now remove the above bit and insert the following code.

try {
thread_sample2.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("With joining");


You will see the difference.

currentThread(), getName() and setName()
Lets consider a scenario where you want to execute a certain part of code by a specific thread and not by others. Lets for example consider an example where we have three friends Raj, Tina and Hina. Now, Tina likes Raj while Raj likes Hina. Only if Tina could block the calls from Hina to Raj, she would have a chance with Raj. Now lets think from Java angle, Raj, Tina and Hina are three classes and you want to implement the above use cases. You get the thread name which is invoking the method in the Raj class and if it is Tina then block the call. The getName and setName methods help in setting and getting the name of a thread while the currentThread gives you the current thread which is executing the method.

public class Raj{
public void attendCall(){
String name = Thread.currentThread().getName();
if ( name.equalsIgnoreCase("Hina"))
System.out.println("Call is blocked.");
else
System.out.println("Call accepted");
}
}



public class Tina{
public void makeCall(){
System.out.println("Tina trying to call");
Thread.currentThread().setName("Tina");
new Thread1().attendCall();
}
}



public class Hina{
public void makeCall(){
System.out.println("Hina trying to call");
Thread.currentThread().setName("Hina");
new Thread1().attendCall();
}
}

If only i could do this in real world.
There is a catch here. When extending the Thread class, you have the getName() method. If you use that, the thread name which you will get is the name of the thread which loaded the class and not the one which is calling the method. This is the reason why you have to first get the current thread( use Thread.currentThread()) and then use the getName() method on it.

One last thing before the basic part is over. You are generally asked on how the garbage collector in case of multi threading. Even after the thread has stopped, the garbage collector does not collect it because it has still not been dereferenced. But for all the other resources in the spawned thread, everything is garbage collected when the run method is completed. So dereference your thread variable to null and everything you can do is done.

SYNCHRONIZATION
Synchronization is necessary to determine how one thread handles data which are also accessed by another thread. Consider the banking example given. It is one of the most basic things which requires thread access control. Another example can be, lets say you have a database where you want to log the transactions to your online shopping shop. But instead of the transasctional way, you want to store the details in bulk mode. Now you store the details in an array list or any other collection object. When you are bulk uploading, what about the collectio object then, it still might get updated by a new transaction. This can be avoided using synchronization.
A important term here is RACE CONDITION. A race condition is defined as a race between two separate processes or threads to do an action on a common resource in which an action by one thread will corrupt the data for the thread which arrives later.
In synchronization, a thread must obtain a lock to execute the synchronized block and while a thread has the lock, another thread cannot obtain the same lock. When the thread comes out of the synchronized part, it gives up the lock and the other waiting thread can access the synchronized part.

The lock object can be of method scope or class scope and even of local scope.
We will get our hands dirty later. This is theory time.
A very dreaded condition in multi-threading is deadlock. How do you define a deadlock? The ideal defination for it is, when two mutually wait for each other to complete a common task. I know it doesnt make sense, but the next couple of examples will explain. Lets say, we are at LandMark and the store is out of cash(Which is impossible!!). Now you have got a Java, Complete Refernce for 450 bucks and you have a 500 rupee note. The cashier is not ready to bill you because of lack of change. I have bought a Sin City comic for 150 bucks and by good luck i have the exact change. In the real world, we both talk, and bill first and this way the cashier has 50 bucks change and we both get our books. But imagine that because of some perverse rule, we cannot break the queue and there is no cash inflow for the million years. We both are stuck there for ever. This is what a dead lock is. The threads are dumb enough not to reconcile and keep waiting.
Synchronization has a big negative performance impact on your application so use it carefully and intelligently. Use it only for the part where a value is being changed/updated. Synchronizing a whole method increases the chances of a deadlock. The only reason for saying this is that increasing the scope increases the chances. And dont synchronize an object whose value is being changed inside the synchronized block.

wait(), notify() and notifyAll()
The funda behind using these methods is to make a thread wait till a particular condition is fulfilled. For example lets say we have two threads A and B which satisfies a dangerous race condition. So now you make A wait till it is notified by B. These two methods are inherited from the Object class and hence every object in Java has these methods. The wait and notify methods are used alongwith synchronization blocks to avoid race conditions. If you have more than one thread waiting, use the notifyAll() method.
Lets say, you have a lot of threads waiting for one thread to complete its job. Now as soon as one thread completes the job, it notifies all and the all the threads wake up to get the object lock. But only one thread can acquire the lock and as soon as the other threads find out that the lock has already been obtained by another thread, it goes to sleep again. This puts unnecessary load on the jvm. This can be avoided by using an array of threads and deciding which thread to be notified. The drawback of this method is that it can be quite confusing and might result is a deadlock if not properly checked.
Code Snippet with thread specific notify() calls. I have added a code which coordinates the order of execution in three threads.

public class Locker {
private Object[] target_locks = null;
private static Locker target;
public Locker(int number){
target_locks = new Object[number];
for(int i = 0; i < number; i++)
target_locks[i] = new Object();
target = this;
}
public void wait( int targetNumber ){
synchronized( target_locks[targetNumber] ){
try {
target_locks[targetNumber].wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public void notify( int targetNumber ){
synchronized (target_locks[targetNumber]) {
target_locks[targetNumber].notify();
}
}
public synchronized Object getLock(int number){
return target_locks[number];
}
public static Locker getInstance(){
return target;
}
}

This is the locker class. As the name suggests, this is the class which stores all the lock objects. We do not call the wait and notify methods from the threads, instead we use this class for the wait and notify calls.

public class Thread1 implements Runnable{
public Locker target = Locker.getInstance();
public void run() {
int counter = 1;
synchronized(target.getLock(0)){
try{
for( int i = 0; i < 10; i++ ){
System.out.println("Thread1 is running: " + counter);
counter++;
target.notify(1);
if (i != 9)
target.wait(0);
}
}catch( Exception ex){
ex.printStackTrace();
}
}
System.out.println("Thread1 is exiting.");
}
public void setLock(Locker target){
this.target = target;
}
}


public class Thread2 implements Runnable{
public Locker target = Locker.getInstance();
public void run() {
int counter = 1;
synchronized(target.getLock(1)){
try{
for( int i = 0; i < 10; i++ ){
System.out.println("Thread2 is running: " + counter);
counter++;
target.notify(2);
if (i != 9)
target.wait(1);
}
}catch( Exception ex){
ex.printStackTrace();
}
}
System.out.println("Thread2 is exiting.");
}
public void setLock(Locker target){
this.target = target;
}
}


public class Thread3 implements Runnable{
public Locker target = Locker.getInstance();
public void run() {
int counter = 1;
synchronized(target.getLock(2)){
try{
for( int i = 0; i < 10; i++ ){
System.out.println("Thread3 is running: " + counter);
counter++;
target.notify(0);
if (i != 9)
target.wait(2);
}
}catch( Exception ex){
ex.printStackTrace();
}
}
System.out.println("Thread3 is exiting.");
}
public void setLock(Locker target){
this.target = target;
}
}


public class ThreadCaller {
public static void main( String args[] ){
Locker target = new Locker(3);
Thread1 thread1 = new Thread1();
Thread2 thread2 = new Thread2();
Thread3 thread3 = new Thread3();
Thread runna1 = new Thread(thread1);
Thread runna2 = new Thread(thread2);
Thread runna3 = new Thread(thread3);
runna1.start();
runna2.start();
runna3.start();
}
}

Each thread has a lock associated with it. The Thread1 notifies the Thread2, Thread2 notifies Thread3 and Thread3 notifies Thread1. This way, the execution transfers from Thread1 to Thread2 and then to Thread3 and back to Thread1.
The inter-thread communication can be done by setting thread priority and then using notifyAll(). To set the priority of a thread use the setPriority(int i) method of the Thread class.

Someone write this code. I am pretty tired.

To end this basic introduction, we will discuss about the two types of threads that exist in Java. The two types are daemon and user threads. The two types of threads are very similar to each other. Daemon threads are those threads which are spawned by the JVM internally to fulfil any given task. But, the user can play God here. He can change the thread from user to deamon and vice versa anytime he wishes before the thread is started.(Mind this. Once the thread starts, no changing buddy!) After the user thread has exited, the JVM checks for any running threads. IF all the threads running are daemon threads, then the JVM exits the program and terminates all the threads itself. Okie! i guess i did my part of making you understand what a daemon thread is. Now you start thinking, why the hell do i need a bloody daemon thread. Isnt getting bogged down by user threads enough. Now consider this my friend, everyone knows about the garbage collector of JVM. This is the magic bit which removes the developer’s overhead of removing obsolete objects from the memory. What if the GC was a user thread? The JVM can never terminate a user thread, so you see the JVM can never shut down after it runs our application. Now if GC is a daemon thread, the JVM checks for any user thread, as none is running, it terminates the garbage collector thread and exits. Neat! Isn’t it. Now lets see for any practical use. One think which i can think of is logging. I dont care if logging is successful or not, i want my JVM to shutdown when i exit it. But, my client wants to see the logs to check if everything is going according to the way he had specified. I create a daemon thread whose only job is to write into the logs. This provides a better abstraction layer. Now what if writing to the file is time consuming and while the daemon thread is writing the logs, the user thread exits. My client doesnt want to loose any logs. Luckily a small work around fixes this.
Spawn a new user thread from your daemon thread which does nothing. And only after the logs have been written, terminate the user thread. This way the daemon thread also exits and it doesn’t depend on your application.