Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I am learning multithreading and am now confused about one topic i.e ExecutorService and CompletableFuture.
Let me summarise that what I learnt till now.
ExecutorService is a Java High-level thread API, which helps in managing threads, i.e two independent threads which is doing their task. But still, if threads are dependent then we can use producer-consumer patterns and many more.
This helps in achieving concurrency. Since multiple threads can be used for running a multiple tasks.
But In CompletableFuture, which we called async programming/ Reactive programming, is also used for accomplishing the same task. i.e It can also run multiple threads.
But I don't get the point of when to use which one and how they are different from each other? What are there use cases in which they sit perfectly?
A CompletableFuture is, in essence, a mechanism by which one thread can find out when another thread has finished doing something.
So, a typical model is this kind of method:
CompletableFuture<Result> doSomething() {
CompletableFuture<Result> future = new CompletableFuture<>();
... arrange to do work in some other thread ...
return future;
}
The caller of doSomething() gets back an object which it can use to determine completion, wait for completion, get the Result of doing 'something', and perhaps run some other work using the Result.
So, how does doSomething() arrange to do work in some other thread. Well, one way is to execute the work vis some ExecutorService. Though there are plenty of other ways to go about it. Regardless, when the work is complete, it will call future.complete(someResult) to set the CompletableFuture into 'completed' state with the expected Result.
Maybe you're confused because our caller could write
doSomething().thenAcceptAsync((result) -> blahBlah(result));
In this case, doSomething() proceeds as above. When that is complete, we want to run another operation, also asynchronously. Because we used theAcceptAsync, this work will be handled via an ExecutorService known to the CompletableFuture framework (the common ForkJoinPool, to be exact - this is documented).
Summary - this is not 'choose one or the other'. ExecutorServices provide the means to run units of work in other threads. CompletableFutures provide the means to know and react to completion of those units of work.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Can you explain short guide about background thread in 2021? I mean what is last recommendation to use, what was deprecated.
When I tried to found the information about it, I have confused. One place told about Thread, another Executor, the next about AsyncTask and so on. Every contains note or comment about obsolescence and not recommended by Google. What is true?
It really depends on what you are trying to do. Generally, the guide to background processing which was already linked by Dmitry in your comments is a good place to start.
Regarding the things you mentioned:
A Thread is useful if you have long-running tasks which do not happen all the time. Then you can create a thread whenever needed and it will be destroyed as soon as it's done executing.
By Executor I guess you are referring to the use of an ExecutorService. This is a class to manage a pool of threads. That is, you can give a job to the ExecutorService and it will assign it to any of its threads for execution. This is more efficient than creating a thread yourself every time, because the threads are not immediately destroyed after their work is complete. However, they will also stay in the memory because of that. Thus, an ExecutorService is suitable if you have short background jobs which occur often.
As for the AsyncTask, this API is indeed deprecated by now.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
is the following statement correct:
" There shouldn't be any thread interference between two synchronized methods in 2 different classes . So they can run concurrently without any problems."
Thanks for your time
That is way too vague. A few pointers:
"how does synchronization work in Java": There are a couple of mechanisms, the question seems to be about the synchronized keyword. This works by marking "critical sections" that must not be executed by more than one thread at the same time, and having the threads "lock" a monitor object while they are in that section (so that all other threads wait).
synchronized methods synchronize on the object instance (or class object in case of a static method). So methods in different classes do not synchronize with each-other that way. They will run concurrently.
you can use the synchronized keyword to synchronize blocks on any other monitor object. This way, methods in different classes can still be synchronized with each-other.
"can run concurrently without problems" is not guaranteed just by having some synchronization (or lack thereof). You need to see what mutable state these methods (directly or indirectly) try to access (and who else does the same) to see what kind of concurrency control is necessary.
You misunderstood the concept a little bit. Collisions happen when two (or more) threads simultaneously try to make a change on the same data or when one of them tries the read the data while the other thread is trying to change it.
When two thread tries to change the shared resource simultaneously, a race condition occurs. Check out this link to learn more about Race Condition.
In order to prevent this kind of problems, you need to guard the shared resource for simultaneous changes. Mutexes and semaphores are invented for this purpose: To lock the shared resource for the other threads, when one thread is currently making a change on it. For this purpose, Java uses the synchronized keyword. You can read more about Synchronized in Java using the link.
Note that, using the synchronized keyword will not eliminate all of the synchronization related issues, but it is a good starting point.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I've been watching a lot of videos on data structures, and these terms are always being mentioned: synchronized/not synchronized and thread-safe/not thread-safe.
Can someone explain to me in simple words what synchronized and thread-safe mean in Java? What is sync and what is thread?
A thread is an execution path of a program. A single threaded program will only have one thread and so this problem doesn't arise. Virtually all GUI programs have multiple execution path and hence threads - one for processing the display of the GUI and handing user input, others for actually performing the operations of the program. This is so that the UI is still responsive while the program is working.
In the simplest of terms threadsafe means that it is safe to be accessed from multiple threads. When you are using multiple threads in a program and they are each attempting to access a common data structure or location in memory several bad things can happen. So, you add some extra code to prevent those bad things. For example, if two people were writing the same document at the same time, the second person to save will overwrite the work of the first person. To make it thread safe then, you have to force person 1 to wait for person 2 to complete their task before allowing person 1 to edit the document.
Synchronized means that in a multiple threaded environment, a Synchronizedobject does not let two threads access a method/block of code at the same time. This means that one thread can't be reading while another updates it.
The second thread will instead wait until the first is done. The overhead is speed, but the advantage is guaranteed consistency of data.
If your application is single threaded though, Synchronized has no benefit.
As per CIP:
A class is thread-safe if it behaves correctly when accessed from
multiple threads, regardless of the scheduling or interleaving of the
execution of those threads by the runtime environment, and with no
additional synchronization or other coordination on the part of the
calling code.
So thread safety is a desired behavior of the program in case it is accessed by multiple threads. Using the synchronized block is one way of achieving that behavior. You can also check the following:
What does 'synchronized' mean?
What does threadsafe mean?
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have a scenario where I have to call multiple objects concurrently, and each object will call multiple other class's objects internally. After the execution of all child objects, it should return result back to parent object and finally, parent objects will return result back to Main thread. It is basically two level multi threading. I do not know what I should take under consideration when implementing this scenario. I would really appreciate any and all guidance, preferably with some sample code.
I have attached a picture which gives a clear understanding of the scenario.
simplty i need to creatre a set of threads and each created threads have to create another set of threads . and also reqires controll over every thread at any time. hope its clear thanks again
ForkJoinPool and RecursiveTask are designed for such use cases. See fork-join tag
From what I understand: Every parent spawns some amount of children and has to wait for all children (and children of children and so on) to complete?
In that case, each parent can spawn one thread per child and then use a semaphore to wait for all of them to finish. Semaphores allow you to wait for multiple threads at a time.
EDIT: You mention four tasks.
ADD thread: Create a new thread, manage all threads in a list of their parent. Use synchronization to maintain that list because if there is no guarantee that only a single thread will ever touch this list.
PAUSE: Set PAUSED flag. That will cause the thread to sleep() or to wait().
RESUME: Unset PAUSED flag. If PAUSE makes thread wait(), call notify() to wake it up.
DELETE: Set STOPPED flag, then remove from list, or wait until thread finishes before removing from list (depends on what you need). If thread might be PAUSED, make sure, to RESUME it first.
The flags must be used by the thread which is running a loop to determine: Whether to PAUSE and whether to opt out of the loop, thus STOPPING the thread. Something like this:
while (!isStopped)
{
while (hasWork() && !isPaused && !isStopped)
{
// do work
}
if (!isStopped)
{
// either just sleep for a few milliseconds (easy way) or wait()
}
}
Make sure that you don't spawn too many threads. You should rather let children wait than creating even more threads, if you already spawned more than x threads, where x depends on your OS and JVM. Play around with it. Intuition might tell you: The more threads the better, but that is absolutely false. Once you surpass a certain amount of threads, they are already using all your computer's available resources (such as CPU, memory bandwidth and hard-disk bandwidth). Spawning more threads than necessary to use all the resources will just add management overhead and slow down execution.
On modern systems, competing thread scheduling might be done well, but each thread still has it's price tag. Imagine, all threads want to access CPU, memory etc. at the same time. That creates contention and requires a very smart scheduler (smart enough to predict the future and who can do that?) to not cause any noticeable overhead.
Good luck.
you can create the N parent Threads on the main object and after calling start on each thread object you can call a join on each object. The main object will block on the first one waiting for it to finish, once it has finished it will try to join the second, the third, and so on until the Nth, but they probably will already have finished and then the main will be able to finish.
Use the same approach in the relationship between parent and child. However it is not clear from your question what the child threads will have to do, you may need to provide some concurrency control among them depending on the task at hand.
Cheers.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What are the types of thread pools in java. I need to implement a robust multi-threaded application which uses heavy computation, which thread pool should I use?
There are various thread pools in java:
Single Thread Executor : A thread pool with only one thread. So all the submitted tasks will be executed sequentially. Method : Executors.newSingleThreadExecutor()
Cached Thread Pool : A thread pool that creates as many threads it needs to execute the task in parrallel. The old available threads will be reused for the new tasks. If a thread is not used during 60 seconds, it will be terminated and removed from the pool. Method : Executors.newCachedThreadPool()
Fixed Thread Pool : A thread pool with a fixed number of threads. If a thread is not available for the task, the task is put in queue waiting for an other task to ends. Method : Executors.newFixedThreadPool()
Scheduled Thread Pool : A thread pool made to schedule future task. Method : Executors.newScheduledThreadPool()
Single Thread Scheduled Pool : A thread pool with only one thread to schedule future task. Method : Executors.newSingleThreadScheduledExecutor()
There are many types ;)
There is, for instance, ExecutorService. This is the "basic" implementation which allows to submit tasks etc. You will probably want to use Executors to obtain a new one, since it has static factory methods for the most common scenarios.
Since Java 7 you also have ForkJoinPool.
Also have a look at FutureTask, since this is a very convenient class to build individual threads.
This shows good animations on the diffrent concurrency constructs, may this will help you choose
http://sourceforge.net/projects/javaconcurrenta/
Take a look at Executors.
Each common ExecutorService is explained and you will probably find one that fits your needs among them.
You can read more about ThreadPoolExecutors here:
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html
However, it might be a good idea to look at the ForkJoinTask API:
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinTask.html