process Vs Thread

1. A process is a collection of virtual memory space, code, data, and system resources. And
2. A thread is code that is to be serially executed within a process. 

                A processor executes threads, not processes, so each application has at least one process, and a process always has at least one thread of execution, known as the primary thread. A process can have multiple threads in addition to the primary thread.

Synchronization is for threads only it won't work for processes in Java. There is no utility in them working across processes, since the processes do not share any state that would need to be synchronized. A variable in one process will not have the same data as a variable in the other process


differences between threads and processes:
1. Threads are easier to create than processes since they don't require a separate address space.

2. difference between a thread and a process is that threads within the same process share the same address space, whereas different processes do not.i.e.Processes are independent of each other.  Threads, since they share the same address space are interdependent, so caution ust be taken so that different threads don't step on each other.

3.  A process can consist of multiple threads.


In Short Description :-
Process:
An instance of a program;
Executed in own address space
Independent entity to which system assigns resources  CPU time, memory Cannot access variables or other data structure in another process Process communicate using inter-process mechanisms like files, pipes, sockets

Thread
Is a particular execution path thru a process.
Multiple threads can share state info of a single process.
Thread share memory and system resources.
Can communicate thru shared variables and other memory structures
Context switching is faster than process.

Thread life cycle in java

Thread can have one of the following state at a time:

1. New
2. Runnable
3. Running
4. Waiting / Blocking
5. Dead

Transition between thread states

Following image represents the thread trasition from one state to other:

Thread state : New

• This is the state the thread is in after the Thread instance has been created, but the start() method has not been invoked on the thread.
• It is a live Thread object, but not yet a thread of execution. At this point, the thread is considered not alive.
• For example,

Thread myThread = new Thread(); // currently thread is in New state only

Thread state : Runnable

• This is the state a thread is in when it's eligible to run, but the scheduler has not selected it to be the running thread.
• A thread first enters the runnable state when the start() method is invoked, but a thread can also return to the runnable state after either running or coming back from a blocked, waiting, or sleeping state.
• When the thread is in the runnable state, it is considered alive.
• For example,

myThread.start(); // after invokation of this line myThread is now in Runnable state

Thread state : Running

• This is it. The "big time." Where the action is. This is the state a thread is in when the thread scheduler selects it (from the runnable pool) to be the currently executing process.
• A thread can transition out of a running state for several reasons, including because "the thread scheduler felt like it." 
• As per shown in above figure, There are several ways to get to the runnable state, but only one way to get to the running state: the scheduler chooses a thread from the runnable pool.

Thread state : Waiting or Blocking

• This is the state a thread is in when it's not eligible to run.
• So this is really three states combined into one, but they all have one thing in common: the thread is still alive, but is currently not eligible to run.
• In other words, it is not runnable, but it might return to a runnable state later if a particular event occurs.
• A thread may be blocked waiting for a resource (like I/O or an object's lock), in which case the event that sends it back to runnable is the availability of the resource.
• For example, if data comes in through the input stream the thread code is reading from, or if the object's lock suddenly becomes available. A thread may be sleeping because the thread's run code tells it to sleep for some period of time, in which case the event that sends it back to runnable is that it wakes up because its sleep time has expired.
• Or the thread may be waiting, because the thread's run code causes it to wait, in which case the event that sends it back to runnable is that another thread sends a notification that it may no longer be necessary for the thread to wait. The important point is that one thread does not tell another thread to block.
• Some methods may look like they tell another thread to block, but they don't. If you have a reference t to another thread, you can write something like this:

 myThread.sleep();   or     myThread.yield();

• But those are actually static methods of the Thread class—they don't affect the instance myThread; instead they are defined to always affect the thread that's currently executing.
• There is a method, suspend(), in the Thread class, that lets one thread tell another to suspend, but the suspend() method has been deprecated.
• There is also a stop() method, but it too has been deprecated and we won't even go there.
• Both suspend() and stop() turned out to be very dangerous, so you shouldn't use them and again, because they're deprecated.
• Note also that a thread in a blocked state is still considered to be alive.

Thread state : Dead

• A thread is considered dead when its run() method completes.
• It may still be a viable Thread object, but it is no longer a separate thread of execution.
• Once a thread is dead, it can never be brought back to life!
• If you invoke start() on a dead Thread instance, you'll get a runtime (not compiler) exception. And it probably doesn't take a rocket scientist to tell you that if a thread is dead, it is no longer considered to be alive.