How to use an ExecutorService in a way that a central Thread Pool is created for the application at the application level whose pool size will be set according to the number of threads available with the CPU at that time and then the different functionalities of the application use thread from this central pool as per their requirement.
As of Java 8, I suggest you use ForkJoinPool.commonPool(). This is the only global thread pool that base Java provides.
Before Java 8, you either keep your own thread pool(s) or use your framework's shareable thread pool(s).
Bellow is my view:
a central Thread Pool?
Maybe, it's say the Singleton Pattern in Design Pattern, I think it can solve your problem;
set according to the number of threads available with the CPU?
The size of the thread pool isn't exact. In practice, the size depends on the tasks' type be executed by the thread pool. For example, the size can be Runtime.getRuntime().availableProcessors() + 1 if the tasks are CPU intensive, or be Runtime.getRuntime().availableProcessors() * 2 if the tasks are I/O intensive.But these are only basic principles, you should determine the appropriate size by testing your application with some guidelines(such as Little's_law);
my suggests:
In practice, I seldom submit all tasks to only one central threal pool, maybe should group your tasks by type, submit them to the different thread pool, this will be convenient to monitor or tuning the thread pool later.
Hope to help you.
Related
Compared to custom thread pool, source which refers to Oracle documentation recommends using common thread pool when parallel streaming.
Since the common pool has same number of threads with the number of CPU cores what's the difference between using a common thread pool and custom thread pool which consists of same number of threads with the common pool?
It might be better to ask, what is the advantage of a custom thread pool? It's more work, so why do it?
Processors are a global resource. Custom thread pools can be created in different places without any coordination, and thus "over-allocate" the processors.
A re-usable library should not create custom thread pools; if you can justify why a custom thread pool is desirable, it should be managed at a higher level in the application. To support this, a re-usable library might permit a caller to configure (inject) a custom executor, and fall back to the common thread pool by default.
what's the difference between using a common thread pool and custom thread pool which consists of same number of threads with the common pool?
Some important considerations:
With the common thread pool, you don't need to write or maintain or configure or manage your own thread pool.
The common thread pool exists and is used, and it already provides as many threads as there are cores. No more threads than that can make progress at the same time anyway, so if you set up a custom pool and it and the common one are both fully subscribed for non-blocking operations then you incur additional overhead from the additional threads but no speedup.
Can a developer tell fork/join pool to create certain number of threads?
If yes then is it guaranteed that those many number of threads will be created by pool?
Source : https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html
A ForkJoinPool is constructed with a given target parallelism level; by default, equal to the number of available processors. The pool attempts to maintain enough active (or available) threads by dynamically adding, suspending, or resuming internal worker threads, even if some tasks are stalled waiting to join others
basically a fork join pool is ThreadPool which works on work-stealing algorithm. There are api to specify parallelism (max number of active threads - (0-2^15-1))
Specifying parallelism doesn't mean pool will create those many threads at start, but it will create threads if required when work is submitted to pool.
I have a 3 instance of a class which is implementing runnable interface. I am instantiating my Executor class like below;
executor = Executors.newScheduledThreadPool(2);<--- talking about this part
executor.scheduleAtFixedRate(unassignedRunnable, 0, refreshTime, TimeUnit.SECONDS);
executor.scheduleAtFixedRate(assignedToMeRunnable, 2, refreshTime, TimeUnit.SECONDS);
executor.scheduleAtFixedRate(createTicketsFromFile, 3, refreshTime * 2, TimeUnit.SECONDS);
My question is, Does it make any difference, if I change thread pool count from 2 to 1 or 3 ? I tried and gained nothing almost. Can anyone explain the real use of thread pool count ? Maybe my tasks are lightweight ?
You need to understand, it doesn't matter how many threads you are going to create, ultimately, threads would be executed upon number of available cores. Now, as per documentation, it is "the number of threads to keep in the pool, even if they are idle."
Can you tell me what is the real use of thread pool count
executor = Executors.newScheduledThreadPool(2);
Above line of code will create 2 threads in thread pool , but it doesn't mean all will be doing some work. But, on same time, the same thread can be used to perform some other task from thread pool, which was submitted.
So, it is better to understand your requirement before picking the total number of threads to be created. (I usually prefer the number, depending on the number of available cores count)
That is corePoolSize is number thread in pool .Available thread pick the eligible task and run in same thread.If there is no thread available though task is eligble for run will not execute as all threads are busy.In your case may be your tasks very short lived.To demo create corepool size one and submit long running task and after that submit a light task check the behavior then increase the corepoolsize to 2 and see the behavior.
It depends on number of CPU cores of a machine, on which you are running your application. If you have more number of CPU cores, multiple threads can run in parallel and performance of overall system can be improved if your application is not IO Bound application.
CPU bound application will benefit with more number of cores & threads.
If you have 4 core CPU, you can configure the value as 4. If your machine has single CPU core, there won't be any benefit to change the pool size as 4.
Related SE questions:
Java: How to scale threads according to cpu cores?
Is multithreading faster than single thread?
I have an application where I use Executors for creating a thread pool.
Now, I know we can create a thread pool with n number of threads in it while creating.
But in my case I don't want the pool size to be fixed. I want the application to create more threads in the pool if the users are more and automatically reduce the pool size if the users are less.
Please tell me if I'm vague and you need more information on understanding this.
Cheers!!
You probably want to use Executors.newCachedThreadPool(). Threads are created as needed, and if they go unused for a while, they will self-terminate.
In general the ExecutorService has default policies that would provide out-of-the-box values for various tuning parameters for newly created threads.
Based on my understanding of your question, IMO you can control the amount of time idle threads are allowed to live within a thread-pool by using the setKeepAliveTime method.
You can refer to the documentation here for more details.
Also this link provides good resources to read about thread pools and executors available in Java
I have a Executor thread pool with core size and maximum size both kept at 40 and each thread will use a HTTP connection from PoolingClientConnectionManager of Apache HTTP client with 40 connections per host route. I can see that if load is less the performance is also coming less...can you guys please help me out?
Use something like following:
ExecutorService service = Executors.newCachedThreadPool();
service.execute(someRunnable);
In this case, you needn't worry about the number of threads that are running.
The system will automatically scale the number of threads up and down for you.
Here is the documentation:
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
Hope it helps.
It all depends on how many cores you have in the host that's running your JVM and how much CPU you expect each thread to utilise.
Assuming an 8 core host where nothing else was running aside from your JVM, every task you execute is purely CPU bound, then you'd probably want to have a thread pool size of 7 (leaving one core free for JVM activities like garbage collection and other OS tasks).
However, systems are never that predictable, so it's probably better to do some profiling under expected loads and seeing what works best.