prueba ejemplo
|
|
Título del Test:
![]() prueba ejemplo Descripción: prueba ejemplo |



| Comentarios |
|---|
NO HAY REGISTROS |
|
¿Cuál es la diferencia fundamental entre la interfaz Runnable y la interfaz Callable cuando se envían tareas a un ExecutorService?. Runnable puede ser ejecutada solo por un solo hilo (SingleThreadExecutor), mientras que Callable requiere un pool de hilos (FixedThreadPool). Runnable define un método run() que no devuelve un valor (void), mientras que Callable devuelve un valor genérico y puede lanzar excepciones. Callable es una interfaz más antigua (introducida en JDK 1.0), mientras que Runnable fue introducida en Java 5. Runnable es utilizada por ExecutorService.execute(), mientras que Callable es utilizada por ExecutorService.submit(). Si se utiliza un ExecutorService para enviar una tarea Callable, ¿qué tipo de objeto se devuelve inmediatamente, permitiendo recuperar el resultado más tarde o verificar el estado de la tarea?. CompletableFuture. Thread. Future. ExecutionResult. ¿Qué garantiza la palabra clave volatile en Java con respecto a una variable compartida entre múltiples hilos?. Garantiza la atomicidad de las operaciones de lectura, modificación y escritura. Garantiza la exclusión mutua, asegurando que solo un hilo pueda acceder a la variable a la vez. Garantiza la visibilidad, asegurando que todos los hilos tengan una vista consistente del valor de la variable. Garantiza que la variable sea recogida por el recolector de basura inmediatamente después de que el hilo termine. En el contexto de la interfaz Future devuelta por un ExecutorService, ¿cuál es el efecto de llamar al método get() sin un timeout si la tarea aún se está ejecutando?. Lanza una TimeoutException. Devuelve inmediatamente null. Hace que la ejecución se bloquee hasta que la tarea finalice y el resultado esté disponible. Cancela la tarea y devuelve false. ¿Cuál es la función principal de la clase ThreadLocal?. Garantizar que todos los hilos compartan una única instancia de una variable, optimizando la memoria. Proporcionar operaciones atómicas en variables sin necesidad de sincronización explícita. Permitir que cada hilo tenga su propia copia, inicializada de forma independiente, de una variable, logrando así el thread confinement. Prevenir activamente el deadlock al forzar un orden estricto de adquisición de bloqueos. Un deadlock (interbloqueo) en aplicaciones concurrentes ocurre típicamente cuando: Un hilo intenta llamar al método start() más de una vez. Un ExecutorService no se apaga explícitamente y continúa esperando tareas. Dos o más hilos se bloquean mutuamente mientras esperan un recurso mantenido por el otro hilo. Se utiliza un tamaño de heap JVM demasiado grande, lo que degrada el rendimiento del Garbage Collection (GC). Para solucionar problemas graves de rendimiento en aplicaciones Java, como el bloqueo de hilos o la espera de recursos, ¿qué instantánea de ejecución de código se recomienda tomar, generalmente varias veces, para identificar la causa raíz?. Un memory dump (o heap dump). Una CPU profile. Un Java thread dump (o stack dump). Un network trace. En Java, ¿cuál de los siguientes mecanismos utiliza la clase AtomicInteger (y otras clases atómicas) para garantizar operaciones de lectura, modificación y escritura atómicas sin requerir el uso de la palabra clave synchronized?. El bloqueo intrínseco asociado a cada objeto. Operaciones atómicas de bajo nivel como Compare-And-Swap (CAS). El ForkJoinPool.commonPool(). La deshabilitación de la detección de grupos de control (CGroups). Cuando se implementa la clase Thread, ¿qué método se invoca para iniciar la ejecución concurrente del nuevo hilo, y cuál es el método que contiene la lógica de la tarea que se ejecutará en ese hilo?. Se invoca run(), y la lógica está en execute(). Se invoca run(), y la lógica está en start(). Se invoca start(), y la lógica está en run(). Se invoca submit(), y la lógica está en call(). ¿Cuál de las siguientes es una práctica recomendada para asegurar el apagado (shutdown) adecuado de un ExecutorService?. Llamar a shutdownNow() y luego a shutdown() para interrumpir todas las tareas. Llamar a execute() y luego esperar hasta que no haya más tareas pendientes. Llamar a shutdown() para dejar de aceptar nuevas tareas, y luego usar awaitTermination() con un timeout antes de llamar a shutdownNow() si el tiempo expira. El ExecutorService se destruye automáticamente cuando no hay tareas que procesar. |





