Java8; Utilizar el tiempo de sueño en un hilo, pero varios callables

IndustryUser1942:

¿Es posible en java8 estándar para ejecutar múltiples callables en un solo hilo al mismo tiempo?
es decir, cuando uno duerme exigibles, empezar a trabajar en otra exigible.

Mi experimento actual, lo que no funciona:

    ExecutorService executor = Executors.newSingleThreadExecutor();
    List<Future> fs = new ArrayList<>();
    for (int i = 0; i < 2; i++) {
        final int nr = i;
        fs.add(executor.submit(() -> {
            System.out.println("callable-" + nr + "-start");
            try { Thread.sleep(10_000); } catch (InterruptedException e) { }
            System.out.println("callable-" + nr + "-end");
            return nr;
        }));
    }
    try { executor.awaitTermination(5, TimeUnit.SECONDS); } catch (InterruptedException e) { }

Resultados en:

callable-0-start
callable-0-end
callable-1-start
callable-1-end

Quiero tener:

callable-0-start
callable-1-start
callable-0-end
callable-1-end

notas:

• Yo como que esperaba una respuesta:.... "No, no es posible Esto no es cómo se asigna hilos trabajos con hilos vez a algún código ejecutable que se ejecuta hasta su finalización, excepción o cancelación No puede haber pleno vuelo de conmutación entre callables / runnables Thread.sleepsolamente permite a otros hilos se ejecuten en CPU / núcleo ". (confirmación explícita pondría mi mente para descansar)
• Naturalmente, esto es ejemplo "juguete".
• Esta es la comprensión, no un problema específico que tengo.

TreffnonX:

Lo que se intenta hacer es emular la funcionalidad no se utiliza en las versiones antiguas de Java. En aquel entonces era posible detener, suspender o reanudar una Thread. Pero desde el javadoc de Thread.stop:

Este método es inherentemente inseguro. Detención de un hilo con Thread.stop hace que para desbloquear todos los monitores que se ha bloqueado (como una consecuencia natural de la excepción ThreadDeath sin control de reproducción hasta la pila). Si cualquiera de los objetos previamente protegidos por estos monitores estaban en un estado inconsistente, los objetos dañados se hacen visibles a otros hilos, potencialmente resultando en comportamiento arbitrario. Muchos usos de parada deben ser sustituidos por el código que simplemente modifica alguna variable para indicar que el subproceso de destino debe dejar de funcionar. El subproceso de destino debe comprobar regularmente esta variable, y volver de su método run de una manera ordenada si la variable indica que se trata de dejar de correr. Si el subproceso de destino espera por largos períodos de tiempo (en una variable de condición, por ejemplo), el método de interrupción debe ser utilizado para interrumpir la espera.

Según la descripción de este descarte, los riesgos de hacer lo que quiere eran críticos, y por lo tanto este comportamiento ya no se utiliza.

Yo sugeriría, que en lugar de tratar de forzar un hilo conductor en una especie de posición de detención desde el exterior, que tal vez debería pensar en una API ThreadPool que le permite empaquetar sus segmentos de código correctamente, por lo que su estado puede ser descargada desde una enhebrar, y más tarde reanudado. por ejemplo, crear Ticket, lo que sería un trabajo elemental, lo que sería un hilo siempre es completa antes de comenzar otra, una TicketChainque conecta secuencialmente entradas y almacena el estado. A continuación, hacer un manejador que las entradas manijas uno por uno. En el caso de un billete no puede hacerse en la actualidad (por ejemplo, porque no todos los datos está presente, o alguna de bloqueo no puede ser adquirido) la rosca puede saltar hasta un punto posterior en el tiempo, cuando dichas condiciones podrían ser verdad.