I am using Executors.newFixedThreadPool(100) method.
Single command execution needs approx 20 threads. After executing the command 5-6 times, application stops responding.
My thread is implementing Callable.
I doubt, that thread doesn't terminate after completion.
I have also called shutdown() to terminate the thread.
Can anybody please tell, when I use get() method to retrieve the thread's result, does it gets terminated(means, its removed from the queue) or it is still there in the queue, which is used by pool to store the threads.
The threads don't terminate. What happens is this:
All worker threads wait for the input queue
One thread pops the head element from the queue
It runs the Callable
It pushes the result into the result queue
It waits for a new element in the input queue
So either the result queue overflows or your Callable doesn't return.
get() is a blocking call - that means the calling thread halts until the running thread has completed its task and the result is available.
The Executor takes care of taking tasks from the queue and cleaning up, so the answer is "no" - it isn't "still on the queue"
Caution using 100 threads - that's a ridiculously high number. Try between 2 and 8 for a typical machine (all depends on how much time is spent waiting for other things eg I/O - the more CPU bound your tasks are, the less threads you should use.
Even after calling get(), the thread would still be in the queue. Infact the API ensures that even if a thread dies, it recreates one to maintain "fixedness"(fixed no of threads in your pool)
Note that if the threads in your pool are actually doing some task(apart from waiting), calling shutdown will not terminate the thread. So, for e.g. if your threads are in a infinite loop doing something, then calling shutdown is useless.
Calling shutdown() only stops the thread pool from accepting new tasks and allows all thread to finish once all tasks have been performed.
How many cores do you have? If you have 100 busy threads, and say 4 cores every thread is only going to get a small amount of CPU time.
Related
I am implementing the following functionality in a load test tool to simulate heavy load on a target application:
Multiple threads are launched in concurrency to perform the same kind of operations.
Each thread will loop for n times. At the end of each loop, test results are available and are added to a list which is returned after all loops finish running.
I'm currently using Callable and Future, and putting lists of results returned by all the threads into another list after all threads finish running and give me the Future. The problem is that I can lose what is available if the execution of the program is interrupted. I want to be able to save results that are available in finishes loops while the threads are still processing remaining loops.
Is there something in Java concurrency library suitable for this purpose? Or is there a better design to the load test functionality I am building?
Thanks in advance!
You can pass your results to a BlockingQueue as they occur. This can be picked up by another thread or the one which triggered the tasks in the first place.
The java.util.concurrent.CyclicBarrier class is a synchronization mechanism that can synchronize threads progressing through some algorithm. In other words, it is a barrier that all threads must wait at, until all threads reach it, before any of the threads can continue.
Creating a CyclicBarrier
When you create a CyclicBarrier you specify how many threads are to wait at it, before releasing them. Here is how you create a CyclicBarrier:
CyclicBarrier barrier = new CyclicBarrier(2);
Waiting at a CyclicBarrier
Here is how a thread waits at a CyclicBarrier:
barrier.await();
You can also specify a timeout for the waiting thread. When the timeout has passed the thread is also released, even if not all N threads are waiting at the CyclicBarrier. Here is how you specify a timeout:
barrier.await(10, TimeUnit.SECONDS);
The waiting threads waits at the CyclicBarrier until either:
The last thread arrives (calls await() )
The thread is interrupted by another thread (another thread calls its interrupt() method)
Another waiting thread is interrupted
Another waiting thread times out while waiting at the CyclicBarrier
The CyclicBarrier.reset() method is called by some external thread.
I have been working on a project in which my program creates around 500 threads during the execution. I find that my PC starts taking a huge load as soon as the program I execute the program. And it continues showing load after 75% of the threads have completed their job.
I want to know whether the threads whose work has finished were killed or not. And how does java deal with threads which have finished their job. Any help...
I find that my PC starts taking a huge load as soon as the program I execute the program. And it continues showing load after 75% of the threads have completed their job.
If 75% of the 500 threads have completed their job then that leaves 100+ threads that continue to run. 100 threads, if using a good amount of CPU, can more than swamp the processors on a box which I assume does not have 100s of cores. So your application may continue to show 100% CPU utilization until the number of running threads drops below the number of cores.
You should consider using a fixed sized thread pool instead of creating 500 concurrent threads. You then submit 500 tasks to the thread pool. This allows you to choose an appropriate number of threads to be running concurrently. The appropriate number of threads is highly dependent on the tasks being submitted. More CPU bound tasks should use fewer threads while IO bound tasks can use more. Doing some test runs with your application while adjusting the number of threads is the best way to optimize the value. I tend to start with 2 times the number of cores and then optimize from there.
// create a thread pool with 10 workers
ExecutorService threadPool = Executors.newFixedThreadPool(10);
// define your jobs somehow
for (MyRunnable job : jobsToDo) {
threadPool.submit(job);
}
// once we have submitted all jobs to the thread pool, it should be shutdown
threadPool.shutdown();
For more details, check out the ExecutorService tutorial.
I want to know whether the threads whose work has finished were killed or not. And how does java deal with threads which have finished their job. Any help...
The threads have most likely finished. After a thread leaves the run() method (either because it returns or throws an exception) it will no longer consume CPU and its underlying native thread can be reaped or reused. If there are no references to the Thread object, its memory will eventually be reaped by the garbage collector.
The JVM will garbage collect the Thread object, as long as there are no references to it, and as long as its run method returns. Thread is dead itself after its run method returns. It might still be in the heap, but it will not have its own stack anymore, and not do anything.
The only possible way that your threads have not been killed is that they still do something or you forgot to clean up references to your thread objects - but this is memory related.
If you allocated your threads through the thread pool, they are returned to the pool after the execution of the task. I this case, they might not be released after the completion of the task.
we should not create many threads to accomplish our task, it will give you many issues like OutofMemoryError. And also creation of thread is a costly task, so we should think of Thread pool i.e. ExecutorService in which we reuse the same threads again and again.
But any ways to answer you question after threads are created they die automatically i.e. it will be garbage collected, you don't need to do anything. Initially java provided methods like stop() or destroy() but these are deprecated for good reason.
You can read about a Thread's lifecycle. If the run method is over then they should not be consuming your cpu.
Threads who have finished their jobs will die. It won't consume any more CPU time.
You can use jstack to check how many threads are active running in your java process.
The docs for ScheduledThreadPoolExecutor says that -
Tasks scheduled for exactly the same execution time are enabled in first-in-first-out (FIFO) order of submission.
Does this mean that the tasks which SHOULD be done at the same time are never done at the same time. Instead they are executed in FIFO order ?
If that is true then which class do I use which is better than Timer and also does not have this FIFO problem ?
The way a ScheduledThreadPoolExecutor works is there is a single "scheduling" or master thread which checks for tasks to execute.
If it finds a task, it delegates it to a "worker" thread from the pool.
If multiple tasks are ready to be executed, they are "kicked off" one at a time, though once "kicked off", subsequent processing is concurrent, per Java's definition.
If you have two tasks that are both scheduled through the executor for the same time, the order in which they complete could vary from run to run and unless you put in specific controls such as locks, waits, etc... to handle this, it's up to java's thread scheduling (how java allots time to threads on a core) to determine how and when what gets processed. Please note that setting up such locks, waits, etc... is a deceptively complex task prone to race conditions leading to unexpected deadlocks, live locks, etc...
It depends on the size of your thread pool. If you schedule 1000 tasks to fire at midnight, and you only have 25 threads, then only 25 can be executed initially, while the rest must wait for available threads. FIFO here refers to the order in which the executor will hand tasks off to the execution threads.
Please note that the docs talk about "enabling" the tasks and that we are talking about a threadpool executor. :-)
That means the tasks will wait until the designated time, then they are treated as if put into a normal ThreadPoolExecutor. If there are enough threads available in the pool all these tasks will be run in parallel.
Only if you have more tasks becoming active than available threads in the pool some tasks will have to wait.
Monitoring our app using JConsole over a period of time shows that the “live thread” count is increasing constantly. Increasing thread count sounds like a bad thing to me, or am I wrong?
Synopsis:
In our app we create thread pools for various collectors using Executors.newFixedThreadPool, Executors.newSingleThreadScheduledExecutor. These collectors are called every few minutes.
And there is this other service which is called n times by the above collectors during every collection. This service generates a single thread (Executors.newFixedThreadPool(1);) that executes a FutureTask. For all the above ExecutorServices we call shutdownNow() only if an exception is caught and leave the rest for GC.
1) Do I need to shutdown the executors once the process is finished or can I rely on GC?
Thanks for your suggestions and insights
Ajju
One should call shutdown explicitly on executor service - executor.shutdown() for orderly shutdown & reclamation of resources (old tasks are executed while new ones are not accepted).
shutdownNow() attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution (there is no guarantee about the executing tasks - they may or may not execute - this is a best attempt).
The point of a thread pool is to avoid the overhead of spawning new threads during processing. You are NOT supposed to spawn new thread pools ! (Which is what you're doing here Executors.newFixedThreadPool(1);)
You should set up your thread pools when your application starts, and inject them into your processing objects.
I have a sort of complex problem like below.
- we have a real time system with large number threads requirement. In order to optimize the performance, we are thinking of following design.
create a thread pool executor with max number of threads
each thread is used to create scheduled executor service.
now the tasks are being assigned to these executor services evenly based on load
BUT the biggest problem is, if one of the task in the queue contains a sleep (for few secs), it blocks the corresponding Schedule executor service thread for that duration and subsequently all the following tasks in that queue.
In this regard, please suggest me how to suspend the execution of the task with sleep OR overriding the sleep somehow and rejoin/schedule the task again to the queue.
Thanks in advance
Seshu
Assuming I understand your question, your Schedule Executor service threads have a deadline requirement, but the actual workers can sleep for an unknown length of time, possibly throwing off the timing of the Schedule Executors. From your description I'm guessing what you want is for a task that needs to sleep to actually stop, save progress information and then requeue itself for the remainder of the work to be rescheduled at some future time. You'd have to build this into your application architecture.
Alternatively, you could have the scheduler threads launch the worker tasks in their own separate threads, letting them sleep as necessary, with one scheduler thread collecting all the worker terminations.
To get a better answer you're going to have to provide more information about what you're trying to accomplish.
Tasks which sleep are inherently unfriendly for running in any kind of bounded thread pool. The sleep is explicitly telling the thread that it must do nothing for a period of time.
If possible, split the task into 2 (or more parts), eliminating the sleep completely. Get the first half-task to schedule the second task with an appropriate delay.
Failing that, you could consider increasing the size of your thread pool somewhat - either setting a much larger cap to its size, or possibly even eliminating the cap altogether (not recommended for a server than might end up with many clients).
Alternatively, move the tasks with sleep statements in them into their own Scheduled executor. Then, they'll delay each other, but better-behaved tasks, with no wait statements in them, will get preferential treatment.