Acabo de tener un caso similar aquí, es por eso que doy una respuesta tardía.
El problema es que su solución con Thread.isAlive()
y Thread.start()
no es multihilo. Puede suceder que un primer hilo invoque su código, ejecute isAlive()
y en algún lugar dentro de Thread.start()
, después de que se inició el nuevo subproceso y antes de que se cambie de estado, se produce un cambio de tarea y un segundo llamador ejecuta isAlive()
cuando todavía está false
llamando start()
. dos veces. Para empeorar las cosas en algún lugar dentro de start()
parece que se fuerza un cambio de tarea y, por lo tanto, este problema aparece con bastante frecuencia.
Solución: Reemplazar start()
para que sea multi-hilo de seguridad, por ejemplo
private final AtomicBoolean started = new AtomicBoolean(false);
/* (non-Javadoc)
* @see java.lang.Thread#start()
*/
@Override
public synchronized void start() {
if (!started.getAndSet(true)) {
super.start();
}
}
Entonces el problema no aparecerá más, incluso si start()
accidentalmente se llama dos veces.
El subproceso puede no estar activo y todavía iniciado: es decir, puede haberse iniciado anteriormente y ya ha finalizado. Tal vez ese es el caso aquí? – pajton
Si dos hilos comparten una referencia a myThread, entonces ambos pueden examinar myThread.isAlive() y ambos ven falso, luego ambos intentan comenzar. Probablemente no deberías iniciar hilos como este (pasando alrededor de un objeto Thread que luego comienzas). Probablemente deberías estar usando un ExecutorService de java.util.concurrent.Executors. Si publica más detalles sobre lo que están haciendo los hilos, entonces puedo dar consejos más específicos. –