I would like to implement a piece of software that will make sure 10 threads running the same class all the time
All threads will terminate let's say after a certain number of seconds at random, but then, I want to make sure once they're terminated, they're replaced instantly by newly created threads.
Would you know if there's any library available?
Many thanks,
Vlad
Rather you use Thread Pool. Java Executor framework provides it.
ExecutorService executor = Executors.newFixedThreadPool(10);
ExecutorService executorPool = Executors.newFixedThreadPool(noOfThreads);
public static ExecutorService newFixedThreadPool(int nThreads)
Creates a thread pool that reuses a fixed set of threads operating off a
shared unbounded queue. If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks.
Parameters:
nThreads - the number of threads in the pool
Returns:
the newly created thread pool
Related
Please note that I usually ask a question after googling for more than 20 times about the issue. But I can't still understand it. So I need your help.
Basically, I don't understand the exact usage of newFixedThreadPool
Does newFixedThreadPool(10) mean having ten different threads? Or does it mean it can have 10 of the same threads? or the both?
I executed with submit() methods more than 20 times and it's working.
Does submit() print a value? Or are you putting threads in the ExecutorService?
Briefly, tasks are small units of code that could be executed in parallel (code sections). The threads (in a thread pool) are what execute them. You can think of the threads like workers and the tasks like jobs. Jobs can be done in parallel, and workers can work in parallel. Workers work on jobs.
So, to answer your questions:
newFixedThreadPool(int nThreads) creates a thread pool of nThread threads that operate on the same input queue. nThreads is the maximum number of threads that can be running at any given time. Each thread can run a different task. With your example, you can be running up to 10 tasks at the same time. (The documentation can be found here with credit to #hovercraft-full-of-eels)
submit() pushes the given task into an event queue that is shared by the threads in the thread pool. Once a thread is available, it will take a task from the front of the queue and execute it. It shouldn't print anything, unless the Runnable you pass it has a print statement in it. However, the print statement may not be printed right when you submit the task! It will print once a thread is executing that particular task. (The documentation can be found here)
Just refer java docs or JAVA API's description rather than googling it.
For your questions I have below comments .
Question 1 ->
ExecutorService executorService = Executors.newFixedThreadPool(10);
First an ExecutorService is created using the Executors newFixedThreadPool() factory method. This creates a thread pool with 10 threads executing tasks.
Executors.newFixedThreadPool API creates, a thread pool that reuses a fixed number of threads and these threads work on a s***hared unbounded queue***.
At any point, at most nThreads threads will be active processing tasks.
If additional tasks are submitted when all threads are active, they will wait in the queue until a thread is available.
If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks. The threads in the pool will exist until it is explicitly SHUTDOWN.
After submitting even 20 tasks ,it worked with this thread pool.
Internally it calls below line of codes .
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue());
}
Question 2- > Submits a Runnable task for execution in Queue and it can also return an Object of type Future Object representing task. we can use Future's get method to check whether submitted task has successfully completed or not because it will return null upon successful completion.
How many threads are initially created in the thread pool when using Executors.newCachedThreadPool() the Javadoc doesn't specify any number is there a guaranteed number that we will always get like 10 initially or something.Docs below:
newCachedThreadPool public static ExecutorService
newCachedThreadPool() Creates a thread pool that creates new threads
as needed, but will reuse previously constructed threads when they are
available. These pools will typically improve the performance of
programs that execute many short-lived asynchronous tasks. Calls to
execute will reuse previously constructed threads if available. If no
existing thread is available, a new thread will be created and added
to the pool. Threads that have not been used for sixty seconds are
terminated and removed from the cache. Thus, a pool that remains idle
for long enough will not consume any resources. Note that pools with
similar properties but different details (for example, timeout
parameters) may be created using ThreadPoolExecutor constructors.
Returns: the newly created thread pool
The answer is 0.
You can find in source code that right after ThreadPoolExecutor creation there is no workers spawned.
I'm new to this concurrent programming in java and came up with following scenarios where I'm getting confusion which to use when.
Scenario 1: In the following code I was trying to run threads by calling .start() on GPSService class which is a Runnable implementation.
int clientNumber = 0;
ServerSocket listener = new ServerSocket(port);
while (true) {
new GPSService(listener.accept(), clientNumber++, serverUrl).start();
}
Scenario 2: In the following code I was trying to run threads by using ExecutorService class as shown
int clientNumber = 0;
ServerSocket listener = new ServerSocket(port);
while(true) {
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.execute(new GPSService(listener.accept(), client++, serverUrl));
executor.shutdown();
while (!executor.awaitTermination(1, TimeUnit.SECONDS)) {
// Threads are still running
System.out.println("Thread is still running");
}
// All threads are completed
System.out.println("\nThread completed it's execution and terminated successfully\n");
}
My Questions are
Which is the best practice to invoke a thread in concurrent programming?
What will be result(troubles) I'll end up with when I use first or second?
Note: I've been facing an issue with the first scenario where the program is getting hanged after every few days. So, is that issue related/expected when I use first method.?
Any good/helpful answer will be appreciated :) Thank you
There are no big differences in the two scenario you posted, except from managing thread termination in Scenario2; you always create a new thread for each incoming request. If you want to use ThreadPool my advice is not to create one for every request but to create one for each server and reuse threads. Something like:
public class YourClass {
//in init method or constructor
ExecutorService executor = Executors....;// choose from newCachedThreadPool() or newFixedThreadPool(int nThreads) or some custom option
int clientNumber = 0;
ServerSocket listener = new ServerSocket(port);
while(true) {
executor.execute(new GPSService(listener.accept(), client++, serverUrl));
}
This will allow you to use a thread pool and to control how many threads to use for your server. If you want to use a Executor this is the preferred way to go.
With a server pool you need to decide how many threads there are in the pool; you have different choices but you can start or with a fixed number or threads or with a pool that tries to use a non busy thread and if all threads are busy it creates a new one (newCachedThreadPool()). The number of threads to allocate depends form many factors: the number of concurrents requests and it durations. The more your server side code takes time the more you need for additional thread. If your server side code is very faster there are very high chances that the pool can recycle threads already allocated (since the requests do not come all in the same exact instant).
Say for example that you have 10 request during a second and each request lasts 0.2 seconds; if the request arrive at 0, 0.1, 0.2, 0.3, 0.4, 0.5, .. part of the second (for example 23/06/2015 7:16:00:00, 23/06/2015 7:16:00:01, 23/06/2015 7:16:00:02) you need only three threads since the request coming at 0.3 can be performed by the thread that server the first request (the one at 0), and so on (the request at time 0.4 can reuse thread used for the request that came at 0.1). Ten requests managed by three threads.
I recommend you (if you did not it already) to read Java Concurrency in practice (Task Execution is chapter 6); which is an excellent book on how to build concurrent application in Java.
From oracle documentation from Executors
public static ExecutorService newCachedThreadPool()
Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available. These pools will typically improve the performance of programs that execute many short-lived asynchronous tasks.
Calls to execute will reuse previously constructed threads if available. If no existing thread is available, a new thread will be created and added to the pool. Threads that have not been used for sixty seconds are terminated and removed from the cache.
Thus, a pool that remains idle for long enough will not consume any resources. Note that pools with similar properties but different details (for example, timeout parameters) may be created using ThreadPoolExecutor constructors.
public static ExecutorService newFixedThreadPool(int nThreads)
Creates a thread pool that reuses a fixed number of threads operating off a shared unbounded queue. At any point, at most nThreads threads will be active processing tasks. If additional tasks are submitted when all threads are active, they will wait in the queue until a thread is available.
If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks. The threads in the pool will exist until it is explicitly shutdown.
#Giovanni is saying that you don' have to provide number of threads to newCachedThreadPool unlike newFixedThreadPool(), where you have to pass maximum cap on number of threads in ThreadPool.
But between these two, newFixedThreadPool() is preferred. newCachedThread Pool may cause leak and you may reach maximum number of available threads due to unbounded nature. Some people consider it as an evil.
Have a look at related SE question:
Why is an ExecutorService created via newCachedThreadPool evil?
How to i implement such a function ?
I have a dynamic queue which gets filled at unknown times with runnables, which have to be executed. The ExecutorService should only start a limited amount of threads, when the maximum thread size is reached, it should stop executing more threads, until one thread finishes, then the next task should be executed.
So far i came across this:
ExecutorService executor = new ThreadPoolExecutor(20, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
databaseConnectionQueue);
The ExecutorService is created before the queue is filled, and should stay alive until the queue is deleted, not when its empty, because this can happen. Can anybody help me ?
ThreadPoolExecutor will will not shutdown when it is empty. From the JavaDoc:
A pool that is no longer referenced in a program AND has no remaining
threads will be shutdown automatically.
I believe you should use FixedThreadPool (Executors.newFixedThreadPool)
As per javadoc [Executors.newFixedThreadPool]
Creates a thread pool that reuses a fixed number of threads operating
off a shared unbounded queue. At any point, at most nThreads threads
will be active processing tasks. If additional tasks are submitted
when all threads are active, they will wait in the queue until a
thread is available. If any thread terminates due to a failure during
execution prior to shutdown, a new one will take its place if needed
to execute subsequent tasks. The threads in the pool will exist until
it is explicitly shutdown.
Hope it helps. Thanks.
I have a fixed thread pool that runs 7 concurrent threads at any time (with a queue), and I want to turn it into a scheduled thread pool that runs only 7 concurrent jobs but can queue/schedule more.
Reading the documentation didn't really help me..
newFixedThreadPool
public static ExecutorService newFixedThreadPool(int nThreads)
Creates a thread pool that reuses a fixed set of threads operating off
a shared unbounded queue. If any thread terminates due to a failure
during execution prior to shutdown, a new one will take its place if
needed to execute subsequent tasks.
Parameters:
nThreads - the number of threads in the pool Returns:
the newly created thread pool
newScheduledThreadPool
public static ScheduledExecutorService newScheduledThreadPool(int
corePoolSize)
Creates a thread pool that can schedule commands to run after a given
delay, or to execute periodically.
Parameters:
corePoolSize - the number of threads to keep in the pool, even if they are idle. Returns:
a newly created scheduled thread pool
What I don't understand is, are corePoolSize and nThreads the same thing? Is a scheduled thread pool really a subset of a fixed thread pool, meaning that I can use scheduled thread pool as a fixed thread pool that can queue delayed tasks?
Yes, they are basically the same thing, just with added scheduling functionality. The ScheduledThreadPoolExecutor even extends the default implementation of the ExecutorService (ThreadPoolExecutor).
nThreads and corePoolSize is the number of threads to be spawned. For a fixed executor, it's always the same. With the other implementation, it varies between min (corePoolSize) and max (maxPoolSize).
Yes, it works that way in JDK5-6. While in principle the ScheduledExecutorService interface is silent on the issue of pool size, the actual implementation of it used in JDK, uses a fixed pool:
Class ScheduledThreadPoolExecutor
While this class inherits from
ThreadPoolExecutor, a few of the
inherited tuning methods are not
useful for it. In particular, because
it acts as a fixed-sized pool using
corePoolSize threads and an unbounded
queue, adjustments to maximumPoolSize
have no useful effect.
Obviously that may not hold true if you use a different implementation of ScheduledExecutorService provided by an application framework or a different vendor.
Yes they are exactly the same with regard to thread pool size: they ultimately both call the same ThreadPoolExecutor constructor.