[concurrency-interest] ScheduledThreadPoolExecutor threadtimeout

Zhong Yu zhong.j.yu at gmail.com
Thu Feb 6 15:02:23 EST 2014


On Thu, Feb 6, 2014 at 12:55 PM, Martin Buchholz <martinrb at google.com> wrote:
> In fact, the current implementation ensures that we never have the queue
> non-empty and no threads to service the task when its time comes.

Thanks, that does seem to be the case. I'll take the risk of ignoring
the javadoc warning.

>
> A higher-quality implementation might ensure that a new thread is created
> (up to core size) not only when a task is submitted to the pool, but also
> when the scheduled time arrives.  Which might mean not just keeping at least
> one thread around, but keeping one idle "manager" thread around that spawns
> new threads to service the ones in the queue.
>
> But the ThreadPoolExecutor code is brittle and we're afraid to touch it.
>
>
> On Mon, Feb 3, 2014 at 12:13 PM, Dr Heinz M. Kabutz
> <heinz at javaspecialists.eu> wrote:
>>
>> Zhong Yu wrote:
>>
>> On Mon, Feb 3, 2014 at 12:22 PM, Dr Heinz M. Kabutz
>> <heinz at javaspecialists.eu> wrote:
>>
>>
>> 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.
>>
>> is the current implementation more robust than that?
>>
>>
>> I think it is in the sense that if there is a task waiting to become
>> eligible to run then there is a worker thread that is waiting for that
>> time
>> to arrive. But the details are complex and there may be circumstances
>> where
>> tasks are not executed as expected.
>>
>>
>> It looks like setting the core size to zero might result in additional
>> threads being constructed if we finish all the tasks in the queue and wait
>> a
>> little bit.  But as far as I could tell, that's the worst case scenario,
>> which is better than leaking threads.  Am I missing anything?
>>
>>
>> import java.util.concurrent.*;
>>
>> public class ForeverYoung {
>>   public static void main(String[] args) throws InterruptedException {
>>     ThreadPoolExecutor tpe = new ThreadPoolExecutor(
>>         0, Integer.MAX_VALUE, 0, TimeUnit.NANOSECONDS,
>>         new LinkedBlockingQueue<>()
>>     );
>>     tpe.submit(() -> System.out.println("tpe1 by " +
>> Thread.currentThread()));
>>     tpe.submit(() -> System.out.println("tpe2 by " +
>> Thread.currentThread()));
>>     tpe.submit(() -> System.out.println("tpe3 by " +
>> Thread.currentThread()));
>>
>>
>>     ScheduledThreadPoolExecutor exec =
>>         new ScheduledThreadPoolExecutor(0);
>>     exec.schedule(() -> {
>>       System.out.println("task 1 by " + Thread.currentThread());
>>     },
>>         ThreadLocalRandom.current().nextInt(5) + 1,
>>         TimeUnit.SECONDS
>>     );
>>     exec.schedule(() -> {
>>       System.out.println("task 2 by " + Thread.currentThread());
>>     },
>>         ThreadLocalRandom.current().nextInt(5) + 1,
>>         TimeUnit.SECONDS
>>     );
>>     exec.schedule(() -> {
>>       System.out.println("task 3 by " + Thread.currentThread());
>>     },
>>         ThreadLocalRandom.current().nextInt(5) + 1,
>>         TimeUnit.SECONDS
>>     );
>>     Thread.sleep(6000);
>>     exec.schedule(() -> {
>>       System.out.println("task 4 by " + Thread.currentThread());
>>     },
>>         1,
>>         TimeUnit.SECONDS
>>     );
>>
>>   }
>> }
>>
>>
>> Output:
>>
>> java version "1.8.0"
>> Java(TM) SE Runtime Environment (build 1.8.0-b126)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b67, mixed mode)
>>
>> tpe1 by Thread[pool-1-thread-1,5,main]
>> tpe2 by Thread[pool-1-thread-1,5,main]
>> tpe3 by Thread[pool-1-thread-2,5,main]
>> task 1 by Thread[pool-2-thread-1,5,main]
>> task 3 by Thread[pool-2-thread-1,5,main]
>> task 2 by Thread[pool-2-thread-1,5,main]
>> task 4 by Thread[pool-2-thread-2,5,main]
>>
>> As we can see, task 4 is executed by a new thread.  But so what?
>>
>>
>> I have no problem with that, but I wonder if it is safe to do so,
>> i.e., all submitted tasks will be executed even if core threads may
>> time out, against the advice of the javadoc.
>>
>>
>> In my test case, the core thread did time out and the world did not end.
>> Another thread was started when a new job was submitted.  But I already got
>> into trouble once this week for ignoring a JavaDoc comment, so I won't say
>> that this necessarily wil always work ;-)
>>
>> Heinz
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>


More information about the Concurrency-interest mailing list