We have a desktop application that has some background threads and, because of execution of external commands, also needs threads for handling the out and err streams.
We could either create new threads and let them finish or we could reuse threads. Would reusing threads have some benefit, e.g. in case of performance or memory usage?
There is no way to reuse a Thread because Thread once finishes (exit the run() method) its Thread.State passes from Thread.State.RUNNABLE to Thread.State.TERMINATED and the Thread class does not have a setState(Thread.State) method for setting its state to reuse it.
However we can take help of Thread Pooling in Java. In case of thread pool, a group of fixed size threads are created. A thread from the thread pool is pulled out and assigned a job by the service provider. After completion of the job, thread is contained in the thread pool again.
Advantage of Thread Pooling :
Thread pooling saves the virtual machine the work of creating brand new threads for every short-lived task.
It minimizes overhead associated with getting a thread started and cleaning it up after it dies
By creating a pool of threads, a single thread from the pool can be recycled over and over for different tasks.
Reduce response time because a thread is already constructed and started and is simply waiting for its next task
JDK 1.5 and above, you should try not to create Thread as much as possible.
Refer : http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html. Try to use Thread pool executor.
Reusing a thread has the following advantage:
no new object needs to be created (thread object)
lower latency because the task can be picked up by an existing idle thread
no old object needs to be garbage collected
using a pool also introduces a limit to concurrently running threads (averages out load spikes)
Related
Our current course assignment specifies that we are supposed to create a manager for a thread pool using the "Object Pool Manager" design pattern which spawns a set amount of threads. The ownership of these threads shall be transferred to the client and then back to the pool after the client has finished using it. If no thread exists in the pool then the client has to wait.
My confusion comes from the fact that a thread is supposedly not reusable, which defeats the purpose of pooling them. Have I understood the assignment incorrectly?
Threads are reusable as long as they have not ended. A pool of threads generally involves threads that do work as it is given to them, and then wait for more work. Thus, they never end until explicitly told to do so. The trick is designing them in a way such that the work they are given ends, but the thread itself does not. Thread pools are useful because it is often relatively expensive to create/destroy threads.
#Kaliatech has already explained the concept behind re-use of threads. Also "The ownership of these threads shall be transferred to the client" is slightly misleading as the ownership of threads generally remain with the thread-pool/object-pool as it is the manager of this pool and the client should simply submits the task to the pool which can either complete successfully or fail. The thread continues to run ready to pick the next task submitted to the pool. As a design too the separation of task object ( Runnable/Callable) and the object representing thread execution (Thread) are designed to be different. Should the need arise the thread-pool is responsible for ramping up/down the number of threads as they are expensive to create and manage. Java ThreadPoolExecutor will be a good example to refer to how typically such a thread pool works.
I was asked this question in an interview , where I could only answered jndi and am not sure if there's anything else like object pooling , thread pooling . Can any one help?
In computer science, a pool is a set of resources that are kept ready to use, rather than acquired on use and released afterwards. In this context, resources can refer to system resources such as file handles, which are external to a process, or internal resources such as objects (read more).
In Java there are
JDBC/JNDI Connection Pooling (for more details see)
Thread Pooling (for more details see here)
Object Pool Design Pattern (for more details see here)
Memory Pool (might or might not apply to Java)
Expanding on Thread Pooling you can have
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()
In terms of Memory Pool I am not entirely sure whether Garbage collection and/or other features of Java that does the job of memory allocation (similar to malloc, calloc, etc) make use of Memory pool or not.
Is there a way to increase the performance of Thread.start method. as i know Thread.start will call the run method of the tread in a separate thread but i have found that it need time more than simple method call in the calling context.
Starting threads definitely involves overhead. You may want to consider thread pooling.
http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html
Thread.start is native. It does a lot more than calling run - it uses Operating System calls to create a thread stack and lots of other things. Consider using a Thread Pool.
Starting threads, context switching and destroying threads all require precious CPU cycles. So it is best to use Thread Pooling which suits your requirement.
There are various options available:
Cached Thread Pool - caches some threads to improve performance
Single Thread pool executor - A single thread executor
Fixed Thread Pool executor - An executor with fixed size
Switching can be reduced by creating n threads based on your hardware configuration and other parameters.
Advantage of executors over Thread.start():
Re use of existing threads, so threads are not created every time a task is submitted
Thread management is done by executors
Thread creation always takes time. The traditional approach
new Thread(runnableObj).start();
creates new Thread everytime we call start() method.
Use Executors, if you don't want to spend extra time in creating threads while your business logic is being run. You can configure and create Thread Pools when your application starts.
Here is a good short tutorial for Executors
I have an tomcat webapp where I use a java executor to execute some runnables.
First I allocate the executor service from my executor instance like this:
executorService = Executors.newFixedThreadPool(nThreads, new MyThreadFactory(threadFactoryName))
Then, I launch task using the executor service:
executorService.execute(new MyRunnable);
Then, it seems to work. But my problem is, I am chasing some sort of leak where I get this error after a while of running the server:
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:640)
at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:703)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652)
at something.server.ThreadExecutor.execute(MyRunnable.java:91)
I used the java VisualVM on tomcat instance to trace the thread allocation. I see that when I call 'newFixedThreadPool' I see 'nThreads' new threads. But after their job is done, I see the state of the threads to be on 'wait'.
Is that normal? I don't believe it is, I know the runnables finish their job but the executor service never frees the threads. What can I do to free them, or am I completely out of scope?
I think you are instantiating a new ExecutorService for every request, or something like that.
You should either instantiate only one ExecutorService, and reuse it, or call shutdown() on the service after you have finished submitting tasks. The shutdown function will wait for the tasks to finish, and then free the threads.
You are instantiating a fixed thread pool. The ExecutorService is not going to release the threads until you terminate the ExecutorService itself by calling ExecutorService.shutdown() or ExecutorService.shutdownNow().
Is that normal? I don't believe it is, I know the runnables finish their job but the executor service never frees the threads.
Yes it is normal. Indeed, this behaviour is desirable because creating a new thread is an expensive operation. The pool threads (or at least the 'core' pool threads) will continue to exist until the executor gets shut down.
What can I do to free them, or am I completely out of scope?
You should be able to configure your thread pool to have a smaller 'core' thread pool, and/or a smaller keepAlive time. Refer to the javadoc for details.
[M]y problem is, I am chasing some sort of leak where I get this error after a while of running the server:
That OOME is not necessarily an indication of a leak. It could be a sign that you haven't left enough non-heap memory for the number of threads that you are trying to create. (Or to put it another way, that your thread pool is too big.)
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.