Reactive Programming in Java: How, Why, and Is It Worth Doing? History of Multithreading
Reactive Programming in Java: How, Why, and Is It Worth Doing? History of Multithreading
We continue our series on Reactive Programming in Java. This time we look at the history of multithreading.
14 черв 2021
769
Інші статті
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Last Modified technique?
How to implement Slowly Changing Dimensions(SCD) Type 2 in Spark?
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Append technique?
Why MongoDB don't fetch all the matching documents for the query fired
How to solve the issue of full disk utilization in HDFS Namenode
Can We Use HDFS as Back-up Storage?
How to do Indexing in MongoDB with Elastic Search? Part 1
How to do Indexing in MongoDB with Elastic Search? Part 2
How to store data on browser using NoSQL IndexedDB?
How to Apply MBTI in HR: Motivation for every day. Groups of People & their Motivations
History of Multithreading
How does multithreading work in Java? The good old multithreading in Java uses basic multithreading primitives:
- Threads
- Synchronization
- Wait/notify
Difficult to write, difficult to debug, difficult to test.
Java 5
- Future interface:
- V get()
- boolean cancel()
- boolean isCancelled()
- boolean isDone()
- Executors
- Callable interface
- BlockingQueue
Then a method ‘get’ appeared in the Future interface. It blocks a call until the completion of the calculation. For example, we have Future which returns data from the DB, and we address the get method:
Future getDBData();
getDBData().get();
Here blocking occurs. In fact, there is no advantage of using Future here. When can we get an advantage? For example, we set a task, execute it, address the get method, and use blocking at this point:
doOutJob();
f.get();
Returning to the metaphor of manager and employees, we set a task, did some job, and then waited for the task to be completed. And what if we need to pass the result of this job to another person? We have already reviewed such a case: do the job, pass the results, and then get back. In the case of parallelism, there is no such possibility.
The Future capabilities are very limited. For instance, we can find out if this task was executed:
Future f = getDBData();
doOutJob();
if (!f.isDone) doOtherJob();
f.get();
If the task is not completed yet, we can do something else. Anyway, we’ll miss this point: either the task is not completed, or it is, but we are busy with other things. Points of synchronization are not very clear here.
The Future interface had minimal capabilities in Java 5 and was not easy to use.
Which are the business tasks to be performed by a typical application?
The original article can be found here.
Interested in learning how to program with Java or in upgrading your Java programming skills? Check out our trainings.