executorservice | 易学教程

How to stop an executor thread when Tomcat is stopped?

阅读更多关于 How to stop an executor thread when Tomcat is stopped?

问题 I am using an executor service by creating a fixed number of threads to do a HTTP GET data retrieval. executorService = ExecutorServiceFactory.getInstance().getExecutorService(Config.getInstance().getNumberOfThreads(), "ThreadExecutor_"+UIDFactory.getInstance().createSessionID()); executorService.execute(new Retrieve(data)); private class Retrieve implements Runnable{ private Vector<String> data; public WADORetrieve(Vector<String> data) { this.data = data; } @Override public void run() { for

Impossible to make a cached thread pool with a size limit?

阅读更多关于 Impossible to make a cached thread pool with a size limit?

It seems to be impossible to make a cached thread pool with a limit to the number of threads that it can create. Here is how static Executors.newCachedThreadPool is implemented in the standard Java library: public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>()); } So, using that template to go on to create a fixed sized cached thread pool: new ThreadPoolExecutor(0, 3, 60L, TimeUnit.SECONDS, new SynchronusQueue<Runable>()); Now if you use this and submit 3 tasks, everything will be fine.

Stop a periodic task from within the task itself running in a ScheduledExecutorService

阅读更多关于 Stop a periodic task from within the task itself running in a ScheduledExecutorService

问题 Is there a nice way to stop the repetition of task from within the task itself when running in a ScheduledExecutorService? Lets say, I have the following task: Future<?> f = scheduledExecutor.scheduleAtFixedRate(new Runnable() { int count = 0; public void run() { System.out.println(count++); if (count == 10) { // ??? cancel self } } }, 1, 1, TimeUnit.SECONDS); From outside, it is easy to cancel via f.cancel(), but how can I stop the repetition at the specified place? (Passing the Future

Java's Fork/Join vs ExecutorService - when to use which?

阅读更多关于 Java's Fork/Join vs ExecutorService - when to use which?

I just finished reading this post: What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool? and felt that the answer is not straight enough. Can you explain in simple language and examples, what are the trade-offs between Java 7's Fork-Join framework and the older solutions? I also read the Google's #1 hit on the topic Java Tip: When to use ForkJoinPool vs ExecutorService from javaworld.com but the article doesn't answer the title question when , it talks about api differences mostly ... Jakub Kubrynski Fork-join allows you to easily execute divide and conquer jobs,

What is the best way to handle an ExecutionException?

阅读更多关于 What is the best way to handle an ExecutionException?

问题 I have a method that performs some task with a timeout. I use the ExecutorServer.submit() to get a Future object, and then I call future.get() with a timeout. This is working fine, but my question is the best way to handle checked exceptions that can be thrown by my task. The following code works, and preserves the checked exceptions, but it seems extremely clumsy and prone to break if the list of checked exceptions in the method signature changes. Any suggestions on how to fix this? I need

Method call to Future.get() blocks. Is that really desirable?

阅读更多关于 Method call to Future.get() blocks. Is that really desirable?

问题 Please read the question carefully before marking this as duplicate. Below is the snippet of the pseudo code. My question is- Does the below code not defeat the very notion of parallel asynchronous processing? The reason I ask this is because in the below code the main thread would submit a task to be executed in a different thread. After submitting the task in the queue, it blocks on Future.get() method for the task to return the value. I would rather have the task executed in the main

Is ExecutorService (specifically ThreadPoolExecutor) thread safe?

阅读更多关于 Is ExecutorService (specifically ThreadPoolExecutor) thread safe?

Does the ExecutorService guarantee thread safety ? I'll be submitting jobs from different threads to the same ThreadPoolExecutor, do I have to synchronize access to the executor before interacting/submitting tasks? It's true, the JDK classes in question don't seem to make an explicit guarantee of thread-safe task submission. However, in practice, all ExecutorService implementations in the library are indeed thread-safe in this way. I think it's reasonable to depend on this. Since all the code implementing these features was placed in the public domain, there's absolutely no motivation for

Turning an ExecutorService to daemon in Java

阅读更多关于 Turning an ExecutorService to daemon in Java

I am using an ExecutoreService in Java 1.6, started simply by ExecutorService pool = Executors.newFixedThreadPool(THREADS). When my main thread is finished (along with all the tasks processed by the thread pool), this pool will prevent my program from shutting down until I explicitly call pool.shutdown(); Can I avoid having to call this by somehow turning the internal thread managing used by this pool into a deamon thread? Or am I missing something here. Probably simplest and preferred solution is in Marco13's answer so don't get fooled by vote difference (mine answer is few years older) or

Dynamic Thread Pool

阅读更多关于 Dynamic Thread Pool

问题 I have a long running process that listens to events and do some intense processing. Currently I use Executors.newFixedThreadPool(x) to throttle the number of jobs that runs concurrently, but depending of the time of the day, and other various factors, I would like to be able to dynamically increase or decrease the number of concurrent threads. If I decrease the number of concurrent threads, I want the current running jobs to finish nicely. Is there a Java library that let me control and

Future task of ExecutorService not truly cancelling

阅读更多关于 Future task of ExecutorService not truly cancelling

问题 I push my Futures from a ExecutorService into a hash map. Later, I may call cancel on Futures from within the hash map. Although the result is true, I later hit breakpoints within the Callable procedure, as if the Future cancel() had no effect. I think it might be a case of two different references here (even though the reference IDs are listed as the same when breakpointing), but was wondering if some experts could chime in. Here's what the code looks like: ExecutorService taskExecutor =