Las siguientes son preguntas relativamente avanzadas, y generalmente rara vez se hacen durante las entrevistas porque pueden rechazar al entrevistador. Pero puedes encontrar algo de tiempo para practicarlo tú mismo.
1. System.exit (0) omitirá la ejecución del bloque Finalmente
System.SetSecurityManager (new SecurityManager () {@Override public void checKExit (int status) {tire new ThreadDeath ();}}); intente {system.exit (0); } finalmente {System.out.println ("en el bloque Finalmente"); } ¿Por qué sale este código en el bloque finalmente? ¿Por qué no se imprime la información de rastreo de pila?
2. String Str = "Hello"; donde str es un objeto de cadena
A diferencia de C ++, las variables en Java son tipos básicos o referencias. Una variable no puede ser un objeto. Esto significa una expresión como esta:
Cadena str = "hola"; String Text = "Bye"; str == texto; // Compare dos referencias en lugar de contenido str = text; // Asignar la referencia del texto a STR
En la mayoría de los casos, en realidad no hay mucha diferencia, pero escribir como esta puede causar fácilmente confusión.
StringBuilder final sb = new StringBuilder (); sb.append ("hola"); // Esta referencia es de tipo final, no esta instancia. método (SB); // Esta instancia se puede modificar a través de métodos, pero esta variable no se puede modificar 3. La fuga de memoria de Java es la misma que los programadores de C ++ entienden
La definición de fuga de memoria en Wikipedia es "en informática, si un programa no administra la asignación de memoria correctamente, se producirán fugas de memoria. En la programación orientada a objetos, si no se puede acceder a un objeto en la memoria en el código, esta es una filtración de memoria". Sin embargo, en Java, los objetos siempre son accesibles, y aquellos sin referencias fuertes serán eliminadas. El término fuga de memoria significa en Java: hay objetos que no deberían existir en la memoria, y generalmente algunos recursos que ya no se usan todavía se almacenan en la colección.
4. La programación multiproceso es difícil
Si no tiene experiencia, la programación de múltiples subprocesos es realmente difícil. Si simplemente arroja un montón de código a un montón de hilos y lo ejecuta, entonces el problema no se puede resolver en absoluto, será un desastre. Pero si puede realizar la asignación de hilos a pedido, controlar las interacciones entre los hilos y usar patrones simples que algunos miembros del equipo también pueden entender, el problema se vuelve mucho más simple. Por supuesto, hay otro desafío que debes hacer que todos en el equipo sigan tus reglas
5. No me importan las diferentes actuaciones entre diferentes operaciones
Recientemente escuché que hay un problema, que implica la adición de enteros, acceso a la memoria, módulo y salida a la consola. Aunque cada una de estas operaciones es un orden de magnitud más lento que la anterior, este tipo solo quiere optimizar la operación, adición y reemplazar más rápida con algunas operaciones más caras. Si realmente desea optimizar el rendimiento, será mejor que reemplace esas operaciones costosas con una operación barata. Si su cuello de botella está en el hardware, por ejemplo, debe leer una gran cantidad de archivos del disco duro, modificar el código del software es inútil, porque el problema no es en absoluto.
6. Los números aleatorios son aleatorios
Un conjunto específico de números aleatorios es como números de algún patrón. Ya he hablado sobre este tema en este artículo. Muchas personas no creen que los números generados por los generadores de números aleatorios en realidad no sean aleatorios.
7. Se deben evitar los puntos flotantes, ya que producirán errores aleatorios
Para la misma operación, los números de punto flotante producirán el mismo error cada vez. Los errores son predecibles y, por lo tanto, controlables. Si sabe lo que va a hacer y se apegará a algunas reglas simples, como redondear los resultados, entonces los números de punto flotante no cometerán más errores que BigDecimal. Además, es más legible y más de cien veces más rápido (y hay menos objetos de basura generados al mismo tiempo).
8. La zona horaria es eterna
La razón de este malentendido es que a medida que cambia el tiempo, la zona horaria está cambiando. Esto significa que Europa/Londres fue 1970/1/1 01:00 en lugar de 00:00. ¿Por qué? Porque Londres usó el tiempo de salvación de verano en los dos años de 1968 a 1971.
En los últimos años, muchas zonas horarias también han cambiado. Moscú solía ser el East Third District (GMT+3), pero ahora es el Cuarto Distrito Este (GMT+4) (a partir del 27 de marzo de 2011). Si observa la época de 2010, encontrará que es East 3 y East 4.
Hay algunas cosas que puede sonar sorprendido:
Febrero de Suecia en 1721 tiene 30 días.
El primer día en Inglaterra en 1751 fue el 25 de marzo, que estaba 11 días detrás de Francia.
Después de que Estados Unidos adopta el calendario gregoriano, se remonta a cientos de años, por lo que las fechas registradas originalmente se pueden expresar en dos calendarios (generalmente se proporcionan dos fechas al mismo tiempo para más precisión). Por ejemplo, el cumpleaños de George Washington cambió del 11 de febrero de 1731 al 22 de febrero de 1732.
9. Cuando lee una variable no volátil en un hilo, finalmente puede leer el valor que actualizó.
Este problema apareció dos veces en Stackoverflow hace unos días. En términos generales, cuando el compilador JIT optimiza el código, en línea los campos de tipos no volátiles que no se han modificado a este hilo. Una vez que se compila este código (puede verlo con -xx:+printCompilation), es probable que nunca sea visible si modifica este campo en otro hilo. Agregar bloques de sincronización aleatorios o declaraciones de impresión puede retrasar la ejecución de esta optimización o interrumpir el compilador JIT para que no realice esta optimización.
10. Las preguntas de la entrevista de Java son correctas
Hay muchas preguntas de entrevistas de Java que están obsoletas (no están actualizadas durante más de 10 años y están fuera de contacto con la versión actual de Java), o son engañosas, o incluso pueden estar equivocados. Desafortunadamente, ninguna de estas respuestas se pasó sin verificarlas.
Me referiré a las respuestas de Stackoverflow anteriores porque la revisión por pares aquí hace un mejor trabajo al revisar las respuestas. En general, no vayas a sitios web como Rose India, las respuestas anteriores son de una calidad ridícula. Si desea llegar al final, puede consultar cuántos errores de ortografía (nombres de clase y términos profesionales) o comentarios incorrectos se encuentran en el artículo anterior. Una razón de estos problemas es que no hay un mecanismo de retroalimentación efectivo para corregir estos errores.
Me gustaría recomendar algunas preguntas de la entrevista de Java:
Las 50 preguntas de entrevista de Java más valiosas son adecuadas para la admisión a los programadores de Java
10 preguntas clásicas de entrevista del método principal de Java
Discuta las diez preguntas de entrevista más comunes en Java (Super Classic)
Se lanzan 10 preguntas de entrevista XML para programadores de Java
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.