ScheduledExecutorService no ejecuta una tarea enviada con un initialDelay de 0 unidades de tiempo cuando se usa scheduleWithFixedDelay o scheduleAtFixedRate . Pero está ejecutando la tarea cuando llamo a la schedule .
ScheduledExecutorService scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(); Runnable runnable = () -> System.out.println("I am a runnable"); scheduledExecutorService.schedule(runnable, 0, TimeUnit.SECONDS); scheduledExecutorService.shutdown();Producción
I am a runnable Pero cuando uso scheduleWithFixedDelay o scheduleAtFixedRate en lugar de schedule la tarea no se ejecuta.
ScheduledExecutorService scheduledExecutorService = Executors.newSingleThreadScheduledExecutor(); Runnable runnable = () -> System.out.println("I am a runnable"); scheduledExecutorService.scheduleWithFixedDelay(runnable, 0, 1, TimeUnit.SECONDS); // or scheduledExecutorService.scheduleAtFixedRate(runnable, 0, 1, TimeUnit.SECONDS); scheduledExecutorService.shutdown(); ¿Por qué no se ejecuta la tarea en este escenario? Esperaba que esta tarea se ejecutara ya que initialDelay está establecido en 0
Apagaste el ejecutor demasiado pronto. Es por eso que aún no se ha iniciado otro hilo. No hay garantía de que el subproceso se inicie primero y luego el método de apagado.
Si usa awaitTermination, verá el resultado.
scheduledExecutorService.awaitTermination(1, TimeUnit.MILLISECONDS);//Salida: soy un ejecutable
Su llamada a ExecutorService#shutdown detiene cualquier programación adicional de tareas. Aparentemente, su llamada ocurre tan rápido que el programador nunca pudo ejecutar la primera ejecución de la tarea programada. Esto tiene sentido.
Lo que no tiene mucho sentido es por qué una llamada a la schedule se programa lo suficientemente rápido como para que su tarea se ejecute a tiempo antes del cierre, pero las llamadas a scheduleWithFixedDelay o scheduleAtFixedRate con una demora de cero no se programan tan rápido. Aparentemente, hay algunos gastos generales en las llamadas scheduleWithFixedDelay y scheduleAtFixedRate , suficientes gastos generales para que el programa salga antes de que tengan la oportunidad de realizar sus primeras ejecuciones.
De todos modos, puede ver el comportamiento en mi versión de su código ejecutándose en vivo en IdeOne.com . Agregando esta línea:
Thread.sleep( 1_000 * 5 ) ; … antes de que se apague da tiempo suficiente para que se ejecuten algunas de las tareas de scheduleWithFixedDelay y scheduleAtFixedRate .
O vea el mismo efecto agregando una llamada a awaitTermination como se muestra en la respuesta correcta de Nguyen .
La razón detrás se puede encontrar en ScheduledThreadPoolExecutor , que es la clase de implementación de Executors.newSingleThreadScheduledExecutor()
schedule llamadas,se debe a executeExistingDelayedTasksAfterShutdown es verdadero de forma predeterminada
/** * False if should cancel non-periodic not-yet-expired tasks on shutdown. */ private volatile boolean executeExistingDelayedTasksAfterShutdown = true;scheduleWithFixedDelay o scheduleAtFixedRatese debe a continueExistingPeriodicTasksAfterShutdown es falso por defecto
/** * False if should cancel/suppress periodic tasks on shutdown. */ private volatile boolean continueExistingPeriodicTasksAfterShutdown; Podemos anular estos parámetros mediante ScheduledThreadPoolExecutor#setExecuteExistingDelayedTasksAfterShutdownPolicy y ScheduledThreadPoolExecutor#setContinueExistingPeriodicTasksAfterShutdownPolicy antes de programar las tareas.
¿Por qué se llama al shutdown de inmediato, el schedule puede realizar esta tarea, pero scheduleAtFixedRate en tasa fija no realiza esta tarea?
Si se usa scheduleAtFixedRate , esta tarea es Periodic y la política predeterminada keepPeriodic es false , por lo que esta tarea se eliminará de la cola de trabajo cuando se llame al shutdown .
Pero el uso de la schedule no realiza la lógica de eliminar la tarea ( isPeriodic es falso).
Consulte ScheduledThreadPoolExecutor#onShutdown :
@Override void onShutdown() { BlockingQueue<Runnable> q = super.getQueue(); boolean keepDelayed = getExecuteExistingDelayedTasksAfterShutdownPolicy(); boolean keepPeriodic = getContinueExistingPeriodicTasksAfterShutdownPolicy(); // Traverse snapshot to avoid iterator exceptions // TODO: implement and use efficient removeIf // super.getQueue().removeIf(...); for (Object e : q.toArray()) { if (e instanceof RunnableScheduledFuture) { RunnableScheduledFuture<?> t = (RunnableScheduledFuture<?>)e; if ((t.isPeriodic() ? !keepPeriodic : (!keepDelayed && t.getDelay(NANOSECONDS) > 0)) || t.isCancelled()) { // also remove if already cancelled if (q.remove(t)) t.cancel(false); } } } tryTerminate(); }Entonces creo que la explicación de la respuesta de Basil Bourque es inexacta:
Aparentemente, hay algunos gastos generales en las llamadas scheduleWithFixedDelay y scheduleAtFixedRate, suficientes gastos generales para que el programa salga antes de que tengan la oportunidad de realizar sus primeras ejecuciones.
No es porque el programa finalice antes de que tengan la oportunidad de realizar sus primeras ejecuciones, sino porque los subprocesos de trabajo en el grupo de subprocesos no obtuvieron la tarea (se eliminó), y luego el grupo de subprocesos se detuvo. En este momento, el programa sale. Si no se elimina la tarea, el programa no se cerrará inmediatamente. Solo cuando el subproceso de trabajo en el grupo de subprocesos haya completado las tareas en la cola de trabajo, el programa se cerrará. (Porque el subproceso de trabajo en el grupo de subprocesos no son subprocesos daemon).