Java: Multi-threading and Concurrency Simplified

Multi-threaded applications normally do parallel processing of tasks where as single threaded applications do one task at a time i.e. If there are two tasks such as T1, T2 they are executed in serial order i.e T1 after T2 or T2 after T1, where as multi threading enables us to execute them simultaneously i.e. T1 along with T2. We can choose single threaded applications when parallel processing is not required example use cases such as simple text editor. 

True parallelism is achieved by assigning tasks to individual CPUs. Where as if there is one CPU and you want to perform multiple tasks in parallel, then CPU will be shared across those tasks for some stipulated time interval, which stands for interleaved execution, and this way of executing the tasks is known as logical parallelism or psuedo parallelism.

You can create a thread by instantiating Thread class and submit it for execution using the start method. In order to perform a task using thread, you can subclass the Thread class and inside the run method you can perform the corresponding task. One other approach is to implement Runnable interface and submit it for Thread class instance to run it. Later approach is better because sub-classing the thread class means you are extending the Thread functionality which is not the case. Also in case of runnable tasks we can utilise an existing Thread object, so that the same Thread is used for executing multiple tasks.

File copy is an IO intensive activity. Take for example you need to copy 100 files, if you do it in serial manner you are not effectively using the CPU and IO resources. Instead you can make it parallel through Java threads and get optimal performance.

Thread creation is a costly activity as it includes creating a separate execution context, stack etc.. Hence we should refrain from creating too many threads for an application. And also creating a thread for each task is not a good idea, instead we can create a pool of threads and effectively utilise them in executing all the task. This could be achieved using ExecutorService in Java. Use the execute method of the ExecutorService to submit a Runnable task, if a thread is available in the pool then it assigns this task to the thread otherwise the task is added to the blocking queue and is kept till a thread is available. 

stop() method of the Thread class could be used to stop the thread in the middle. But this is the dangerous thing to do as it leaves the system in inconsistent state, because we are not giving the opportunity to the thread to rollback or reverse the actions that it has taken. And hence the stop method is deprecated.

Correct approach would be to interrupt() the thread and then it is up to the thread to consider it. A thread can check if it was interrupted or not using interrupted() method. If interrupted() we can design the thread in a way that it reverses the actions it has performed and then stop.

sleep() method of the thread class is used to block the thread for the given time interval in milliseconds.

Unlike Runnable, Callable interface allows us to create an asynchronous task which is capable of returning an Object. Create a Callable task and submit it for ExecutorService which returns the Future object.  We can use this Future object to get the result once the task is completed.

When an object is modified through multiple threads we need to synchronize the operation to make it threadsafe or re-entrant. If it not taken care then it might lead to inconsistent results. 

To make a method re-entrant we might declare it as synchronized. When a method is synchronized the corresponding object is locked before a thread can enter into the method. This can solve concurrency problems to some extent but it is not a good solution.

Instead of making a method synchronized, we can use the synchronized block which allows us to retain the lock only for a specific portion of code instead of the entire method. This is at times a better solution as synchronized method doesn't solve a class of problem where multiple method calls need to be atomic instead of one single method.

ReentrantReadWriteLock allows us to obtain two different kinds of locks,

1. readLock() - If there are other readLock request they will also acquire the lock till the writeLock request is obtained. Once writeLock request is obtained all subsequent requests should  wait till writeLock is unlocked.
2. writeLock() - Mutually exclusive.

read write locks are preferred over synchronized methods due to shared read and their ability to go beyond a method with lock acquired.