[concurrency-interest] ScheduledThreadPoolExecutor threadtimeout

Zhong Yu zhong.j.yu at gmail.com
Mon Feb 3 14:44:03 EST 2014


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.

>
> Heinz


More information about the Concurrency-interest mailing list