Guys I'm in bit dilemma between Tree Set
and Thread Pool Executor
Following is the scenario :
First Approach
treeset constructor
(with comparator
interface) Second Approach
Thread pool executor
and for this I had taken inspiration from this link and I had achieved my requirements with this approach also which will choose high priority task first and execute it first and same way it will execute all the tasks. Now my confusion here is which one is best to use in term of performance costs, flexibility(increase/decrease threads) etc and why should I opt for it?
Any suggestions and answers are highly appreciated.
There are two different notions of priority embedded in your question:
starting priority: in which order tasks are submitted for execution, (point 1 of your first approach explanation)
runtime priority: in which order threads are considered for scheduling (point 3)
These two properties happen to be equal in your scenario, so the tree set will help you define both of them. The executor will help you enforce them, but you will need an ad-hoc tailored executor (based on thread pooling or not), to start your threads up with a specific priority. Basically, each time a task is pulled out of the priority queue, it should be associated with a thread set at the task's priority level. I assume that this is the feature that the executor implementation found in the article you link is providing, and thus what you do.
As for thread pools, from the documentation:
Using worker threads minimizes the overhead due to thread creation. Thread objects use a significant amount of memory, and in a large-scale application, allocating and deallocating many thread objects creates a significant memory management overhead.
Worker threads are threads managed by threadpools, and are conservatively recycled (as opposed to destroyed and recreated), to handle sequences of tasks. I Don't think it matters much with regard to priority handling, but it will optimise your usage of resources.
Regarding the implementation from the article, the code uses a simple blocking deque for handling incoming tasks, hence it's a plain fifo priority scheme. It doesn't reorder tasks.
Finally got the real winner out of this two. I should select for Thread pool Executor
because of following reasons
thread pool executor
architecture and vice versa. comparator
interface though it has complexity O(logn) but after that we have to fetch it and it will become a sequential flow of single source so we will not multi-threaded environment advantage. etc were the reasons which I pointed out during a heavy brain storming,googling and last but not the least stack Overflow searching. Thank you all for your humble support and huge appreciation to @didierc for getting me clear over it.
You can try DelayedQueue in ordinary threadpool.
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(size, size, 0, TimeUnit.DAYS, new DelayQueue<>());
threadPoolExecutor.execute(runnable);
Runnable should be implements Comparable . So In this implementation , priority will taken care by delayedqueue.
This approach will be easier to implement.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.