Muchas preguntas de entrevistas de Java principales provienen de marcos de colecciones de múltiples subprocesos y colecciones. La experiencia práctica competente es necesaria al comprender el concepto de hilos centrales. Este artículo recopila algunas preguntas típicas sobre el enhebrado de Java, que a menudo las hacen ingenieros senior.
0. ¿Qué es la sincronización multiproceso en Java?
Bajo programas multiproceso, la sincronización puede controlar el acceso a recursos compartidos. Si no hay sincronización, cuando un hilo de Java está modificando una variable compartida, otro hilo está utilizando o actualizando la misma variable, lo que puede conducir fácilmente a resultados incorrectos en el programa.
1. Explicar varias formas de implementar múltiples subprocesos?
Un hilo de Java puede implementar la interfaz ejecutable o heredar la clase de subprocesos para implementarlo. Cuando planea heredar varias veces, preferirá implementar Runnable.
2. ¿Cuál es la diferencia entre thread.start () y thread.run ()?
El método thread.start () (nativo) inicia el hilo y ingresa al estado listo. Cuando la CPU asigna tiempo al hilo, el JVM programa para ejecutar el método run ().
3. ¿Por qué necesitamos los métodos Run () e inicio ()? ¿Podemos usar el método Run () para completar la tarea?
Necesitamos los dos métodos de ejecución () y inicio () porque el JVM crea un hilo separado diferente de la llamada de los métodos ordinarios, por lo que este trabajo se realiza mediante el método de inicio del hilo. El inicio es implementado por el método local y debe llamarse visualmente. Otra ventaja de usar estos dos métodos es que cualquier objeto se puede ejecutar como un hilo. Mientras se implementa la interfaz ejecutable, esto evita los problemas de herencia múltiples de Java causados por heredar la clase de hilo.
4. ¿Cuál es la clase Threadlocal y cómo usarla?
Threadlocal es una variable local a nivel de hilo, no un "hilo local". ThreadLocal proporciona una copia independiente de la variable para cada hilo que usa la variable. Cada hilo no afecta la copia de otros objetos de subproceso al modificar la copia (nota del traductor).
Estos son los puntos clave de las variables locales de hilo:
Una variable local de subprocesos (variable de treveLocal) proporciona convenientemente una variable separada para cada hilo.
Las instancias de Threadlocal generalmente aparecen en una clase como campos privados (estáticos privados) estáticos, que se utilizan para asociar un hilo.
Cuando múltiples hilos acceden a instancias de ThreadLocal, cada subproceso mantiene una copia independiente de las variables proporcionadas por ThreadLocal.
Los usos de uso común se pueden ver en el modo DAO. Cuando la clase DAO es una clase Singleton, cada hilo mantiene independientemente la conexión de la base de datos y no se afecta entre sí. (Singleton basado en hilo)
5. ¿Cuándo se lanzará InvalidMonitorStateException y por qué?
Al llamar a cualquiera de los métodos en WAIT ()/notify ()/notifyall (), si el hilo actual no obtiene el bloqueo del objeto, se lanza una excepción de IllegalMonitorStateException (es decir, cuando el programa no ejecuta ningún bloque de sincronización o método de sincronización del objeto, todavía intenta llamar a la espera ()/Notify ()/NotifyAll ()). Dado que la excepción es una subclase de RuntimeExcPetion, la excepción no tiene que ser atrapada (aunque puede atraparla todo el tiempo que desee). Como RuntimeException, tales excepciones no se mencionan en la firma Wait (), notify (), notifyall () del método.
6. ¿Cuál es la diferencia entre dormir (), suspender () y esperar ()?
Thread.sleep () hace que el hilo actual sea en un estado "no ejecutable" en el momento especificado. El hilo siempre contiene el monitor del objeto. Por ejemplo, si un hilo se encuentra actualmente en un bloque de sincronización o método de sincronización, otros subprocesos no pueden ingresar al bloque o el método. Si otro hilo llama al método de interrupción (), despertará ese hilo "durmiendo".
Nota: Sleep () es un método estático. Esto significa que solo es válido para el hilo actual, y un error común llama a t.sleep (), (aquí T es un hilo que es diferente del hilo actual). Incluso si se ejecuta t.sleep (), el hilo actual va a dormir, no el hilo t. T.Suspend () es un método obsoleto. El uso de suspender () hace que el hilo ingrese a un estado estancado. El hilo siempre sostendrá el monitor del objeto, y es probable que suspender () cause problemas de bloqueo muerto.
Object.Wait () hace que el hilo actual salga de un estado "innecesable". A diferencia de Sleep (), Wait es un método de objeto en lugar de hilo. Al llamar a Object.Wait (), el hilo primero debe obtener el bloqueo del objeto de este objeto. El hilo actual debe mantener el objeto de bloqueo sincronizado y agregar el hilo actual a la cola de espera. Luego, otro hilo puede sincronizar el mismo bloqueo de objeto para llamar a Object.notify (), que despertará el hilo que originalmente estaba esperando y luego liberará el bloqueo. Básicamente, Wait ()/notify () es similar a Sleep ()/Interrupt (), excepto que el primero requiere que se adquiera el bloqueo del objeto.
7. ¿Qué sucede al usar sincronización en métodos estáticos?
Al sincronizar un método estático, se obtendrá el objeto "clase" de la clase. Por lo tanto, cuando un hilo ingresa un método estático sincronizado, el monitor de subprocesos adquiere el bloqueo de objeto de la clase en sí, y otros subprocesos no pueden ingresar ningún método de sincronización estática de esta clase. No es como un método de instancia, porque múltiples hilos pueden acceder a diferentes instancias simultáneamente métodos de instancia sincrónicos.
8. Cuando se ha ejecutado un método de sincronización, ¿puede el hilo llamar al método de instancia asíncrona en el objeto?
Sí, siempre se puede llamar a un método asincrónico sin ningún problema. De hecho, Java no realiza ninguna verificación de métodos asincrónicos, y los objetos de bloqueo solo se verifican en métodos de sincronización o bloques de código sincrónicos. Si un método no se declara como sincrónico, incluso si está utilizando datos compartidos, Java aún lo llamará sin verificar si es seguro, así que tenga especialmente cuidado en este caso. Si un método se declara sincrónico depende del acceso crítico de la sección. Si el método no accede a la sección crítica (recursos compartidos o estructuras de datos), no es necesario declarar sincrónico.
Aquí hay un ejemplo: la clase común tiene dos métodos sincronizadosmethod1 () y método1 (), y la clase MyThread llama a estos dos métodos en un hilo independiente.
clase pública común {public sincronizado sincronizado sincronizadomethod1 () {system.out.println ("sincronizadomethod1 llamado"); intente {Thread.sleep (1000); } catch (InterruptedException e) {E.PrintStackTrace (); } System.out.println ("SynchronizedMethod1 hecho"); } public void Method1 () {System.out.println ("Método 1 llamado"); intente {Thread.sleep (1000); } catch (InterruptedException e) {E.PrintStackTrace (); } System.out.println ("Método 1 hecho"); }} Public Class MyThread extiende Thread {private int id = 0; común común común; public mythread (nombre de cadena, int no, objeto común) {super (nombre); común = objeto; id = no; } public void run () {System.out.println ("Running Thread" + this.getName ()); intente {if (id == 0) {Common.synchronizedMethod1 (); } else {común.method1 (); }} catch (Exception e) {E.PrintStackTrace (); }} public static void main (string [] args) {común c = new Common (); Mythread t1 = new MyThread ("MyThread-1", 0, C); Mythread t2 = new MyThread ("MyThread-2", 1, C); t1.start (); t2.start (); }}Aquí está el resultado del programa:
Ejecutando ThreadMyThread-1
sincronizadomethod1 llamado
Ejecutando ThreadMyThread-2
Método 1 llamado
sincronizadomethod1 hecho
Método 1 hecho
Los resultados muestran que incluso si se ejecuta el método sincronizadomethod1 (), se llamará a Method1 ().
9. ¿Pueden dos hilos llamar a dos métodos de instancia sincrónicos diferentes en un objeto?
No, debido a que un objeto ha sincronizado el método de instancia, el hilo adquiere el bloqueo del objeto del objeto. Por lo tanto, otros métodos de sincronización solo se pueden ejecutar después de liberar el método después de que se libera el bloqueo del objeto. El siguiente ejemplo de código es muy claro: la clase común tiene los métodos sincronizados demethod1 () y sincronizedMethod2 (), y MyThread llama a estos dos métodos.
clase pública común {public sincronizado sincronizado sincronizadomethod1 () {system.out.println ("sincronizadomethod1 llamado"); intente {Thread.sleep (1000); } catch (InterruptedException e) {E.PrintStackTrace (); } System.out.println ("SynchronizedMethod1 hecho"); } public sincronizado void sincronizadomethod2 () {system.out.println ("sincronizadomethod2 llamado"); intente {Thread.sleep (1000); } catch (InterruptedException e) {E.PrintStackTrace (); } System.out.println ("SynchronizedMethod2 hecho"); }} Public Class MyThread extiende Thread {private int id = 0; común común común; public mythread (nombre de cadena, int no, objeto común) {super (nombre); común = objeto; id = no; } public void run () {System.out.println ("Running Thread" + this.getName ()); intente {if (id == 0) {Common.synchronizedMethod1 (); } else {común.synchronizedMethod2 (); }} catch (Exception e) {E.PrintStackTrace (); }} public static void main (string [] args) {común c = new Common (); Mythread t1 = new MyThread ("MyThread-1", 0, C); Mythread t2 = new MyThread ("MyThread-2", 1, C); t1.start (); t2.start (); }}10. ¿Qué es un punto muerto?
Un punto muerto significa que dos o más hilos están infinitamente bloqueados, y los hilos se esperan entre sí los recursos requeridos. Esto puede suceder cuando dos hilos intentan adquirir bloqueos para otros recursos, y cada hilo está esperando indefinidamente la liberación de otros bloqueos de recursos a menos que se termine un proceso de usuario. En lo que respecta a Javaapi, pueden ocurrir un punto muerto de hilos en la siguiente situación.
11. ¿Qué es un hilo muerto de hambre y qué es un bloqueo en vivo?
Aunque el hambre de hilos y los bloqueos de la vida no se consideran problemas comunes como los puntos muertos, son como un encuentro para los diseñadores de programación concurrente.
Cuando todos los hilos están bloqueados o no se pueden procesar porque el recurso requerido no es válido, no hay hilos que no sean bloqueados para que el recurso esté disponible. Los mechones vivos de hilo en Javaapi pueden ocurrir en las siguientes situaciones:
Las preguntas aquí no son detalladas, espero que sean útiles para todos. Si tiene alguna pregunta, déjame un mensaje y el editor responderá a todos a tiempo. ¡Muchas gracias por su apoyo al sitio web de Wulin.com!