While using Synchronization my threads are working one after the other , the same happens when i have only one thread which executes the instructions one after the other so what's the use of creating multiple threads.
class Myclass1 extends Thread
{
public void run()
{
System.out.println("Running in class 1");
}
}
class Myclass2 extends Thread
{
public void run()
{
System.out.println("Running in class 2");
}
}
class Driver
{
synchronized public static void main(String[]args)
{
Myclass1 obj1=new Myclass1();
Myclass2 obj2=new Myclass2();
obj1.start();
obj2.start();
System.out.println("Hello");
}
}
Steven C said, in a nutshell, that threads can be used to achieve parallel computations. That's true, but it's not the only thing that threads are good for. In fact, threads were in wide-spread use long before parallel computation was possible outside of cutting-edge computer engineering laboratories.
Threads are a model of concurrent computing, which is a broader category. All parallel algorithms are concurrent algorithms, but not all concurrent algorithms exploit parallelism. Simply put, "concurrency" means that the program has two or more activities that run, mostly independently of each other, at the same time.
A classic example is a network server that is able to serve several different clients at the same time. Whatever it's doing for any one client may be completely unrelated to what it's doing for any other client. If the server creates one thread for each active client, then the state of the work that any thread is doing for its client is implicit in the context registers and the call stack of the thread—That is to say, the program counter and the currently nested function calls and the local variables of those functions contain all of the information about what the thread is doing for the client.
That makes reading the code easy* because the code looks just like the code of a single-threaded server that can only handle one client at a time would look. It looks just like the single-threaded code that we all learned to write when we were beginners. One alternative to using a thread-per-client is to have a single thread call something like Linux's select to await the next message from any client, and then it has to look up an object that explicitly encodes the state of that client, and call some routine that continues the work from that point onward. Some servers are built that way, and for good reasons, but their code can be significantly more complicated than the thread-per-client model.
Note that, in the case of our thread-per-client server, if there are multiple CPUs available, the program will automatically exploit them, and handle simultaneous client requests in truly parallel fashion, but even with just a single CPU, the model still works, and the benefits of multi-threading still are worth while.
* Reading multithreaded code may be easy, but writing correct multithreaded code is a whole 'nother story. Even so, code that gets written one time may be read many times, so even just making it easier to read usually is a win.