How to check utilization of fixed thread pool [duplicate] - java

This question already has an answer here:
Active threads in ExecutorService
6 answers
I'm running a Java application that uses a fixed thread pool, where threads are used to make HTTP requests to external services.
The thread pool was purposefully overprovisioned, and I want to obtain some measurements for utilization of the thread pool (i.e, at this moment, 20% of the threads in the pool were free, at this other moment 30% of threads were busy).
Is there an efficient way of checking what proportion of the thread pool (created through the Executors.newFixedThreadPool(x)) is currently performing a task?
I had thought about creating a special monitor thread that continually runs a Callable task, reporting back the utilization, but I wasn't certain if that would impact performance of the tread pool itself (by making threads respond to the monitor instead of making HTTP calls).

All of the following are with respect to:
package java.util.concurrent;
If you are OK with bypassing the factory method and creating a 'ThreadPoolExecutor' instance directly, then you could use a monitor thread and invoke 'ThreadPoolExecutor.getActiveCount' (amoung other useful methods) to tell the thread pool state.
Unfortunately, the factory methods on 'Executors' don't expose 'ThreadPoolExecutor': The return type is 'ExecutorService', and that doesn't expose the necessary methods. You would have to instantiate the thread pool executor directly.
I looked for overridable methods which would run when a thread pool started a thread, or when a managed thread stopped, and didn't find any non-private methods which would be useful. Otherwise, subclassing the thread pool, with overrides of those methods which display the thread pool state would be another way to monitor the thread pool state which does not require a monitor thread.
public class Executors {
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
public interface ExecutorService extends Executor {
public interface Executor {
public abstract class AbstractExecutorService implements ExecutorService {
public class ThreadPoolExecutor extends AbstractExecutorService {
/**
* Returns the approximate number of threads that are actively
* executing tasks.
*
* #return the number of threads
*/
public int getActiveCount();

Related

Limiting one of each Runnable type in ExecutorService queue

I have an Executors.newFixedThreadPool(1) that I send several different tasks to (all implementing Runnable), and they get queued up and run sequentially correct? What is the best way to only allow one of each task to be either running or queued up at one time? I want to ignore all tasks sent to the ExecutorService that are already in the queue.
I have an Executors.newFixedThreadPool(1) that I send several different tasks to (all implementing Runnable), and they get queued up and run sequentially correct?
Yes, by default the underlying thread pool executor is created with a LinkedBlockingQueue. Since you have only one worker thread and the queue is used in a FIFO manner, tasks will be executed in order.
What is the best way to only allow one of each task to be either running or queued up at one time? I want to ignore all tasks sent to the ExecutorService that are already in the queue.
The easiest way I can think is to create your own ExecutorService which extends a ThreadPoolExecutor. Then override the execute() method such that you call BlockingQueue#contains(Object) prior to delegating to the super classes execute.
public class LimitedExecutorService extends ThreadPoolExecutor {
public LimitedExecutorService(final int nThreads) {
super(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());
}
#Override
public void execute(Runnable command) {
if (!this.getQueue().contains(command)) {
super.execute(command);
} else {
//reject
}
}
}
Note: Many people will argue that you should not extend a ThreadPoolExecutor, but instead say you implement ExecutorService and have your class contain a ThreadPoolExecutor which you delegate to (aka composition).
The thread pool does not guarantee task ordering.
As for the second part you can set the rejected execution handler, using ThreadPoolExecutor.DiscardPolicy using ThreadPoolExecutor

How to change thread pool size in ScheduledExecutorService?

I need ScheduledExecutorService with a dynamic thread pool. I want to change the thread pool size dynamically. How can I do this?
class ExecutorTask {
private ScheduledExecutorService service;
public void add(Task task) {
// I need thread pool size == count added tasks.
service.scheduleAtFixedRate(this::start, 0, 10, TimeUnit.SECONDS);
}
}
Maybe you can advice me another thread pool?
You can easily do that with ScheduledThreadPoolExecutor.
//Init executor
int initialPoolSize = 5;
ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(initialPoolSize);
//[...] do something
//Change max size
int newPoolSize = 10;
executor.setCorePoolSize(newPoolSize);
Note that the inherited method setMaximumPoolSize(int) has no effect on ScheduledThreadPoolExecutor. To change the pool size you need to change the corePoolSize:
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.
Additionally, it is almost never a good idea to set corePoolSize to
zero or use allowCoreThreadTimeOut because this may leave the pool
without threads to handle tasks once they become eligible to run.
Maybe that is what you are looking for in the Executors Util class:
ExecutorService executorService = Executors.newScheduledThreadPool(5)
you can use setCorePoolSize(int) method for that.
Also using Executors.newCachedThreadPool you provide the responsibility of creating the thread pool size to ThreadPoolExecutor.
The ThreadPoolExecutor creates new threads if needed to execute the new tasks, and reuses the existing ones with Executors.newCachedThreadPool()

Detect if current thread is ExecutorService thread

I want to ensure all methods of my class (updater service) are called within the ExecutorService's thread (provided there's even a single thread). The order of the methods is not given so those that are public might get called from both the Executor's thread and some other threads, mostly GUI thread.
My code:
// Instantiated lazy using synchronized getter - I decided not to bother with shared locks
private ExecutorService executor;
/**
* Provides compatibility between calls from executor thread pool and other threads.
* No matter the thread from which you call this method, the callback will be executed
* within the loop. Proper events will be raised in the loop thread as well, so
* mind to use SwingUtilities.invokeLater if event involves GUI operations.
* #param callback
* #throws Exception
*/
protected void runInExecutorIfNeeded(Callable callback) throws Exception {
// Already in executor thread
if(Thread.currentThread() == /* ??? */)
callback.call();
// Not in executor thread, go to executor thread and call callback there
else
getExecutor().submit(callback);
}
I have already done a similar thing in Swing - for methods like changeApplicationTrayIcon I simply checked if I'm in GUI thread and if not, I used SwingUtilities.invokeLater.
So, how do I check if current code is running in Executor's thread?
If you provide an implementation of a ThreadFactory to your implementation of an ExecutorService (e.g. a ThreadPoolExecutor), you could record the threads created by the factory (either by reference or id) and perform a lookup against that ThreadFactory later on in order to determine if they've been created by the factory, and thus an executor thread

Differences between these 2 factory methods

I would like to know the difference between these 2 methods:
public static ExecutorService newFixedThreadPool(int nThreads)
and
public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory tf)
Obviously one takes a specified ThreadFactory for threads creation. However I would like to know what kind of standard ThreadFactory the former use?
Why is it convenient using the latter rather than the former or vice-versa?
Thanks in advance.
The first one uses the DefaultThreadFactory which is an inner class of Executors. When you define your own ThreadFactory you can influence the created Threads. You can choose their name, priority, etc.
DefaultThreadFactory,
New threads are created using a ThreadFactory. If not otherwise
specified, a Executors.defaultThreadFactory() is used, that creates
threads to all be in the same java.lang.ThreadGroup and with the same
NORM_PRIORITY priority and non-daemon status. By supplying a different
ThreadFactory, you can alter the thread's name, thread group,
priority, daemon status, etc. If a ThreadFactory fails to create a
thread when asked by returning null from newThread, the executor will
continue, but might not be able to execute any tasks. Threads should
possess the "modifyThread" RuntimePermission. If worker threads or
other threads using the pool do not possess this permission, service
may be degraded: configuration changes may not take effect in a timely
manner, and a shutdown pool may remain in a state in which termination
is possible but not completed.
Reference -
But you can encapsulate the thread creation in your ThreadFactory, what actaully usage of Factory pattern.
For Example -
class SimpleThreadFactory implements ThreadFactory {
public Thread newThread(Runnable r) {
// do something
return new Thread(r);
}
}
For reference please check - documentation and also find a good answer.
The first uses Executors.defaultThreadFactory to create threads with the first version. You would use the first version if you don't care how the threads are created, and the second if you need to impose some custom settings on the threads when they are created.

Controlling the number of threads and controlling object accessing in a Multi Threaded Web Crawler in Java

I built a web crawler but it is single threaded. Now I am extending it to work with multiple threads. I am not able to understand the following :
How many threads should I create? Should it be a fixed number or a dynamic one changing according to the length of the Queue holding the URIs? (Taking into consideration the available memory also)
I have created a new class for the thread through the Runnable Interface and I want each thread's run method to access an object I created in my Main class which is calling thread.start(). How should I access this object from each thread?
I am using NetBeans.
You're definitely going to want concurrency with a web a crawler :)
And you're probably going to want to set up a thread pool so that you can reuse threads and not bite the cost of instantiating new threads with each task.
The thread pool options that you have are a FixedThreadPool and a CachedThreadPool. the benefits of each of these are explained in detail in the Java Concurrency Tutorial. The big drawback of the CachedThreadPool is that there's no limit on how many threads can be created; in the event that a very large number of threads are added to the pool, you might see some significant performance degradation or timeouts (if you have a socket timeout defined).
In either case, the best practice for setting up thread pools is through java.util.concurrent.Executors
It's just a matter of creating an ExecutorService by calling one of the following:
ExecutorService threadPool = Executors.newCachedThreadPool();
ExecutorService threadPool = Executors.newFixedThreadPool(500);
Once you have the threadpool, you can either invoke a single runnable (which doesn't return a response) or a callable (which does) by using the submit() method.
You can also run .invokeAll() if you're using callables to generate futures:
futures = cachedThreadPool.invokeAll(tasks,
timeout,
TimeUnit.MILLISECONDS);
And then get the results:
for (Future f: futures) {
someList.add(f.get())
}
If you want multiple threads to be able to modify the same object, you'll either need to use the synchronized keyword in the setters or use thread-safe data types.
Hope this helps. Good luck!!
For the first question I guess in your situation it's best to use a dynamically adjusting thread pool like:
ExecutorService exec = Executors.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.
For the second question, you can create a constructor and pass objects that way:
class ThreadTask implements Runnable {
private Object obj;
public ThreadTask(Object obj) {
this.obj = obj;
}
public void run() {
}
}
public static void main(String[] args) {
Object obj = new Object();
exec.submit(new ThreadTask(obj));
}
There could not be any specific answer it. But you can study on following -
For 1st point study on ExecutorService and ThreadPoolExecutor.
For 2nd point study on callable and Future.

Resources