Java: LockSupport.parkNanos vs Thread.sleep (...)

Question

En algunos casos, la mayoría de nosotros escribir cosas como esta:

try { 
    Thread.sleep(2000); 
} catch (InterruptedException e) { 
    ; // do nothing 
} 

Ya sea bueno o malo, aceptable sólo en algunos arneses de prueba, no es mi punto. Mi punto es que el mismo código se podría escribir, más sucintamente, como:

LockSupport.parkNanos(2000* 1000000); 

¿Hay alguna razón por la que debería favorecer un enfoque sobre el otro.

Answer 1

la documentación para el método parkNanos proporciona las condiciones en las que puede devolver el método. Una de esas condiciones es: la llamada falsamente (es decir, sin motivo) devuelve. Así que, básicamente, está bien usarlo si no te molestan los despertadores espurios y algunos otros subprocesos que "desvelan" el hilo de espera en consideración. Y, por supuesto, el comentario de Jon básicamente explica el razonamiento para preferir uno sobre otro.

Answer 2

LockSupport tiene una aplicación mucho más limitada, y no admite el manejo de excepciones. Si solo tiene que bloquear un solo hilo, está bien.

Desde el API:

están diseñados estos métodos para ser utilizados como herramientas para crear utilidades de sincronización de nivel más alto, y no son en sí mismos útil para la mayoría de aplicaciones de control de concurrencia.

Answer 3

Legibilidad: Thread.sleep tiene un significado bastante intuitivo. ¿Cómo describiría usted (a otro desarrollador) su uso de LockSupport.parkNanos? Si esa descripción consiste principalmente en "Quiero el actual hilo a dormir" entonces seguramente Thread.sleep es más descriptivo.

La concisión proviene de la falta de manejo de interrupciones, por lo tanto, cree un método de envoltura para hacer esto si lo desea, que propaga la excepción como RuntimeException. Heck, si va a crear un método de envoltura, se puede utilizar ya sea la aplicación, aunque otro hilo podría, por supuesto anular el estacionamiento de su "dormir" hilo de la misma manera como podría interrumpirlo ...